[FFmpeg-trac] #11182(swscale:closed): yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference

[FFmpeg]

#11182: yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference
-------------------------------------+-------------------------------------
             Reporter:  Andrew-R     |                    Owner:  (none)
                 Type:  defect       |                   Status:  closed
             Priority:  normal       |                Component:  swscale
              Version:  unspecified  |               Resolution:  invalid
             Keywords:  colorspace   |               Blocked By:
  color_primaries                    |
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Comment (by Andrew-R):

 Replying to [comment:35 Balling]:
 > >Honestly, until now I was under impression RGB was superset of YUV, not
 other way around ... I was wrong!
 >
 > You just read one small text in
 ​https://stackoverflow.com/questions/17892346/how-to-convert-rgb-yuv-rgb-
 both-ways "Since the 8 bit YUV only uses Y values [16, 235] and U, V
 values [16, 240] it has less possible colors than RGB using [0, 255].",
 which is simply not true, there is a comment from me under that answer
 that says: It is not on any flagship TV. If you send YCbCr it will show
 superwhite and supercolors no problem. In some cases even xvYCC. LG C9
 does it even in internal files player."


 Hm, well, I guess I just confused usual chroma subsampling and associated
 loss of information with colorspace itself.

 There is post titled "U and V ranges for valid RGB" from 2010, it has
 animated illustration.

 https://forum.doom9.org/showthread.php?t=154731


 ffmpeg -i /dev/shm/yuv-mpeg-yuv444p.y4m -vf
 "signalstats,metadata=print:file=logfile.txt" -f null /dev/null

 from logfile it says
 {{{
 frame:0    pts:0       pts_time:0
 lavfi.signalstats.YMIN=0
 lavfi.signalstats.YLOW=76
 lavfi.signalstats.YAVG=127.733
 lavfi.signalstats.YHIGH=178
 lavfi.signalstats.YMAX=255
 lavfi.signalstats.UMIN=0
 lavfi.signalstats.ULOW=76
 lavfi.signalstats.UAVG=127.733
 lavfi.signalstats.UHIGH=178
 lavfi.signalstats.UMAX=255
 lavfi.signalstats.VMIN=0
 lavfi.signalstats.VLOW=76
 lavfi.signalstats.VAVG=127.733
 lavfi.signalstats.VHIGH=178
 lavfi.signalstats.VMAX=255



 }}}


 so full-range y4m file from yuvtestsrc contain all Y, U, V values (as
 requested!), even illegal (for RGB conversion later on) ones?

 But then one method to kill illegal colors in yuv was said to be to
 convert it to rgb and back ....

 Not sure how specific figure in YUView should look for invalid colors
 after such roundtrip? Right now it still look like limited range
 conversion was applied twice at the end of range?
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/11182#comment:36>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker