Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

invalid default FrameDurationLimits #238

Open
christianrauch opened this issue Feb 10, 2025 · 1 comment
Open

invalid default FrameDurationLimits #238

christianrauch opened this issue Feb 10, 2025 · 1 comment

Comments

@christianrauch
Copy link
Contributor

In v0.4.0+rpt20250127 the default FrameDurationLimits was unset and reported as <ValueType Error>. Since v0.4.0+rpt20250210, the default is reported as 33333 µs.

Since FrameDurationLimits is a span with two elements (lower and upper frame duration bounds in microseconds), there is no sensible scalar mapping of the scalar default to the bounds.

How is the scalar default to be interpreted for the array control? Are the lower and upper bounds supposed to be set to the default value of 33333? This means that the frame duration would be fixed to 33.333 ms (30Hz), effectively disabling any auto exposure etc. What is the motivation of forcing the frame duration to a fixed value of 33ms?

@naushir
Copy link
Collaborator

naushir commented Feb 11, 2025

In v0.4.0+rpt20250127 the default FrameDurationLimits was unset and reported as . Since v0.4.0+rpt20250210, the default is reported as 33333 µs.

This was done to fix an issue with libcameraify expecting a default value for FrameDurationLimits: #235 (comment)

There's no mechanism to set a span as a default value in the libcamera control API. To workaround this, take the scaler default value as the min/max value of the FrameDurationLimits span,. However, this may not be applicable to other span controls. Again, this is all under discussion as mentioned in #237.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants