Frames sequence becomes unordered when hardware region-or-interest reduced from maximum

[astraw]

An email on the mailing list (2011-10-07) from Tony Yu:

Apologies if this doesn't show up as part of the original thread: I just signed up for the email list, so I just copied the subject title.

I guess this doesn't add much of a clue, but I see the same issue with (probably) the same configuration---I also have a Prosilica GX. A couple of additional clues: I've noticed that the ordering error varies with the buffer size. And also, the problem is persistent: changing the ROI raises the issue, but changing it back to full frame does not correct the issue.

Regardless, the timestamps for the frames is correct, so this allows you to reorder the frames fairly easily.

Best,
-TSY

[tonysyu]

I just wanted to add some details to this issue.

After changing the region-of-interest, the frames are out of order, but they're all saved correctly (the frames themselves don't get garbled). If I set the camera to buffer 3 frames and print out the frame number when it's grabbed (in fview.grab_func), I get something like

3 1 2 4 5 6 8 9 7 12 10 11 13 14 15 17 18 16 ...

This probably isn't helpful, but to me it looks like the frame numbers have the following pattern:

312
123
231
312
123
231
...

I don't quite understand how the image buffer is implemented, but it looks to be some combination of BACKEND_GLOBAL(frames_ready_*) variables (in cam_iface_prosilica_gige.cpp), where * is one of list_cam0, cam0_read_idx, cam0_write_idx, and cam0_num. My guess is that something is strange with the read and write indexes.

Also, there are a couple of not-so-great work arounds. Setting the number of framebuffers to 1 works since the code can't get confused about which buffer to grab from / write to. And just sorting the frames of the saved *.fmf file will work as well.