[libcamera-devel,v3,0/7] Colour spaces
mbox series

Message ID 20211020110825.12902-1-david.plowman@raspberrypi.com
Headers show
Series
  • Colour spaces
Related show

Message

David Plowman Oct. 20, 2021, 11:08 a.m. UTC
Hi everyone

Here's a new version of the colour space patches. A huge amount has
changed, even since I last discussed it with folks!

1. The ColorSpace class

There's a ColorSpace class with 4 enums, one for each of: the colour
primaries, the Y'CbCr encoding, the transfer function and the range
(quantisation).

Notes:

- There are no "default" values at all. Every standard colour space
  has a unique representation in terms of these enums.

- But each enum does have an "undefined" value, in case a driver
  framework (such as V4L2) uses something that the ColorSpace class
  does not recognise.

- It's conceivable that the class could be extended in future by using
  a "custom" enum value and then adding further fields (such as colour
  primaries or transfer functions). But this is out-of-scope for now.

2. Stream configurations

The StreamConfiguration contains two ColorSpace fields, the one an
application wants (the "requested" colour space) and the one it will
get (the "actual" colour space), which is filled in by the validate()
method.

Notes:

- The requested colour space may never contain "undefined" values,
  though the actual colour space, returned by the system, may.

- The reason for having two fields is so that we don't change the
  requested colour space, which would make the configuration harder to
  use later, or to change and re-validate.

- I've moved away from allowing colour spaces to be "unset". I couldn't
  really figure out how this would play nicely with validate() and
  configure(), and it does make the whole thing easier to understand.

3. Pipeline handlers

In generateConfiguration, pipeline handlers should set
ColorSpace::Jpeg for stills and ColorSpace::Rec709 for
video. Application code must be aware of this, and overwrite these
values if they want something different. Then validate() should call
the new validateColorSpaces method which checks the requested colour
spaces. Ideally, pipeline handlers will then go on to verify whether
the requested colour spaces are actually supported.

As regards ipu3/rkisp1, I can easily add commits for those first
simple changes if it would be helpful. Beyond that, verifying what the
hardware will really do is probably best left to someone who
understands those pipelines!

Thanks, and sorry that this is all so long!

David

David Plowman (7):
  libcamera: Add ColorSpace class
  libcamera: Add ColorSpace fields to StreamConfiguration
  libcamera: Convert between ColorSpace class and V4L2 formats
  libcamera: Support passing ColorSpaces to V4L2 video devices
  libcamera: Support passing ColorSpaces to V4L2 subdevices
  libcamera: Add validateColorSpaces to CameraConfiguration class
  libcamera: pipeline: raspberrypi: Support color spaces

 include/libcamera/camera.h                    |   2 +
 include/libcamera/color_space.h               |  88 ++++++
 include/libcamera/internal/v4l2_device.h      |   7 +
 include/libcamera/internal/v4l2_subdevice.h   |   2 +
 include/libcamera/internal/v4l2_videodevice.h |   2 +
 include/libcamera/meson.build                 |   1 +
 include/libcamera/stream.h                    |   4 +
 src/libcamera/camera.cpp                      |  53 ++++
 src/libcamera/camera_sensor.cpp               |   1 +
 src/libcamera/color_space.cpp                 | 256 ++++++++++++++++++
 src/libcamera/meson.build                     |   1 +
 .../pipeline/raspberrypi/raspberrypi.cpp      |  42 +++
 src/libcamera/stream.cpp                      |  25 ++
 src/libcamera/v4l2_device.cpp                 | 171 ++++++++++++
 src/libcamera/v4l2_subdevice.cpp              |  37 ++-
 src/libcamera/v4l2_videodevice.cpp            |  69 ++++-
 16 files changed, 755 insertions(+), 6 deletions(-)
 create mode 100644 include/libcamera/color_space.h
 create mode 100644 src/libcamera/color_space.cpp