[libcamera-devel,RFC,0/3] Colour spaces
mbox series

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

Message

David Plowman June 8, 2021, 2:44 p.m. UTC 
Hi everyone

At this point I think it's worth having something more specific to
discuss and poke holes in, so I've attached an implementation of
colour spaces. It roughly follows the thoughts I had outlined
previously. Obviously it's a bit rough and ready at the moment, I
don't really want to spend time polishing if we decide to do something
completely different!

Some things to note:

* I've not filled out the necessary documentation - it seems a bit
  early for that!

* I've only included the bare minimum of colour spaces (though these
  probably represent the vast majority of use cases, and certainly all
  the ones the Pi handles).

* It's not unlike V4L2 - it wants to know the YCbCr encoding, the
  transfer function and the range. Though I think there's perhaps a
  discussion to be had about the transfer function (see below).

* We could include "CUSTOM" values for some or all of the fields. So
  for example you might set the YCbCr encoding to "CUSTOM", and then
  the class would have space for a 3x3 matrix you can fill in. (For
  platforms that would support this.)

* It doesn't deal with the CCM which converts sensor RGB to sRGB. We
  already have a control for that. I think this would be enough (at
  least, when a platform lets you set it)?

* How about the transfer (gamma) curve? Should we have a control for
  that, or would it make sense in here? There might be a bigger
  discussion to have about the transfer function - how meaningful is
  it really for cameras? Our gamma curves are always custom, and I
  wonder if other vendors might take the same view.

* I've made the colour space a per-stream thing. If there are
  platforms that can handle this, then it may be unavoidable.
  However, pipeline handlers will have to take care to coerce them
  into whatever combinations they can actually support - which is I
  think where a certain amount of fiddliness will creep in. I've tried
  to illustrate this in the Raspberry Pi implementation, which insists
  on the same colour space on every (non-raw) output.

* There's a slightly weird YCbCr encoding called "VIDEO". This is just
  a placeholder, and gets converted to a real encoding by the
  configure() method, according to the video resolution. This makes it
  easier for the default behaviour to "do the right thing" nearly all
  the time - so that applications rarely even have to consider colour
  spaces.

That's probably enough to get us going, so comments and discussion are
most welcome!

Thanks
David

David Plowman (3):
  libcamera: Add ColorSpace class
  libcamera: Support passing ColorSpaces to V4L2 drivers
  libcamera: pipeline: raspberrypi: Support colour spaces

 include/libcamera/color_space.h               |  94 +++++++++++++++
 include/libcamera/internal/v4l2_videodevice.h |   2 +
 include/libcamera/meson.build                 |   1 +
 include/libcamera/stream.h                    |   3 +
 src/libcamera/color_space.cpp                 |  43 +++++++
 src/libcamera/meson.build                     |   1 +
 .../pipeline/raspberrypi/raspberrypi.cpp      |  84 +++++++++++++
 src/libcamera/v4l2_videodevice.cpp            | 112 ++++++++++++++++++
 8 files changed, 340 insertions(+)
 create mode 100644 include/libcamera/color_space.h
 create mode 100644 src/libcamera/color_space.cpp