On Tue, 17 Mar 2026 17:59:27 +0530 "Borah, Chaitanya Kumar" <[email protected]> wrote:
> AFAIU, the block I wanted to represent is Full Range YCbCr -> Full Range > RGB. We have the following configuration in our plane. > > [YUV range correction Block] -> [Degamma LUT] -> [PRESET CSC] -> [Gamma LUT] > > With the legacy "COLOR RANGE" property, selecting limited range enabled > the YUV range correction block. > > I still need to figure out what use-case does the degamma LUT in between > the Range correction block and the Preset CSC serve since YCbCr to RGB > conversion will take place in non-linear domain. But it makes me wonder Hi Chaitanya, yes, that is peculiar indeed. At least "Degamma LUT" is usable with RGB framebuffers. > if we can have "COLOR ENCODING" and "COLOR RANGE" property within the > same colorop like you have been implementing in [1] or should they be > represented by separate colorops. If there is another operation in between (Degamma LUT) that you want to expose, then range-conversion and fixed-matrix operations need to have their own colorops. The chain of colorops cannot go backwards. OTOH, if there is a single hardware operation that does both range-conversion and fixed-matrix, then there is no problem for a driver to translate the pair of colorops into hardware configuration. So it sounds like they should be defined as separate colorops, and then drivers usually expose them together. Unless the hardware cannot do all combinations of their values. Thanks, pq > Uma please weigh in if you have something to add or disagree with. > > == > Chaitanya > > [1] https://gitlab.freedesktop.org/hwentland/linux/-/commits/csc-colorop >
pgp2I5ujblc1o.pgp
Description: OpenPGP digital signature
