On Tue, 9 May 2023 10:23:49 -0100
Melissa Wen <mwen@igalia.com> wrote:

> On 05/05, Joshua Ashton wrote:
> > Some corrections and replies inline.
> > 
> > On Fri, 5 May 2023 at 12:42, Pekka Paalanen <ppaalanen@gmail.com> wrote:  
> > >
> > > On Thu, 04 May 2023 15:22:59 +0000
> > > Simon Ser <contact@emersion.fr> wrote:
> > >  

...

> > > >     Color operation 47 (3D LUT RAM)
> > > >     └─ "lut_data" = Gamut mapping + tone mapping + night mode
> > > >     Color operation 48 (blend gamma)
> > > >     └─ "1d_curve_type" = PQ  
> > 
> > ^
> > This is wrong, this should be Display Native -> Linearized Display Referred  
> 
> This is a good point to discuss. I understand for the HDR10 case that we
> are just setting an enumerated TF (that is PQ for this case - correct me
> if I got it wrong) but, unlike when we use a user-LUT, we don't know
> from the API that this enumerated TF value with an empty LUT is used for
> linearizing/degamma. Perhaps this could come as a pair? Any idea?

PQ curve is an EOTF, so it's always from electrical to optical.

Are you asking for something like

"1d_curve_type" = "PQ EOTF"

vs.

"1d_curve_type" = "inverse PQ EOTF"?

I think that's how it should work. It's not a given that if a
hardware block can do a curve, it can also do its inverse. They need to
be advertised explicitly.


Thanks,
pq

ps. I picked my nick in the 90s. Any resemblance to Perceptual
Quantizer is unintended. ;-)


> > >
> > > You cannot do a TF with a matrix, and a gamut remap with a matrix on
> > > electrical values is certainly surprising, so the example here is a
> > > bit odd, but I don't think that hurts the intention of demonstration.  
> > 
> > I have done some corrections inline.
> > 
> > You can see our fully correct color pipeline here:
> > https://raw.githubusercontent.com/ValveSoftware/gamescope/master/src/docs/Steam%20Deck%20Display%20Pipeline.png
> > 
> > Please let me know if you have any more questions about our color pipeline.