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

Support libcamera's new SensorConfiguration #560

Merged
merged 2 commits into from
Oct 4, 2023
Merged

Support libcamera's new SensorConfiguration #560

merged 2 commits into from
Oct 4, 2023

Conversation

davidplowman
Copy link
Collaborator

This commit adds support for the new SensorConfiguration within libcamera's CameraConfiguration object. We have to use this now to force the choice of particular sensor modes in case of future extensions where the raw stream format is no longer sufficient.

There are quite a few changes:

  1. We now populate the list of sensor modes always, even when no framerate was given. Though we don't fill in the mode's framerate unless that's going to be something we use to select the mode.

  2. The selectModeForFramerate function has been generalised and turned into selectMode. This now supports mode selection based on width, height, bitrate as well as (optionally) framerate.

  3. Raw streams are always requested now, as this means we always get the same buffer management behaviour. It also simplifies the code slightly.

  4. We always fill in a Mode structure (using the user's values if given) that we can pass to the amended selectMode function. This will return the correct sensor mode for us, that we can use to program the SensorConfiguration. So a SensorConfiguration is now always supplied to libcamera.

  5. Everywhere where the code was running through the available modes and configuring them, it has been amended to program the SensorConfiguration too - otherwise you may not be able to get non-default bit-depths. To make this easier, the SensorMode class has been made public.

  6. The "rawfull" option has been removed. It was only ever a temporary hack from the very early days, and trying to keep it seems to add more complexity that would be warranted.

@davidplowman
Copy link
Collaborator Author

@naushir Not to be merged until SensorConfigurations have been committed into libcamera!

This commit should preserve existing behaviour where it finds the best matching mode when a raw mode is requested, and tries to simplify the configuration process a bit. Obviously it won't compile until those libcamera updates have happened.

@davidplowman davidplowman force-pushed the sensor-config branch 2 times, most recently from 6b81662 to 23f971e Compare October 4, 2023 14:00
This commit adds support for the new SensorConfiguration within
libcamera's CameraConfiguration object. We have to use this now to
force the choice of particular sensor modes in case of future
extensions where the raw stream format is no longer sufficient.

There are quite a few changes:

1. We now populate the list of sensor modes always, even when no
framerate was given. Though we don't fill in the mode's framerate
unless that's going to be something we use to select the mode.

2. The selectModeForFramerate function has been generalised and turned
into selectMode. This now supports mode selection based on width,
height, bitrate as well as (optionally) framerate.

3. Raw streams are always requested now, as this means we always get
the same buffer management behaviour. It also simplifies the code
slightly.

4. We always fill in a Mode structure (using the user's values if
given) that we can pass to the amended selectMode function. This will
return the correct sensor mode for us, that we can use to program the
SensorConfiguration. So a SensorConfiguration is now always supplied
to libcamera.

5. Everywhere where the code was running through the available modes
and configuring them, it has been amended to program the
SensorConfiguration too - otherwise you may not be able to get
non-default bit-depths. To make this easier, the SensorMode class has
been made public.

6. The "rawfull" option has been removed. It was only ever a temporary
hack from the very early days, and trying to keep it seems to add more
complexity that would be warranted.

Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
When we receive a compressed buffer we decompress it in software so
that it can be written to the DNG file.

Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
@davidplowman
Copy link
Collaborator Author

@naushir I think this is actually good now, test failures notwithstanding. Obviously those can't work until they're running on a libcamera that includes sensor configurations.

I've also added a 2nd commit to write DNGs using compressed raw formats as well.

@naushir naushir merged commit a85aed7 into main Oct 4, 2023
1 of 7 checks passed
@naushir naushir deleted the sensor-config branch October 19, 2023 14:06
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

Successfully merging this pull request may close these issues.

None yet

2 participants