[FFmpeg-trac] #9167(undetermined:closed): Color changed when an image converting to video

FFmpeg trac at avcodec.org
Wed Mar 31 03:03:32 EEST 2021

#9167: Color changed when an image converting to video
             Reporter:  kvsico       |                    Owner:
                 Type:  defect       |                   Status:  closed
             Priority:  normal       |                Component:
                                     |  undetermined
              Version:  unspecified  |               Resolution:  invalid
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |

Comment (by pdr0):

 Replying to [comment:15 Balling]:
 > Replying to [comment:14 pdr0]:

 > >How are you defining "superblack" ? <0 RGB in any channel ?
 > No, standard definition: 16, 128, 128 in limited range YCbCr is black.
 If Y is less than 16 than it is superblack. 0 is reserved though, in HDMI
 interface in all components. Not in files AFAIK. So it is 15, 128, 128;
 14, 128, 128; ... 1, 128, 128. If Cb or Cr are not 128 there, it is xvYCC
 already :) Not that superblack is even visible, of course. Only superwhite
 is, on high end devices.

 But a studio range conversion is typically used on TV's (studio range RGB,
 Y 0-255 => RGB 0-255) . Reference black is RGB16,16,16 using studio range
 RGB , reference white is RGB 235,235,235. (this is also called "limited
 range RGB", or "full range equations") . So Y=14,CbCb128 <=> RGB 14,14,14
 . If you look at broadcast standards, EBU r103 etc. this is what they are
 referring to. Consumer TV's vary widely on how they display, and qualtiy,
 but for the most part you can see much better superblack and superwhite
 tones than on a computer monitor

 Computers and monitors typically use computer range RGB conversion (also
 called "full range RGB", or "limited range equations" , Y 16-235 => RGB
 0-255 . Range expansion . Reference black is RGB 0,0,0 there. Indeed Y=14
 and Y=16 both "map" to RGB 0,0,0

 In broadcast and professional video distribution, 0 and 255 are reserved
 for sync. Y,R,G,B So that bmp is "illegal" too, you'd clip to [1,254]
 before you do anything;  but preferred min/max is usually [5,246]

 > Again, that is the point: RGB to YCbCr should not introduce superblack,
 IMHO. But that is just my opinion.

 Ok, but now you're mixing up some concepts :)

 At one point you  were talking about "out of gamut" . It means YCbCr
 values that "map" to negative RGB, or values >255 in 8bit RGB . (In
 broadcast their definition of this range is extended to <1 or >254)

 You don't get "superblack" Y<16  from converting RGB 0,0,0 to YCbCr when
 you use standard range equations

 Using standard range equations, computer 8bit RGB black (0,0,0) to 8bit
 YCbCr conversion should be Y=16,CbCr128

 Using full range equations, studio RGB 8bit (16,16,16)  to 8bit YCbCr
 conversion should also be Y=16,CbCr128 . But notice reference black is at
 16. Black to white is RGB 16-235 in studio range RGB . Black to white is
 RGB 0-255 in computer RGB.

 Note in both cases the YCbCr values are the same, reference black is Y=16,
 reference white is Y=235 in 8bit values

 If you take that bmp , Ymin is 16, Ymax is 235 when you use standard range
 equations to convert RGB to YUV . No "superblack" by your definition

Ticket URL: <https://trac.ffmpeg.org/ticket/9167#comment:16>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list