Auto exposure limit seems to have a wrong description and error message

[cansik]

RealSense Camera: D455
Firmware Version: 05.13.00.50
pyrealsense2 Version: 2.50.0.3812
Option: option.auto_exposure_limit

It seems that auto-exposure limit seems to work differently from the documentation. If I request the description of it, the framework tells me:

Exposure limit is in microseconds. Default is 0 which means full exposure range. If the requested exposure limit is greater than frame time, it will be set to frame time at runtime. Setting will not take effect until next streaming session.

But the option_range tells me that 0 is not included:

pyrealsense2.option_range: 1-200000/1 [33000]

And if 0.0 is set, a wrong error message is shown (this is not about the Auto Exposure Mode):

RuntimeError: set(enable_auto_exposure) failed! Invalid Auto-Exposure mode request 0.000000

Here a code snippet to test it out yourself:

import pyrealsense2 as rs

ctx: rs.context = rs.context()
device: rs.device = ctx.devices[0]

depth_sensor: rs.depth_sensor = device.first_depth_sensor()

# works because it is in range
depth_sensor.set_option(rs.option.auto_exposure_limit, 500.0)

# does not work and results in a wrong error message
depth_sensor.set_option(rs.option.auto_exposure_limit, 0.0)

It seems like a copy-paste error when implementing this option: https://github.com/IntelRealSense/librealsense/blob/master/src/ds5/ds5-options.cpp#L672

Update

Same problem happens with auto_gain_limit.

[MartyG-RealSense]

Hi @cansik Do you still experience an error with these instructions if you use int values instead of floats (such as 0 instead of 0.0) like in #9018

In that case there was also a problem reported in Python with rs.option.auto_exposure_limit that resulted in the error RuntimeError: object doesn't support option #85, though you do not seem to be experiencing that and it was thought that the error may be specific to Python wrapper installations that were built from a particular wheel version.

[cansik]

@MartyG-RealSense Using a 0 integer leads to the same behaviour, so it is not connected with that problem I guess.

[MartyG-RealSense]

What happens if it is set like this:

import pyrealsense2 as rs
pipeline = rs.pipeline()
profile = pipeline.start()
sensor = profile.get_device().first_depth_sensor()
sensor.set_option(rs.option.enable_auto_exposure, True)
sensor.set_option(rs.option.auto_exposure_limit, 0)

[cansik]

@MartyG-RealSense I already tried first enabling the auto-exposure. But it does not seem to work. Your code results in the same exception:

Traceback (most recent call last):
  File "./tests/RealSenseAutoExposureLimit.py", line 6, in <module>
    sensor.set_option(rs.option.auto_exposure_limit, 0)
RuntimeError: set(enable_auto_exposure) failed! Invalid Auto-Exposure mode request 0.000000

[MartyG-RealSense]

Does setting it to almost zero (1 instead of 0) achieve the desired effect?

[cansik]

@MartyG-RealSense Thank you for your efforts and I don't mean to be rude, but I'm not sure that trying these things will make any difference.

The desired effect would be that if the option is set to 0, the full exposure range would be used by the auto-exposure. If any number above 0 is used, the number will be used as exposure value in microseconds. So a 1.0 would result in a 1μs exposure time (if that is even possible on the hardware side). So no, any number not being 0 does not achieve the desired effect (as described in the documentation).

You can even check it out in the RealSense viewer that the auto-exposure-range limit is not from 0, but from 1-2000000. So to cover the full range we have currently to set it to the max value, instead to 0 which deviates from the documentation. I do not have any problems with this and I do have a workaround by setting it to the max-value, it was just a bit confusing and should be aligned.

In my opinion just the documentation is wrong, not the code itself. Since 2.50.0 there is a toggle option for the limits, which could be used instead of using a range value of 0 and maybe the documentation was not aligned with the code. But that is something the devs of the framework would know more about.

[MartyG-RealSense]

Thanks very much for your detailed feedback. As you already have a solution, the best approach is likely to be to keep this case open and assign it a Documentation label so that it can be reviewed at a future date by a RealSense team member responsible for documentation. Thanks again!