Is_locked inconsistent between FLIR and Allied Vision with Aravis

1

Hello,

I’m currently developing a camera application using Aravis and I noticed some inconsistent behavior related to the is_locked parameter in ArvGcFeatureNode between FLIR and Allied Vision cameras.

When I connect to a FLIR camera I see certain read-only parameters have is_locked set to true while the camera is grabbing or certain properties are not available at that moment. For ex: If PixelFormat is set to BayerRG8 then Hue and Saturation won’t be writable.

This lets me know when it’s not safe to modify certain settings.

However, with Allied Vision cameras, the is_locked for these parameters are always False.

Questions:

  • Is this a limitation of Aravis, or a reflection of the GenTL or camera’s capabilities?
  • Is there a standard way to detect when parameters are locked in scenarios like this?

Any guidance or best practices for gracefully handling parameter locking across different camera vendors would be much appreciated.

Thank you in advance for your help!

2

Without knowing the specifics (about FLIR and AlliedVision cameras you have), those things are described in the genicam XML which Aravis gets from the camera and interprets. You can use arb-tool to get that XML and inspect it for yourself. If the XML is well written, it will express what the firmware is ready to handle, and should not let you do anything which is unsafe (such as modifying payload length or format while acquiring).

Looking at another camera here (VRmagic), some nodes have <pIsLocked>...</pIsLocked> while others (like acquisition start) might have <pValue>...</pValue> referring to that register.

Not sure if it is best practice, but I ended up with vendor-specific genicam sequences for stages of setup (one just after connecting after connection; one before acquisition starts; one to stop acquisition etc).