[FFmpeg-trac] #7978(undetermined:reopened): inaccurate conversion from YCbCr Narrow range to RGB Full range

[FFmpeg]

#7978: inaccurate conversion from YCbCr Narrow range to RGB Full range
-------------------------------------+-------------------------------------
             Reporter:  cepesh       |                    Owner:  (none)
                 Type:  defect       |                   Status:  reopened
             Priority:  normal       |                Component:
                                     |  undetermined
              Version:  unspecified  |               Resolution:
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Comment (by François-Xavier Thomas):

 I've hit the same issue in https://stackoverflow.com/questions/75260266,
 and found this ticket while trying to answer it, and I was wondering is
 there were anybody currently working on updating this inside ffmpeg? Is
 there any way I can help?

 > I suppose the idea that 10 bit value in png 16 bit per component will be
 just multiply with 64 is wrong.

 At least in my mind, all standards I know of assume 255 (8-bit) = 1023
 (10-bit) = 65535 (16-bit) = 100% = 1.0 (float)...

 For 10-bit signals the multiplication factor should therefore be slightly
 different (65535/1023 = 64.0616...). In binary math I think the closest is
 `(v << 6) + (v >> 4)` with `v` a 10-bit integer).

 (Using a factor of 64 is indeed a common misconception: the roundoff error
 is at most 1 if the final output is downconverted to a smaller integer
 type, so it's not easily visible, especially combined with lossy encoding
 and chroma subsampling.)

 > Now, as described in ITU docs it is normal to use 1020 instead of 1023
 since that is what naïve implementation will give.

 Could you clarify which ITU recommendation (and which version) you were
 referring to, if you still have it?

 At least in the case of ITU-R BT.2020-2, I believe this is an incorrect
 interpretation ; this recommendation only provides specifications for
 narrow-range signals, for which Y'=940 corresponds to 100% signal, and the
 maximum value of 1019 is still valid but maps to a signal that is much
 greater than 100%. It does not cover full-range conversions like what PNG
 images are supposed to contain.

 ITU-R BT.2100 does add an explicit definition for full-range signals,
 where 100% = 1023 (in 10-bit), which seem to correspond to the usual
 assumption that 100% = maximum of the data type.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/7978#comment:10>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker