Re: per-plane LUTs and CSCs?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 2020-09-10 1:51 p.m., Laurent Pinchart wrote:
Hi Vitaly,

On Thu, Sep 10, 2020 at 01:09:03PM -0400, Vitaly Prosyak wrote:
On 2020-09-10 6:56 a.m., Laurent Pinchart wrote:
On Thu, Sep 10, 2020 at 01:28:03PM +0300, Pekka Paalanen wrote:
On Thu, 10 Sep 2020 12:30:09 +0300 Laurentiu Palcu wrote:
On Thu, Sep 10, 2020 at 11:50:26AM +0300, Pekka Paalanen wrote:
On Thu, 10 Sep 2020 09:52:26 +0200 Daniel Vetter wrote:
On Thu, Sep 10, 2020 at 10:25:43AM +0300, Pekka Paalanen wrote:
On Wed, 9 Sep 2020 13:57:28 +0300 Laurentiu Palcu wrote:
     
Hi all,

I was wondering whether you could give me an advise on how to proceed further
with the following issue as I'm preparing to upstream the next set of patches
for the iMX8MQ display controller(DCSS). The display controller has 3 planes,
each with 2 CSCs and one degamma LUT. The CSCs are in front and after the LUT
respectively. Then the output from those 3 pipes is blended together and then
gamma correction is applied using a linear-to-nonlinear LUT and another CSC, if
needed.
Hi,

hmm, so FB -> CSC -> LUT -> CSC -> blending?

Is it then
	blending -> LUT -> CSC -> encoder
or
	blending -> CSC -> LUT -> encoder?
The DCSS pipeline topology is this:

FB1->CSC_A->LUT->CSC_B-\
FB2->CSC_A->LUT->CSC_B-|-blender->LUT->CSC_O->encoder
FB3->CSC_A->LUT->CSC_B-/

Basically, CSC_A is used to convert to a common colorspace if needed
(YUV->RGB) as well as to perform pixel range conversions: limited->full.
CSC_B is for gamut conversions(like 709->2020). The CSC_O is used to
convert to the colorspace used by the output (like RGB->YUV).
I didn't realize that it would be correct to do RGB-YUV conversion in
non-linear space, but yeah, that's what most software do too I guess.

Are all these LUTs per-channel 1D LUTs or something else?
LUTs are 3D, per pixel component.
Sorry, which one?

An example of a 3D LUT is 32x32x32 entries with each entry being a
triplet, while a 1D LUT could be 1024 entries with each entry being a
scalar. 1D LUTs are used per-channel so you need three of them, 3D LUTs
you need just one for the color value triplet mapping.

A 3D LUT can express much more than a 4x4 CTM. A 1D LUT cannot do the
channel mixing that a CTM can.

So if you truly have 3D LUTs everywhere, I wonder why the CSC matrix
blocks exist...
Possibly because the 3D LUT uses interpolation (it's a 17x17x17 LUT in
R-Car), having a separate CSC can give more precision (as well as
allowing the two problems to be decoupled, at a relatively low hardware
cost).
If you put nonlinear signal to 3DLUT then your
precision would be improved.
How many bits each color value has in 3DLUT ?
The whole display pipeline uses 8 bits per component.
It is pretty low , please, use always nonlinear signal in the pipe and it allows you to compress and 'win' about 2 bits.

    
--
[AMD Official Use Only - Internal Distribution Only]
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux