title: Using C++ to interface with a line-scan camera at 3000Hz, and process / display the data
body: <p>Several months ago, I started working on a project to develop an algorithm to process data acquired from a linescan camera device (e.g., a line of 384 pixels every 300us).  Since I am an engineer and not a programmer, I started working with Python to minimize the learning curve.  With help from SX, I successfully built a Python application (that ended up being more than 2000 lines of code) and successfully created an image processing algorithm to work with the data.  I impressed the customer and they want to take it to the next level.  Now, I need it to be real-time... and that means C++.  I got Koenig and Moo's Accelerated C++ and started reading.  So, please go easy on me.  I love to learn to program, but I have no formal training.  I'm doing the best I can!</p>
  
  <p>I now have a C++ prototype GUI (using Qt) wrapped around all the libraries needed to communicate with the camera via a CameraLink interface.  The acquisition code lives in its own thread and emits signals to the GUI.  So, I have the fundamentals in place.  I can acquire as many lines of data as I wish with my current code, but I am now trying to figure out how to build an application around that.  Even wrote a custom makefile that works with Qt (MOCing, etc.)</p>
  
  <p>Anyway, for the application, I would like two modes (these are the QUESTIONS): </p>
  
  <p>(1) A "live" view... where the linescan data is displayed in real time by the GUI.  I was thinking about using a circular buffer (e.g., Boost::circular_buffer) to hold the data in real time, and simply pass a copy of the buffer (memcpy?) to the GUI via an emitted signal.  Is this tenable?  I feel the copy of the buffer is necessary since the circular buffer will change every 300us or so and I don't know the main event loop can keep up.  Again, the data acquisition lives in its own thread.  Does it have to be more complicated than that?  Will I have to pop data from the buffer as it is read instead of using a circular buffer?  I felt a circular buffer was the way to go since that is exactly the kind of image I want to display.</p>
  
  <p>(2) A data processing mode... where the linescan data is emitted in blocks (i.e., 384 x 384) pixels.  At a scan rate of 300us (~3,333 Hz), that is a block or frame every 100ms or so.  In that 100ms, I'll need to do normalization of data, object detection, thresholding, etc.  I'm planning on running this on a Linux box running real-time kernel patch.  I think it should keep up.  I'll need to communicate between the data acquisition and data processing threads...  do I need sockets for this?  </p>
  
  <p>I'm looking for advice here on how to get started with these two pieces.  The second one is more critical, but the first will help me visualize what is going on.  Ultimately, I'd like to have both modes running simultaneously.  I've spent most of the week getting this far... but need to ensure I'm heading down the right path with my plan. </p>