On Fri, 15 Aug 2025 21:28:47 -0600 Alex Hung <alex.h...@amd.com> wrote:
> On 8/15/25 20:45, Shengyu Qu wrote: > > Hi, > > > > Thanks for reply. I guess we need to point this out in documentation or > > code comment? As I can see different definition somewhere like this[1]. > > > > Best regards, > > Shengyu > > > > [1] https://color.org/chardata/rgb/BT2020.xalter > > It's the same one. You can find the ITU document in "Documentation > source" in above link. Hi, I sense confusion, because color.org quotes BT.1886 explicitly in > Color component transfer function: C'= C^1/2.4 which is not the BT.2020 OETF (nor it's inverse, nor approximation). > >> > >> https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.2020-2-201510-I!! > >> PDF-E.pdf (Table 4?) says E' = 4.5 * E, for 0 <= E < β E' = α * E^0.45 - (α - 1), for β <= E <= 1 with α = 1.09929682680944... and β = 0.018053968510807.. The footnote for that table: > (4) In typical production practice the encoding function of image > sources is adjusted so that the final picture has the desired look, > as viewed on a reference monitor having the reference decoding > function of Recommendation ITU-R BT.1886, in the reference viewing > environment defined in Recommendation ITU-R BT.2035. In other words, the common practice is to not use the specified curve. As we can see in https://www.desmos.com/calculator/gqjuzqsebg the two curves do not even approximate each other. However, for someone familiar with the specifications BT.2020 and BT.1886, the two curves are distinctly named. BT.2020 defines the OETF, and BT.1886 defines the EOTF. Inverse of one does not match the other deliberately. The mismatch between the camera curve and the display curve is required to make the picture look better. When someone says "BT.2020 OETF", it is unambiguous. It's the only curve actually specified in BT.2020. Thanks, pq
pgp4QbicH7Uhp.pgp
Description: OpenPGP digital signature
