Update osgar/drivers/oak_camera_*.py for new modifiers

[m3d]

follow up after merge of #1069

[m3d]

Note, that I would drop the test ... but OTOH it is expected that they are failing until master is updated ...

[m3d]

Elena's research:
Based on a comprehensive search across the codebase, LogZeroMQ in osgar/drivers/logzeromq.py is the only other module
that dynamically appends modifiers based on a custom JSON configuration variable.

Specifically, it registers 'raw:gz' or 'raw:null' conditionally based on the custom save_data config parameter:

1 # osgar/drivers/logzeromq.py (Line 14)
2 bus.register('raw:gz' if config.get('save_data', False) else 'raw:null', 'response', 'timeout')

Summary of Modifiers in Other Modules:

• Audio (osgar/drivers/audio.py): Statically registers 'audio_data:gz'.
• Realsense (osgar/drivers/realsense.py): Statically registers 'depth:gz' (and dynamically configures stream names
  depending on active device type, but doesn't conditionally append modifiers).
• OAK Camera (Updated): Registered 'depth:gz' directly as a default, removing the custom/non-standard
  compress_depth_stream variable in favor of the unified config-driven modifier system.

[tajgr]

As I wrote, the :gz/:null suffixes should not be used in drivers. If the user needs to ensure lower CPU load, they must check the driver codes to see if there is :gz there or not. In my opinion, it is unsystematic.
I would not say that compressing depth data is generally the "best choice". I did a few tests with a realsense camera (D435) and the load on my PC (CPU) was as follows:
without compression: 17%
with compression 40%.
I had only depth stream enabled, 30 fps, 640x360 resolution.

[m3d]

As I wrote, the :gz/:null suffixes should not be used in drivers. If the user needs to ensure lower CPU load, they must check the driver codes to see if there is :gz there or not. In my opinion, it is unsystematic. I would not say that compressing depth data is generally the "best choice". I did a few tests with a realsense camera (D435) and the load on my PC (CPU) was as follows: without compression: 17% with compression 40%. I had only depth stream enabled, 30 fps, 640x360 resolution.

😄
we are both looking from the opposite extremes ... "only 30fps" 😄 ... in my case, if compression is not enabled it is basically unusable.