Re: [V7 31/45] drm/colorop: add BT2020/BT709 OETF and Inverse OETF

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

 



On Thu, 16 Jan 2025 10:56:22 +0200
Pekka Paalanen <pekka.paalanen@xxxxxxxxxxxxx> wrote:

> On Thu, 19 Dec 2024 21:33:37 -0700
> Alex Hung <alex.hung@xxxxxxx> wrote:
> 
> > From: Harry Wentland <harry.wentland@xxxxxxx>
> > 
> > The BT.709 and BT.2020 OETFs are the same, the only difference
> > being that the BT.2020 variant is defined with more precision
> > for 10 and 12-bit per color encodings.
> > 
> > Both are used as encoding functions for video content, and are
> > therefore defined as OETF (opto-electronic transfer function)
> > instead of as EOTF (electro-optical transfer function).
> > 
> > Signed-off-by: Alex Hung <alex.hung@xxxxxxx>
> > Signed-off-by: Harry Wentland <harry.wentland@xxxxxxx>  
> 
> Hi,
> 
> why would a display system ever use BT.2020 or BT.709 OETF or its
> inverse?

Sorry, this is more for my own curiosity, not an argument against the
patch. Since hardware designers decided to incorporate these curves
explicitly, what use was in mind? It's likely something I have
overlooked.


Thanks,
pq

Attachment: pgpIRkkegyCDr.pgp
Description: OpenPGP digital signature


[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