Gamma 2.2 Displays

[janderbrain]

I wanted to reach out regarding potential gamma 2.2 display support.

I was digging through the OCIO config and, as I understand it, everything seems to revolve around using a typical sRGB display device for viewing; i.e. all of the looks move us from the "Filmic Log Encoding" colorspace into a final space for sRGB monitor display.

linear image data -> filmic log colorspace -> magic transform + sRGB gamma correction.

I'm working with an HP DreamColor display which uses a 2.2 gamma curve instead of sRGB.

Have you considered separating the "contrast" looks from the sRGB gamma correction and daisy-chaining them together, or would that somehow defeat the purpose? (It's quite possible I'm missing the entire point of this exercise.)

In an attempt to match the look between Gamma-2.2 and sRGB devices, I'm planning to create a sRGB->Gamma2.2 LUT which I can apply on top of the results to shimmy the values into the DreamColor's working space. The config would wind up looking something like this:

displays:
  sRGB / BT.709:
    - !<View> {name: Standard, colorspace: sRGB EOTF}
    - !<View> {name: Filmic Base Contrast, colorspace: Filmic Log Encoding, look: +Base Contrast}
    ...
  Gamma 2.2:
    - !<View> {name: Standard, colorspace: Gamma 2.2}
    - !<View> {name: Filmic Base Contrast, colorspace: Filmic Log Encoding, look: +Base Contrast,+srgb_to_gamma22}
    ...

In my mind, barring any rounding errors, this would account for the slight difference in the transfer function which mostly affects the final dark values. But I wanted to reach out and get your thoughts in case I'm missing something.

Regards.

[janderbrain]

Just updated my original post as I realized BT.1886 does not have a 2.2 gamma transfer function. I had setup a quick test and tricked myself. The underlying question is still the same though. :)

[sobotka]

Filmic is designed for a pure 2.2 power transfer function display. Unless the Dreamcolor does a precise two part transfer function as per the sRGB OETF specification, it should match perfectly, as it would with all sRGB displays.

If you need to apply a "true" sRGB correction in terms of transfer, you would undo the 2.2 power then apply the sRGB transform. The sRGB 1D LUT included in ACES would be a perfect candidate for this.

Hope this helps. If you require any aid in transforming for a wider gamut etc., feel free to post a subsequent issue.

[janderbrain]

Ah, so I have it backwards in effect.

The looks in this config are designed to be viewed on a pure gamma-2.2 display device and NOT on 2-part sRGB devices. Great, thanks!

Unless the Dreamcolor does a precise two part transfer function as per the sRGB OETF specification, it should match perfectly, as it would with all sRGB displays.

Is this remark implying that the vast majority of "sRGB" display devices actually use a gamma-2.2 transfer function instead of the 2-part definition in the sRGB OETF spec?

Thanks again.

[sobotka]

I believe the vast majority of commodity hardware DACs indeed use a 2.2 power function.

In your case however, with the Dreamcolor, and a potential sRGB emulation mode, it may indeed use the proper sRGB EOTF for inversion. Worth testing. Should be easy to spot with a 1024 greyscale swatch set and a colorimeter / spectrophotometer, and assuming it is a 30 bit panel.

Otherwise, the documentation may reveal the nature of the transfer function?

[janderbrain]

In our case the DreamColors were supposed to use a two-part sRGB EOTF, but after much calibration headbanging and customer support calls, it was confirmed they use a 2.2 gamma.

At any rate, this has certainly been educational and helpful. Thanks again.

[sobotka]

I am going to close this issue. If you need further information or adjustments, let me know.