Workaround for BlackFly U16 pixel endianness issues

[berke]

Proposed solution for the endianness problem discussed here: #921

ArvCamera detects devices known to have pixel endianness issues using a model/vendor table, the result can be queried through arv_camera_has_incorrect_pixel_endianness. This is used by the viewer to byte-swap pixels.

Shortcomings:

• It would be better to do the byte-swapping transparently in aravis as the packets are received and not in the viewer
• The user should be able to control the table of devices without having to recompile Aravis, or at least specify an option to activate the fix
• This code assumes the machine is little endian
• Code not optimized for the case where the rows have to be aligned AND the pixels byte-swapped
• Only handles MONO_U16

[EmmanuelP]

Hi,

Thanks for your work.

I would not implement the byte swapping, gstreamer can do that for us, and possibly more efficiently. Also, your code will not work on big endian platform. I'm also not fond in exposing an API for a kludge.

Please move the camera list to arvmisc, and select the right gstreamer caps based on it there.

Emmanuel.

[berke]

Please move the camera list to arvmisc, and select the right gstreamer caps based on it there.

Done, see #923