On Tue, 9 May 2023 10:23:49 -0100 Melissa Wen <mwen@xxxxxxxxxx> wrote: > On 05/05, Joshua Ashton wrote: > > Some corrections and replies inline. > > > > On Fri, 5 May 2023 at 12:42, Pekka Paalanen <ppaalanen@xxxxxxxxx> wrote: > > > > > > On Thu, 04 May 2023 15:22:59 +0000 > > > Simon Ser <contact@xxxxxxxxxxx> 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.
Attachment:
pgp7zQ_kyJ12Q.pgp
Description: OpenPGP digital signature
