Support for ITU-R such as BT.709

[HeroicKatora]

Requested features

It would be awesome to have support for the ITU-R Recommendations family of color representations. The primary ones of concern for today are BT.709, BT.2020 and BT.2100 for HD, 4k and high-dynamic range respectively.

Motivation

These are in use by video codes and other media alike, most prominently mpeg using the YCbCr encoding of BT.709. This would lay the ground work for implementing correct consumers and producers of these raw video codecs in rust. Additionally, it would improve the state of interoperability with external libraries such as ffmpeg without sacrificing performance (such as copying/converting image data with another ffi).

Implementation notes

All standards use the same whitepoint and sRGB and BT.709 even use the same primaries. The difference is a slightly changed transfer function and a quantization function for digital output data (8-bit or 10-bit). A different primary configuration is employed by the other two standards as well as a slightly more involved definition of the transfer function but still similar in effect. The same holds for the quantization.

Open questions

There standards are defined for various different bit depths. It is an open question on how this is best mapped to the api. Staying in floating point representation is not enough, as the quantization is not defined as a simple scaling.

References

https://en.wikipedia.org/wiki/Rec._709 http://www.itu.int/rec/R-REC-BT.709-6-201506-I/en https://en.wikipedia.org/wiki/Rec._2020 https://en.wikipedia.org/wiki/Rec._2100

Checklist

• [x] analog YUV color representation
• [ ] accurate standardized, depth dependent YCbCr quantization and encoding
• [x] BT.601
  • [x] both RGB standards
  • [x] YUV difference conversion
  • [x] quantization function
• [x] BT.709
  • [x] RGB standard
  • [x] YUV difference conversion
  • [x] quantization function
• [x] BT.2020
• [x] BT.2100
  • [x] HLG
  • PQ–deferred, see #198

[Ogeon]

That sounds useful. Thanks for the detailed suggestion! I suppose the bit depths can be solved by having a more opaque version that doesn't expose individual channels as properties, but I'm not familiar enough with them to say for sure. If they are only meant for encoding they may not have to be as flexible as RGB, for example. They should at least be implemented as close to specification as possible.

[HeroicKatora]

I've started with 601 and 709 for now expecting 2020 to also be included. I'm not going to attempt Rec.2100 though since I'm not completely sure about the patent situation with regards to both transfer functions and encoded color spaces. Furthermore, it adds to the electro-optical transfer function and its inverse an additional optic-optical transfer function which can either appear before the encoding (applied to linear scene luminance), or after decoding (applied to intended display luminance) depending the chosen model. This seems a bit too complex for the first contribution :)

[Ogeon]

Excellent! And yes, take it in small steps. It's better to iterate than trying to swallow it whole if it's a large effort. Start with the simple ones. You can always submit an early PR if you want feedback!

[Keavon]

With the groundwork from this, could the ACES AP0 and AP1 color spaces be added in the future? I am also wondering about how the SDR vs. HDR color models work and what's involved in converting an sRGB to HDR RGB color space. I understand a key difference is basically whether it's luminance-relative or luminance-absolute, although I don't know how those play into things like ACES or BT.709 and BT.2020/2100 color spaces. Is any of what I mentioned out of scope for the project or could this all be added at some point in the future?

(For context, I'm asking in reference to work on an open source graphics editor project that should ideally support every color visible to the human eye and HDR color for editing things like EXRs.)

[Ogeon]

That looks like a really cool project! I believe it all of what you mention should be possible to some extent. I haven't personally looked into all of the details, so I may miss some technical obstacle, but the current situation is this:

• It's simple to add an extended gamut and transfer functions that work similarly to sRGB. Briefly looking up ACES AP0 and AP1 suggests that they don't have a non-linear format, so it should just be a matter of adding the primaries in that case. That would be a relatively small addition.
• The library doesn't differentiate between SDR and HDR on a type level yet, but we discussed a couple of alternatives in #198. I'm personally leaning towards some sort of Hdr<Color> wrapper type, but we will have to see where it lands. It would be nice if it can be solved in a convenient way.

I'm unfortunately a bit out of my depth regarding HDR and this feature, since I don't have much insight into what's important when working with these formats. That's why much of it rests in the hands of contributors. That said, I'm happy to help fitting it into the rest of the library.