The Video Streaming System
Being the first attempt to document the programs Gonzales and ImageReader for fast video streaming, including tips for use and installation reports

By Enrico Segre

Oct 27, 2014

1 Generalities

1.1 Scope

1.2 The name

1.3 Design Choice

2 Installation

2.1 Hardware

2.1.1 Server platform

1. ahissar-pc55 (“Udi’s”, “room 69”), building (assembling and setup at WIS) started 6/5/2009;
2. ahissar-pc66 (“behavioral”, “Inbar’s”), built about 9-10/2010, as an exact copy of #2.1.1↑
3. OPTOWHISKER (“Tess’”), building started 23/12/2012.
4. MAMTAK (“Noy’s”), building started 19/12/2013.

2.1.2 Camera

2.1.3 Framegrabber

2.1.4 Disk array and RAID controller

2.1.5 DAQ

2.2 Software

2.2.1 OS

2.2.2 RAID setup

• system #2.1.1↑ and #2.1.1↑ have been configured as 4 logical volumes of 2 disks each, independent volumes at controller level.
• system #2.1.1↑ has been configured as a single logical volume including all 8 disks at controller level.

2.2.3 Framegrabber driver and SDK

2.2.4 Camera configuration files

2.2.5 Labview

2.2.6 Framegrabber LV layer

2.2.7 Camera control software

2.2.8 Application programs

2.2.9 AVI codecs

2.2.10 Goodies and Ancillaries

3 Applications: user manual

3.1 Gonzales

3.1.1 Main image tools and information

The program shows in its larger inset window the image acquired by the camera (if it is turned on, if there is enough illumination, if parameters are correct). Since there would be no point in trying to show every image coming from a fast camera (the eye would not appreciate, and the computational load would be prohibitive), the display is refreshed as specified by the

↓Show Image slider. Normally 5fps is a reasonable compromise providing enough feedback about what is happening under the camera without spoiling the exactness of software timing; in normal circumstances even 25fps is affordable. For testing purposes (e.g. on former systems on which screen drawing was very CPU intensive, and interfered with video streaming), the display can also be suppressed (position “No Show”). In such case, clicking on the image still refreshes it.

The main image can be zoomed in or out (select the lupe↓ tool at the upper right corner of the image), panned (select the hand↓), or rectangular Regions Of Interest (↓ROI) can be drawn (select the rectangle↓). Multiple ROIs can be drawn holding Control; ROIs can be dragged around and adjusted by their corner handles, and a right-click menu allows to clear them selectively.

The button ↓ROI all creates a single ROI enclosing the whole image.

Below it, the recessed button with a ↓crosshair symbol toggles the drawing of a red crosshair in the center of the image. This may be of no use nowadays, it was an aid in pointing and tracking in earlier versions.

3.1.2 Camera control

3.1.3 Streamfile control

3.1.4 Recording control

This group comprises controls which, loosely said, determine how and when the streamfile is written.

• the condition write if present in self can be activated;
• if ROI write is on, the (single) ROI of the main image is adjusted dynamically, following the centroid of the detected blob and preserving its size. The intended effect is that the movie records a subimage, which tracks a single moving object detected in the larger frame. The limitation is that blob analysis needs some tens of milliseconds to be computed, hence the ROI position can be updated only every several frames when acquiring at high speed, and the resulting effect is rather jerky.

3.1.5 Tabs

A wealth of additional diagnostic information, as well as configuration which does not need to be constantly observed by the user, has been organized in tabbed pages in order to economize screen space. Tabs are switched to by clicking on their labels on top of the page.

3.1.6 the Streaming statistics tab

This tab shows a lot of statistic information about the enqueuing of images grabbed and waiting to be written, which is important for debugging and troubleshooting anomalous conditions, but less useful for the normal use. The indicators in this tab cause a lot of video activity, which increases the jitter in all timings. Because of that, there is a switch ↓Visible stat in the upper right corner, with a caption encouraging the user to keep it off. In the off position, all indicators but first frame in movie and lost frames (if supported) are made invisible. [In fact, having this tab open with Visible stat off is the position causing the least video activity among the three tab options].

