#3801(undetermined:new): SWSCALE: Incorrect Values in Full Range Conversion RGB to YCbCr
#3801: SWSCALE: Incorrect Values in Full Range Conversion RGB to YCbCr -------------------------------------+------------------------------------- Reporter: troy_s | Type: defect Status: new | Priority: normal Component: | Version: undetermined | unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: FFMPEG is potentially delivering values that deviate from theoretical results in RGB to YCbCr conversions. This case applies to RGB to full range YCbCr conversion, using REC.709 coefficients on the input. {{{ ./ffmpeg -i ~/Documents/FFMPEG\ Color\ Research/ARIB_STD-B28.png -pix_fmt yuv444p -vcodec rawvideo -f rawvideo -vf scale="in_range=full:in_color_matrix=bt709:out_range=full:out_color_matrix=bt709" test-full.yuv ffmpeg version N-64958-gce8e27e Copyright (c) 2000-2014 the FFmpeg developers built on Jul 24 2014 10:54:07 with gcc 4.7 (Ubuntu/Linaro 4.7.3-12ubuntu1) configuration: --enable-gpl --enable-libx264 --enable-shared --disable- static --enable-pic WARNING: library configuration mismatch avutil configuration: --enable-gpl --enable-libx264 --disable-asm --enable-shared --disable-static --enable-pic avcodec configuration: --enable-gpl --enable-libx264 --disable-asm --enable-shared --disable-static --enable-pic avformat configuration: --enable-gpl --enable-libx264 --disable-asm --enable-shared --disable-static --enable-pic avdevice configuration: --enable-gpl --enable-libx264 --disable-asm --enable-shared --disable-static --enable-pic avfilter configuration: --enable-gpl --enable-libx264 --disable-asm --enable-shared --disable-static --enable-pic swscale configuration: --enable-gpl --enable-libx264 --disable-asm --enable-shared --disable-static --enable-pic swresample configuration: --enable-gpl --enable-libx264 --disable-asm --enable-shared --disable-static --enable-pic postproc configuration: --enable-gpl --enable-libx264 --disable-asm --enable-shared --disable-static --enable-pic libavutil 52. 92.101 / 52. 92.101 libavcodec 55. 69.100 / 55. 69.100 libavformat 55. 49.100 / 55. 49.100 libavdevice 55. 13.102 / 55. 13.102 libavfilter 4. 11.102 / 4. 11.102 libswscale 2. 6.100 / 2. 6.100 libswresample 0. 19.100 / 0. 19.100 libpostproc 52. 3.100 / 52. 3.100 Input #0, image2, from '/home/aphorism/Documents/FFMPEG Color Research/ARIB_STD-B28.png': Duration: 00:00:00.04, start: 0.000000, bitrate: N/A Stream #0:0: Video: png, rgb24, 1920x1080 [SAR 2835:2835 DAR 16:9], 25 tbr, 25 tbn, 25 tbc Output #0, rawvideo, to 'test-full.yuv': Metadata: encoder : Lavf55.49.100 Stream #0:0: Video: rawvideo (444P / 0x50343434), yuv444p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc Metadata: encoder : Lavc55.69.100 rawvideo Stream mapping: Stream #0:0 -> #0:0 (png (native) -> rawvideo (native)) Press [q] to stop, [?] for help frame= 1 fps=0.0 q=0.0 Lsize= 6075kB time=00:00:00.04 bitrate=1244160.0kbits/s video:6075kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000% }}} The above command delivers the attachment test-full-444-out.png, with Y, Cb, and Cr a pure dump of the results into the R, G, and B channels of the image. No color transformations have been applied. The file ARIB_STD-B28.png is an 8 bit representation of a SMPTE test pattern, based off of a 32 bit float version. The file ARIB_STD-B28_YCbCr_full.png is a theoretically correct transformation of the ARIB_STD-B28.png test pattern into YCbCr using REC.709 coefficients. It is based off of a 32 bit EXR input. The file test-full-diff.png is a heat-map difference, with red areas indicating deviations between the theoretical results and the actual. The SMPTE test pattern black set test stripes at the very bottom contain one stripe that sources at -2%, and as such, will always be incorrect unless float values are provided for input. As such, it is the single bar that can be ignored. Potentially Related Issues: https://trac.ffmpeg.org/ticket/3794 -- Ticket URL: <https://trac.ffmpeg.org/ticket/3801> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3801: SWSCALE: Incorrect Values in Full Range Conversion RGB to YCbCr -------------------------------------+------------------------------------- Reporter: troy_s | Owner: Type: defect | Status: new Priority: normal | Component: Version: unspecified | undetermined Keywords: range | Resolution: Blocking: | Blocked By: Analyzed by developer: 0 | Reproduced by developer: 0 -------------------------------------+------------------------------------- Changes (by cehoyos): * keywords: => range -- Ticket URL: <https://trac.ffmpeg.org/ticket/3801#comment:1> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3801: SWSCALE: Incorrect Values in Full Range Conversion RGB to YCbCr -------------------------------------+------------------------------------- Reporter: troy_s | Owner: Type: defect | Status: closed Priority: normal | Component: Version: unspecified | undetermined Keywords: range | Resolution: invalid Blocking: | Blocked By: Analyzed by developer: 0 | Reproduced by developer: 0 -------------------------------------+------------------------------------- Changes (by michael): * status: new => closed * resolution: => invalid Comment: The 2 png images are nearly identical, i see some +-1 differences from different rounding, which is clearly not what was meant in this bug, though if our rounding is suboptimal then such suboptmal rounding of course would be a bug that iam interrested in. The big vissible color difference is a fault in how the file was created, one of the pngs has a gamma of 1.0 the other does not. firefox displays them quite differently, other software shows them nearly identical, ignoring gamma i assume xview, displays this difference: ARIB_STD-B28_YCbCr_full.png is 1920x1080 PNG image, color type RGB, 8 bit test-full-444-out.png is 1920x1080 PNG image, color type RGB, 8 bit, file gamma 1.0000 Also the difference png shows massive differences in areas that are bit exactly identical -- Ticket URL: <https://trac.ffmpeg.org/ticket/3801#comment:2> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3801: SWSCALE: Incorrect Values in Full Range Conversion RGB to YCbCr -------------------------------------+------------------------------------- Reporter: troy_s | Owner: Type: defect | Status: closed Priority: normal | Component: Version: unspecified | undetermined Keywords: range | Resolution: invalid Blocking: | Blocked By: Analyzed by developer: 0 | Reproduced by developer: 0 -------------------------------------+------------------------------------- Comment (by troy_s): The rounding is the issue, and I can assure you that all of the values per channel were encoded 1:1. The reason a gamma of 1.0 was assigned is likely due to that being required to prevent the PNG color mangling. I could provide raw files, but that is vastly less easy to diagnose. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3801#comment:3> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3801: SWSCALE: Incorrect Values (+-1) in Full Range Conversion RGB to YCbCr -------------------------------------+------------------------------------- Reporter: troy_s | Owner: Type: defect | Status: reopened Priority: normal | Component: Version: unspecified | undetermined Keywords: range | Resolution: Blocking: | Blocked By: Analyzed by developer: 0 | Reproduced by developer: 0 -------------------------------------+------------------------------------- Changes (by michael): * status: closed => reopened * resolution: invalid => -- Ticket URL: <https://trac.ffmpeg.org/ticket/3801#comment:4> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3801: SWSCALE: Incorrect Values (+-1) in Full Range Conversion RGB to YCbCr -------------------------------------+------------------------------------- Reporter: troy_s | Owner: Type: defect | Status: reopened Priority: normal | Component: Version: unspecified | undetermined Keywords: range | Resolution: Blocking: | Blocked By: Analyzed by developer: 0 | Reproduced by developer: 0 -------------------------------------+------------------------------------- Comment (by michael): ffmpeg output vs. the reference: stddev: 0.39 PSNR: 56.28 MAXDIFF: 1 bytes: 6220800/ 6220800 -- Ticket URL: <https://trac.ffmpeg.org/ticket/3801#comment:5> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3801: SWSCALE: Incorrect Values (+-1) in Full Range Conversion RGB to YCbCr -------------------------------------+------------------------------------- Reporter: troy_s | Owner: (none) Type: defect | Status: reopened Priority: normal | Component: | undetermined Version: unspecified | Resolution: Keywords: range | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Balling): Well, you know what. First of all, you must have specified that the file should be opened with ffplay -video_size 1920x1080 -pixel_format yuvj444p -f rawvideo -i ARIB_STD-B28_YCbCr_full.yuv -vf scale=in_color_matrix=bt709 Second of all, it uses range full YCbCr values, as can be checked using ffplay -video_size 1920x1080 -pixel_format yuv444p -f rawvideo -i ARIB_STD-B28_YCbCr_full.yuv (see black that is 0 in Y). Here it does not matter '''yuvj444p or yuv444p''' we are using, BTW! That is why "contain one stripe that sources at -2%" will be just not included for full range. But ARIB B28 never specified full range YCbCr format... Just like SMPTE RP 219. Also looks like the 100 red and blue are not actually 100% or it is just a bug somewhere... They are RGB 254, not 255. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3801#comment:6> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3801: SWSCALE: Incorrect Values (+-1) in Full Range Conversion RGB to YCbCr -------------------------------------+------------------------------------- Reporter: troy_s | Owner: (none) Type: defect | Status: reopened Priority: normal | Component: | undetermined Version: unspecified | Resolution: Keywords: range | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Balling): Right, so test-full-444-out.png has 1.0 gAMA png chunk. How beautiful. You know that Photoshop, Paint and GIMP until my fixes and FFmpeg do not support gAMA or cHRM chunks? While Chrome, Mozilla and Windows photo viewer do support it? Let me guess, considering your ramp from 0 to 255 uses 186 as Cb=Cr with applying gAMA, gAMA of 1.0 is actually NOT CORRECT, because without applying it (and falling back to sRGB) it will be 128 for Cb=Cr??? WTF. Are you serious right now? Okay, whatever. P.S. test-full- diff.png​ also has 1.0 gAMA. That means you do understand PNG spec or gAMA too. Wow, just wow. exiftool test-full-444-out.png [Color Type : RGB Compression : Deflate/Inflate Filter : Adaptive Interlace : Noninterlaced Gamma : 1 Background Color : 255 255 255 Pixels Per Unit X : 72 Pixels Per Unit Y : 72 Pixel Units : Unknown] So I need to remove gAMA with pngcrush -m 3 -rem gAMA: -- Ticket URL: <https://trac.ffmpeg.org/ticket/3801#comment:7> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3801: SWSCALE: Incorrect Values (+-1) in Full Range Conversion RGB to YCbCr -------------------------------------+------------------------------------- Reporter: troy_s | Owner: (none) Type: defect | Status: reopened Priority: normal | Component: | undetermined Version: unspecified | Resolution: Keywords: range | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Changes (by Balling): * Attachment "test-full-444-out-no-gAMA.png" added. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3801> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3801: SWSCALE: Incorrect Values (+-1) in Full Range Conversion RGB to YCbCr -------------------------------------+------------------------------------- Reporter: troy_s | Owner: (none) Type: defect | Status: open Priority: normal | Component: | undetermined Version: unspecified | Resolution: Keywords: range | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Changes (by Balling): * status: reopened => open Comment: And here are first results. ffplay -video_size 1920x1080 -pixel_format yuv444p -f rawvideo -i ARIB_STD-B28_YCbCr_full.yuv -vf extractplanes=y shows that 75% Cyan is 151, 149, 32 while it should be (at least according to you) as in png 150, 150, 32, NICE! Next, 75% blue is supposed to be 14, 224, 119 but it is 14, 223, 119 (DAH). Next: 75 % magenta is supposed to be 54, 202, 215 but actually it is 54, 201, 214. Next 100% Red is supposed to be 54, 99, 255 but it is actually 54, 98, 255 (which causes that 254 issue). 100% yellow is supposed to be 237, 0, 140 but is actually 237, 0, 139 (again, 254 issue). And finally 75% yellow is supposed to be 177, 32, 137 but it is actually 177, 32, 136. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3801#comment:8> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3801: SWSCALE: Incorrect Values (+-1) in Full Range Conversion RGB to YCbCr -------------------------------------+------------------------------------- Reporter: troy_s | Owner: (none) Type: defect | Status: open Priority: normal | Component: | undetermined Version: unspecified | Resolution: Keywords: range | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Balling): This are all good on modern ffmpeg even without any magic whatsover. I would say that a) mpv says there is out-of-gamut stuff even though there should be none b) decoder in ffmpeg is pretty bad, but encoeder is perfect, all issues in comment above this are fixed {{{ ffmpeg -y -t 4 -loop 1 -i ARIB_STD-B28.png -vf scale=out_color_matrix=bt709:out_range=pc -color_range 2 -color_primaries bt709 -color_trc iec61966_2_1 -colorspace bt709 8.mp4 }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/3801#comment:9> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3801: SWSCALE: Incorrect Values (+-1) in Full Range Conversion RGB to YCbCr -------------------------------------+------------------------------------- Reporter: troy_s | Owner: (none) Type: defect | Status: open Priority: normal | Component: | undetermined Version: unspecified | Resolution: Keywords: range | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Balling): Apparently all that SMPTE pattern stuff is popular, see #7249. Does anybody has ideas on the decoder and whether it should be hardcoded for those values? mpv should be fixed too. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3801#comment:10> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3801: SWSCALE: Incorrect Values (+-1) in Full Range Conversion RGB to YCbCr -------------------------------------+------------------------------------- Reporter: troy_s | Owner: (none) Type: defect | Status: open Priority: normal | Component: | undetermined Version: unspecified | Resolution: Keywords: range | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Balling): See bug in mpv: https://github.com/mpv-player/mpv/issues/9757 As for b) I believe that there is at least a problem that one should use most saturated colors when decoding. Indeed, otherwise that would be that 255, 255, 0 is not achievable, which is just hilarious. And it looks like a bug in ffmpeg. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3801#comment:11> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3801: SWSCALE: Incorrect Values (+-1) in Full Range Conversion RGB to YCbCr -------------------------------------+------------------------------------- Reporter: troy_s | Owner: (none) Type: defect | Status: open Priority: normal | Component: | undetermined Version: unspecified | Resolution: Keywords: range | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Balling): Actually, now that I think about it, you can still get the 255, 255, 0 color by doing some out-of-gamut magic. So I suppose all is correct here. It is also ver cool to note that 8 bit YCbCr RP 219 pattern is not more often correct. For example on this video. https://youtu.be/k5tcHp1kBmQ (0:21 time.) -- Ticket URL: <https://trac.ffmpeg.org/ticket/3801#comment:12> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
participants (1)
-
FFmpeg