3.1.7 the Self Tracker tab

3.1.8 the Hotspots & Triggers tab

1. Detection of activity in the ROIs (the Hotspots↓) defined in the main image, and computation of logic functions involving them (Formulas↓)
2. Configuration of an UDP listener service, allowing other programs on the same computer or on a computer across the network to send commands to Gonzales while it runs (UDP remote commanding↓)
3. Configuration of a service sending event messages to an external logger, potentially listening via UDP (UDP reporting↓)
4. Routing of digital triggers, to which Gonzales reacts or which Gonzales generates, to the available ports of eventual DI/O cards (Digital lines routing↓)

3.1.9 Formulas

3.1.9.1 UDP commanding

set “control name” value

set “take as reference” true
set “write to file” TRUE
set “pixel clock” 1
set “ROI y offset” 32
set “streamfile” F:\test1\streamtest_new

set ohy ohi “camera framestamp” trumpatrumpatretre

3.1.9.2 UDP reporting

3.1.9.3 Digital routing

3.1.10 Session control

The correct way to terminate the program is always by clicking on the Quit button↓. Attempts to stop it differently, like by pressing on the stop button on the Labview Toolbar (an action which is left for emergency stops and troubleshooting), will most likely leave some camera resources busy, and will need quitting labview (or altogether killing the process from OS) in order to resume operation.

3.2 ImageReader

3.2.1 Streamfile controls

3.2.2 Main image and File info

The main image shows the current image in the streamfile being played. It is implemented as standard Labview image widget, with features pretty the same as that of the main image in Gonzales (see section 3.1.1↑).The image can be zoomed in/out when the lupe↓ tool is selected, panned ( hand↓), ROIs can be drawn ( rectangle↓), and a right click menu adds a few options for handling ROIs, zooming to fit, exporting the image. Below the image tools, by the upper right corner of the image, a frame reports the current zoom factor, and the intensity value and coordinates of the pixel over which the mouse is hovering.

3.2.3 Movie position controls

3.2.4 Jog shuttle

This composite control controls the playback speed of the movie, which can be played forward as well as backwards. At 1x, the movie will be played at the frame rate specified by frame rate↓ (provided that the streamfile can be read fast enough and the video card is capable of; normally files are inspected and played at a much lower speed than that they were recorded at, so that is a non-issue).

3.2.5 the Single blobbing tab

thresholded difference↓ is a binary image showing the result of the image processing done to locate the centroid of the blob, that is a morphological erosion of the thresholded absolute difference between the image analyzed and the reference background. The Blob↓ (sorry, I really can’t resist; see http://en.wikipedia.org/wiki/The_Blob) is the set of points showing in white. Note that this image is updated infrequently during scanning, to save CPU time spent in screen rendering.
The widget is locked in ROI draw mode (equivalent to choose the rectangle tool in the main image), so that rectangular ROIs can be dragged around interesting blobs.

3.2.6 the ROI logic tab

3.2.7 the Playlist tab

• pressing add stretch between bookmarks to playlist appends the stretch currently selected (section 3.2.3↑) to the list;
• running a scan for activity, all the stretches identified are automatically appended to the existing playlist. If the scan spans several files of a sequence, all the relevant stretches are inserted as they are found.

3.3 Goodies

3.3.1 WriteSpeedTestNormal

3.3.2 UDPSender2 and UDPReceiver2

3.3.3 AVItoStreamfile

3.3.4 matlab scripts

A Streamfile API

Streamfiles format since Gonzales3

Header (first block, size=1 sector):

• bit 0  →  Basler Stamp (inserted by the camera at source): AOI (4*U16) and image counter (U16) in the last 10 pixels of the last image line.
• bit 1  →  Software timestamp (inserted by Gonzales): the first 20 pixels of the last line contain: image counter (U32), AOI (4*U16), Pan Tilt (2*I32). Versions of Gonzales later than 3 may have written other test and statistic data (e.g. grabbed buffed number) in place of the no more present PTU coordinates; do not relate to them.
• bit 2  →  Optronis timestamp (inserted by the camera at source): the first 2 pixels of the first line should contain image counter (U16) [the buggy firmware of the older Optronis writes garbage here, the other cameras are ok]
• bit 3  →  Software millisecond absolute timestamp (inserted by Gonzales, subjected to OS jitter): (U64) counter representing the number of milliseconds from 1/1/1904, written in place of first 8 pixels of the first line, i.e. the upper left corner. (Was not implemented, hence bit3==0, until Gonzales8).
  Bits 0 and 2 are mutually exclusive, but the other bits may be either on or off depending on user choice at the time of recording.

Each image contains:

B Changelogs

Gatto10

26/10/2014

ImageReader 9.3

• hotfix: img_read_file_Normal receives also the argument LineWidth, because apparently the alignment requirement has changed from multiple of 32 bytes to multiples of 64 bytes somewhen across time. Old streamfiles, especially ROI cuts with odd horizontal sizes, recorded in the past, have values of LineWidth recorded in the header which don’t match anymore what IMAQ GetImagePixelPtr reports for an image buffer of the same exact size, hence the stored value of LineWidth has to be taken into account instead.

12/3/2014

Gonzales 10.3

• in Self Track. the center of the ROI can be moved not just to the center of the detected blob, but also at any of the eight corner and mid-side positions of the bounding rectangle. This is done to help automatic positioning of optical threshold detectors with moving poles.
• "lower threshold", "upper threshold" and "erosions" unbundled in order to be directly controllable by UDP set commands.
• In principle, numeric arrays too can set via UDP commands. That was done for changing "ROI size", but the periodic check to rebound the ROI inside the frame renders that ineffective as of now.
• minor glitches addressed, strings of "formula to Write to file" updated on start, and "load configuration", "save configuration" forced to false

2/1/2014

Gonzales 10.2.1:

• Just recompile for LV2013_64bit, moved to .2 to safeguard from possible changes. In fact, enlargement of the ringbuffer to 600 images (more than that seems to impact negatively performance and to cause stability problems); possibly other minor FP size adjustments.

ImageReader 9.2:

• timestamp as string appended into the AVI frame data when stream is exported to AVI. No check on source is done, i.e. when exporting to AVI streamfiles which have not been recorded with "software timestamp" tagged, garbage will be present in that position

AVIfileLister:

• quick snippet to read the timestamps of the first and last frame of all AVI files in a selected directory (supposed exported by ImageReader9.2 from a streamfile recorded with "software timestamp" tagged), and to dump the information into a csv file.

Gatto9

15/8/2013

Gonzales 10.2:

• solve bug "UDP in error" not clearing unless restarting the big loop
• solve bug frame in movie repoted as #0 when udp reporting activity of hotspot>1. Hopefully not broken the frame# reporting upon trigger, because the fix was about a mixup there.

19/3/2013

Gonzales 10.1:

• add a "Not Write repeat line (OUT)" for Tess

21/1/2013

ImageReader9.1:

• subvis for Load/Save ROI logic. No visible FP change if excluding perhaps very minor cosmetics.

Gonzales10:

• ROI logic instead of Hotspots; triggers & hotspots tab reorganized.
• automatism to choose the Karbon SDK path and Karbon card registry entry on the system, hopefully allowing same code to work on all systems.
• UDP listener to generate arbitrary control changes events (first use thought: new background, also commanded write start)
• Chosen ROI formula triggers Write start OR Write in effect (selectable)
• reconfiguration of DI/O and UDP ports does not restart grabbing, as did before due to lazy programming.

15/1/2013

ImageReader9:

• no ROI on opening the program;
• default "remember ROI across files"
• ROI diff average values updated also when pressing "take as ref"

1/1/2013

ImageReader9rc:

• ROI logic for scanning activity: new tab with boolean formulas, choice between old mode "blobbing" activity and new logic mode; definition of stretched with start and end anticipated/retarded with respect to the activity detected on image; annotation of the main image with ROI name and mean absolute difference value; saving and loading of ROI definitions and formulas.
• some code modularization in the scanXact event frame, to allow development.
• image updates while scanning for activity.
• minor cosmetic FP and wiring cleanup.
• TODO: double buffering and simultaneous read/process could speed up scanning and export?

Gatto8+

25/12/2012

Gonzales 9.3

• path and registry key for the new environment (to be hardwired on the BD according to case)
• avoided unnecessary registry writes if camera configuration is not changed.
• avoided restarting grabbing when pixel clock or #taps is changed. Avoids a frequent loss of sync of the frame after the very first few images grabbed, while settings are changed.
• added a boolean indicator "setting camera". Main use, to flag the completion of the serial settings, to reference the first fiducial framestamp. The count of "lost frames" (when camera framestamp is checked) is now correct.
• All stream file access functions use now normal (unbuffered) file access functions, avoiding the original direct calls to kernel32.dll. Same functionality, hopefully more portability.
• changed ROI save in configuration file, still not satisfactory (restores as ROI the global rectangle, not all ROIs).
• write configuration on exit copes nicely with configuration file not previously existing.
• minor cosmetic changes (wire positions) on the BD. Many blocks wrapped by conditional disables for testing, left in place.
• observed occasional MemoryManager.cpp crashes. To be cleared whether LV bug or race condition.
• Observed higher tendency of locking the frame out of sync, notably immediately after changing to a new frame mode. An operative workaround, if the image locks out of sync, is to select again the same "Karbon camera configuration" from pull down menu, and repeat if necessary. If it doesn’t help, usually lowering the fps, selecting the configuration, and increasing fps afterwards does the trick.

SDK5.60

23/12/2012

Gonzales 9.2

27/9/2012

Gonzales 9.1

• Message reporting logic changed attempting to achieve more reliable frame# report. Local interthread variables store the grabbed frame number at the time the last trigger/hotspot was received, and the reporting thread which builds the message reads these variables, even if running asynchronously.
• autosaved configuration file now called <VI_name>Config.dat instead of GrabberConfig.dat to avoid mixup of files when running variation VIs from the same directory.
• ROI position saved across sessions.
• attempting to get a correct count of "lost frames", but still not finding the logic mistake.

11/7/2012

Gonzales9

• best attempt to achieve a millisecond precision software timestamp. The timestamp is obtained by combining the system clock and the BIOS ticker. Both have millisecond resolution, but the former is updated at a rate decided by the OS (every ~15ms on windows XP, every ~1ms on linux and windows7). The timer readouts achieved seem accurate to +-1ms as long as the screen activity is minimal. Plotting a new image in the main Gonzales window adds delays of ~5-10ms, and displaying Gonzales statistics even of ~50ms.
• a new option for soft stamping the streamed images with this timestamp is implemented. The timestamp consists of 8 bytes written in place of the upper left corner, representing the number of milliseconds from 1/1/1904. Images can be marked with this timestamp as well as with the camera hard framestamp and soft framestamp previously implemented, so that their mutual consistency can be further checked. The considerations about the jitter and reliability of this software timestamp apply.
• one further digital input line is polled, so to provide the option of marking an additional trigger event (additional to the trigger used to start the recording).
• UDP reporting of various events, including start/stop of writing, file closing/reopening, hotspot activity, external hardware triggering. The report datagram includes the presumed timestamp, the kind of event, the current filename and the estimated frame number simultaneous with the event. The pretrigger offset is for the moment NOT taken into account in the computation of the frame, while the queue backlog is. The above considerations about the accuracy and jitter of the software timestamp apply. The UDP reporting can be directed to any single host (named or IP address) and port. It could be easily changed to broadcasting. The current design allows for a maximum of 100 report datagrams per second, but that is not a hard limit.
• the logic of polling the digital input lines and repeating on digital outputs has been somewhat changed, and it would be better to recheck that they function correctly.

ImageReader8

• support for the new software timestamping mode.

Miscellaneous:

[t_movie,s_framestamp,c_framestamp,img1]=movietimestamp2(’F:\testGonzales9\r’);
subplot(311),plot(diff(t_movie));
subplot(312),plot(diff(s_framestamp));
subplot(313),plot(diff(c_framestamp)); 

Gatto6&7

21/9/2011

New features in ImageReader5:

• improved navigation of sequenced files. A sequence is here defined as a set of streaming files, residing in the same directory, and having filenames differing only by a _NNNN ending, where NNNN is any integer number (no limitation about number of figures, nor is needed for numbers to be consecutive, as intermediate files may have been removed). An eventual file sharing the same name, but without the _NNNN ending is considered the first one of the sequence.
• A new checkbox by the jog-shuttle control determines whether the reader works in single file mode or sequence mode.
  In sequence mode:
  • play forward/backward automatically moves to the next/previous file of the sequence;
  • in paused mode, single stepping is also through files of the sequence.
  • Search for activity continues from the current file on, to the last file of the sequence, using the same reference image initially chosen. Activity (i.e., frames sufficiently different than the reference) stretches are automatically inserted in the playlist.
• Playlist.
  A new list of stream stretches can be used. Each entry of this list contains the filename reference to the movie, a start and an end point. Filenames can belong to different sequences and reside in different directories. Filenames cannot be edited, but start and end frame number can. An unlimited number of stretches, even overlapping, of the same movie can be inserted in the playlist. The playlist is not for "playing" the stretches in sequence, but is intended to be a repository of bookmarks into different files at once, and a list of stretches to be exported in batch, unsupervised operation. Entries in the playlist can be inserted or removed manually, copying the current filename and bookmark position, or automatically, as the result of a scan for activity search. The playlist can be saved to file and retrieved; it can be navigated. No provision is made for reordering it, though. The reader can be made to play the currently selected entry of the playlist at a click. [No, I don’t know how to make more evident the highlight of the selected entry]. An export action exports FIRST the stretch of the current movie between bookmarks (previous behavior), THEN continues exporting one after the other the entries of the playlist FOLLOWING the currently selected one. This is not the most ergonomic behaviour, and could be improved in future. The usage scenario for the time being would be to select in the playlist the first stretch to be exported (could be at any point of the playlist), render it current, and then start the exporting. Exporting and scanning for activity can be canceled at any time even when they navigate through multiple files [but there seems to be a bug as sometimes the cancel button does not react — to be investigated]
• Search for activity: if(?) no ROI is selected in the main image (right mouse button/clear ROI), then the ROI resulting after the search will be the largest rectangle containing all the "active" pixels across all images scanned and tested. This feature allows to preselect automatically an "interesting" subregion of the image. The resulting ROI will just contain the active pixels; an eventual guard border has to be added manually a posteriori by enlarging the ROI found.
• improved robustness of the program when reading corrupted files (but no attempt made yet to guess the correct movie parameters of stream files with missing or corrupted header block). [Corrupted headers also usually result in an abnormally large number of frames; I still have to prevent the program from trying to loop on the nonexistent frames when playing in sequence, or scanning for activity, otherwise the program does it forever].
• Timestamping:
  As of now, the following sources of framestamping and timestamping are available:
  • the OS marks the creation date, the closing date and the last access date of the file to the precision of 1 sec. Currently ImageReader5 reports the second of these three, which is the one most easily achievable with LV. These already provide an identifier.
  • at recording time, the user can presently choose to activate camera timestamping and soft timestamping. The former, for the camera with the correct firmware release, is a 16 bit counter, which advances at every frame, i.e. regardless of whether we are writing to file or not. The information is stored in corner pixels of the image. The soft framestamp also writes to corner pixels the values of two I32 program counters, which are also running since the program is started. Non identity of these two values already implies some loss. All these counters can be used to some extent to determine the timing of each frame and to detect frame losses. For instance, the values of each of these counters have to increment by 1 at each frame; larger increments mean either a frame loss or an interrupted and resumed recording [which is one of the currently possible modes of operation!]. Jumps forward of these counter of as many frames as the ringbuffer size (currently 400), or multiples of, denote a buffer full condition, i.e. a sustained slowing down of the write-to-disk thread w.r.o. the grabbing thread. The framestamp provided by the camera is absolutely (in the sense, not affected by software jitter) reliable, but wraps around 2^16, that is every 65sec at 1000fps. Hence it provides only timing information modulo that amount. Relative timing of a frame within a movie is currently calculated by multiplying the counter increment since the first frame of the movie by the movie fps. The only "absolute" timing achievable as of now, considers the absolute value of these counters, which is at best relative to the time either the camera was turned on or the grabbing program was started, i.e. not too useful.
  An implementation of absolute (PC clock) soft timestamping of the grabbing time of each frame is under consideration.

New features in Gonzales7:

• stricter timing in the startup of the recording, notably with respect to triggered start and pretrigger recording. With the work carried on so far (essentially more careful decoupling of GUI activity from time critical threads), I have been able to achieve a somewhat more reliable timing on Inbar’s system, but not yet the goal of time determinism to the millisecond. I’m already much in the direction though, as the current performance seems to be the start of the recording exact to the millisecond in at least 90% of the cases, BUT with a systematic (and changing) further small anticipation. Extensive timing tests, now made easy with ImageReader5, have been done by recording several short movies with various fps and pretrigger time settings, filming a led which is turned on or off immediately after the record button is pressed or the trigger signal is received. The two problems observed as of now [could hopefully change] are:
  1. The recording starts actually always a number of frames earlier than expected (w.r.o. the turning on of the led). That is at least good because it implies no data loss. Usually the number of early frames is ~8. A couple of them could be explained by the fact that shooting is already taking place before the frame is readout from the camera and then transferred to computer memory; it may well be that the led turns on with a delay (due to data transfer to DI/O delay or led response time), but those don’t explain completely what observed at different fps. It is to be assessed whether this overhead is due to the polling or to the repeat of the trigger state done via an USB card, which certainly involves the management of internal communication buffers and packetization.
  2. on a minority of movies, a few images which should still belong to the previous movie in the sequence end up in its successor. That is evidenced by inspecting framestamps. Usually the first offending frames are ~12 frames after the last frames of the preceding movie, then there is a longer frame counter break, and then begins the intended movie. Relative timing computations based on the difference between the current frame of the movie and its first one are clearly affected. [bug to be tackled]
  On Udi’s system, these problems are absolutely exacerbated at normal working fps, and repeatable trigger timing seems possible only when shooting at rates of the order of tens of fps.
• better care taken of the sequencing of opening and closing files in progressive recording mode. That should avoid situations in which image data intended for one file is written on the next one of the sequence, opened too early, and file headers not correctly created. [NB: the system has anyway some limitation, yet do be fully timed, as for opening and closing files, which require longer disk operations (moving writing heads, despite caches, etc.). As a rule of thumb, I would say that you shouldn’t be working in progressive file mode if you expect recordings to be spaced in time by say, less than 100ms of dead time]
• in Progressive Recording mode, the maximal number of frames to record is remembered from one stream file to the next. It is only bounded by the available disk space, and reduced when less than the requested number is available. [The actual number of frames recorded is not as of now very exact, due to the construction of the program. That deserves to be improved in future, together with a better treatment of the number of frames to be included in the stream AFTER the end of the trigger signal, and the option of posttrigger delay in starting to record]

In course of evaluation, probably will be implemented in the near future:

• Absolute soft timestamping of the frame in corner pixels, as double precision second counter since 1/1/1904. Would either replace and supersede the previous PTU position stamp, currently used as grab loop/write loop counter stamp (2xI32), or augment it, perhaps classifying it as a new stamping option (file header, etc). That would represent the time of arrival of the frame from framegrabber to memory; not the absolute shooting time, but valuable for referencing and studying the grabbing jitter.

Miscellaneous comments about the systems:

• The present design pattern of the recording system is the only possible one which allows pretriggered recording of the images with the given hardware, for unpredictable trigger occurrence. That is, given that neither the camera or the framegrabber have image memory, we run the camera continuously, store a heap of recent images within the computer memory, and if a trigger appears we decide which images to transfer to disk.
  Our program, written in user space on a GUI-reactive system, has to stand behind the two time-critical tasks - download images from the framegrabber before it is too late, and poll a trigger input - and take software decisions.
  If we would always be in the conditions where the trigger occurrence could be anticipated (e.g., if the control of the trigger event would be our call, not if the trigger depends on the occurrence of some external and unpredictable event), then we could switch to a model in which the camera is "turned on" and starts to deliver frames only with the selected anticipation before the trigger. That design would allow the trigger to be taken care by non-user-interaction dependent hardware, which could enforce real strict timing. For instance, a pulse generator (card, eventually) providing the camera frame sync, which would start its train of pulses at the activation of a pretrigger input, which would precede the trigger output by a preprogrammed time. Our program design would have however to be significantly revised.
  The path I have been pursuing so far, instead, has been of trying to identify all existing impediments to the time critical tasks, and to decouple them, in order to maintain the existing GUI driven, user space design pattern, which is more comfortable for me to work with.
• It is recommendable to upgrade Udi’s system with some sort of graphic card. It seems that screen drawing operations take always a high system priority, which heavily interferes with other time critical tasks. On Udi’s system these are noticeably slower and heavier to the system than on Inbar’s system.
  Though programmatically it is possible (and has been largely done so far) to limit heavily the amount of redraw operations, it is not desirable to have none of them. It seems (but see next point) that the producer-consumer thread model for grabbing and writing to disk is still able to cope with the maximal target bandwidth without loss of frames, but high jitter is then apparent, as evidenced for instance by fluctuations of the loop repetition rate and ringbuffer fill. This jitter is almost absent in Inbar’s system. Moreover Inbar’s system is even as of now way more repeatable w.r.o. trigger timing repeatability when the trigger is polled from the USB DAQ card. That this is due to a competition of priorities is merely an educated guess so far.
• The camera used in Udi’s setup has an older version of its firmware, which is incapable of writing correct framestamps. Upgrade is recommended in order to be able to monitor the performance and the eventual loss of frames of the recording system, which presently is only indirectly possible and not always conclusive.
• Udi’s system seems slightly unstable, but precise causes and cures unassessed. Unknown whether eventual BIOS or framegrabber firmware upgrades might help. Recurring complaints are inability to cold boot if an USB peripheric is connected, and rare nonrecognition of the framegrabber card at cold boot, usually solved by turning off the system for a while, in extreme cases by removing and reinserting the framegrabber card.
• To be assessed if the use of a PCI DI/O card (rather than the present USB DAQ) could provide stricter overall reaction times to the recording trigger, which is currently software polled.

Gatto 5

21/1/2011

Gonzales5 & 6

ImageReader4

Gatto4

21/9/2010

Gonzales4

• writing to windows registry for configurations
• removed range camera, camera-PTU registration and PTU drive

ImageReader4

Gatto 3

6/1/2010

ImageReader4 18/1/2010

Gatto 2

23/11/2009

Gonzales3

19/11/2009

Gonzales2

17/11/2009

Gonzales

TopoTracker

FastCameraStream11-13

23/11/2009

ImageReader3

ImageReader2

Gatto

FastCameraStream

12/10/2009

ImageReader2

11/10/2009

ImageReader

C Problems encountered in the past

• Framegrabber not seen in system #2.1.1↑, see 2.1.3↑. Symptom: Gonzales opens without responding and after a while trows obscure errors about Bitflow routines. To troubleshoot: open the Bitflow utilities PCIwalk: if no framegrabber is listed there, we have the problem. Other Bitflow utilities will also fail throwing errors.
• RAID disk failures, see 2.1.4↑.
• Losses of sync, see 3.1.1↑.
• Salt and pepper noise, see 3.1.2↑.
• Basler degradation of the image: it was some image degradation, or loss of sync, or NI framegrabber timeout after some minutes of work of the camera (don’t exactly remember). What I do remember is that me and Udi went crazy in searching the cause, trying to correlate it to cables, temperature, time of the day. At the end it turned out that the original power supply of the camera was faulty, and replacement with an off-the-shelf switching PS bought at Tzafrir solved the problem.

Index

>b2: ↑

AOI: ↑

Acquired frame: ↑

Allow: ↑

Digital lines routing: ↑

Event trigger line (IN): ↑

Formula to Write to file: ↑

Formulas: ↑, ↑, ↑

Formulas (Gonzales): ↑

Frame position: ↑

Global Rectangle: ↑

Host reported to: ↑

Hots: ↑

Hotspot: ↑, ↑

Hotspots: ↑

Karbon camera configuration: ↑, ↑

Load ROI logic (Gonzales): ↑

Local in port: ↑, ↑

Local out port: ↑

Lower threshold (Gonzales): ↑

PanTilt: ↑

Quit button: ↑

R value: ↑

ROI: ↑

ROI across files: ↑

ROI all: ↑

ROI size: ↑

ROI write: ↑

ROI x offset: ↑

ROI y offset: ↑

ROItracker: ↑, ↑

Remote in port: ↑

Save ROI logic (Gonzales): ↑

Show Image: ↑

The Blob: ↑

The activity bar: ↑, ↑

UDP in status: ↑

UDP out status: ↑

UDP remote commanding: ↑

UDP reporting: ↑

Upper threshold (Gonzales): ↑

Visible stat: ↑

Write repeat line (OUT): ↑

Write to file: ↑, ↑, ↑

Write trigger line (IN): ↑

activity type: ↑

auto update ref: ↑

b1<: ↑

backlog: ↑

bookmark1: ↑

bookmark2: ↑

camera framestamp: ↑

camera setup: ↑

camera setup status: ↑

closed, press to reopen (Image Reader): ↑

command accepted: ↑

command line: ↑

crosshair: ↑

datagram: ↑

description (ImageReader): ↑

description text (Gonzales): ↑

dt from end: ↑

dt from start: ↑

dt histogram: ↑

erosions (Gonzales): ↑

event trigger led: ↑

every (Gonzales): ↑

exposure time us: ↑

exposure time us, exp max: ↑

filename (ImageReader): ↑

first frame in movie: ↑

formula label: ↑

formula result: ↑, ↑

formula syntax: ↑

formula to playlist: ↑

fps: ↑

fps max: ↑

frame number (ImageReader): ↑

frame rate (Jog shuttle): ↑

grab fps: ↑

hand: ↑, ↑

hotspot extraction time: ↑

images written: ↑

individual file/sequence files: ↑

last file modification: ↑

line IN status: ↑

line OUT status: ↑

load configuration: ↑

loss log: ↑

lost frames: ↑

lupe: ↑, ↑

movie parameters: ↑

next bookmark activity stretch: ↑, ↑

number of images in queue: ↑

number of images to record: ↑, ↑

open file button (Gonzales): ↑

opened (Image Reader): ↑

optical Write to file mode: ↑

pixel clock: ↑

playlist: ↑

pretrigger time: ↑

previous bookmark activity stretch: ↑, ↑

progressive files: ↑, ↑

queue log: ↑

rectangle: ↑, ↑

reference background image (Gonzales): ↑, ↑

reference image (Gonzales): ↑

roi>big: ↑

routing (OUT): ↑

save configuration: ↑

scan for activity: ↑

scan jump: ↑, ↑

self tracking: ↑, ↑

selftracking delay: ↑

setting led: ↑

show R values: ↑

software framestamp: ↑

software timestamp: ↑

streamfile (Gonzales): ↑, ↑

take as reference: ↑

take as reference (ImageReader): ↑

taps: ↑

the green slider: ↑

the red slider: ↑

the yellow slider: ↑

thresholded difference (ImageReader): ↑

thresholded self: ↑

thresholding: lower, upper, erosions (ImageReader): ↑

time loss percent: ↑

time recorded: ↑

total recording time: ↑

trajectory: ↑

trigger check interval: ↑

write if present in self: ↑

write if trigger: ↑, ↑

write loop fps: ↑

write trigger led: ↑

writing led: ↑, ↑