Again, nice work, Sharc.
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays! or rip iTunes movies!
+ Reply to Thread
Results 31 to 42 of 42
Thread
-
There is issue with this formula - normally you should use 10 bit (8.2 code) and in 10 bit apply mentioned error rounding - conversion to 8 bit values is performed by truncation of fractional part i.e. 8 bit values without fraction - there is no error rounding there - this is subtle but important difference (if you work with broadcast equipment and sources then those differences begin to be obvious).
Not sure why there is many errors in standards and recommendations... -
Here is an interesting tidbit to add to this discussion. Fortunately the calculation results agree with Sharc's calculations for 709.
https://www.silicondust.com/yuv-to-rgb-conversion-for-tv-video/ -
Here is the ffmpeg code I use to encode to Y,Cb,Cr 709:
Code:ffmpeg -y -loop 1 -t 60 -i "color_bars.bmp" -pix_fmt yuv420p -c:v libx265 -c:a none -crf 0 -vf scale=w=1280:h=720:out_color_matrix=bt709:out_range=limited -color_primaries bt709 -color_trc bt709 -colorspace bt709 -r 59.94 bars.mp4
-
Sharc: would you be willing to work out the conversion equation for BT.2020 / BT.2100?
Thanks. -
-
Do you mean doing the matrix inversions? I have really no experience at all with BT.2020, I am not even sure whether the matrix conversion principle still applies for BT.2020 similar as for 601/709.
Page 4:
https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.2020-2-201510-I!!PDF-E.pdf -
https://github.com/sekrit-twc/zimg
conversion library between colorspaces, bitdepths, resolutions ... so while avoiding apps that use it, maybe you can use it directly, there is some API examples -
This code returns R=181, G=180, B=12
Code:Kr = 0.2126 Kg = 0.7152 Kb = 0.0722 y.f = 168 u.f = 44 v.f = 136 r = y + 2*(v-128)*(1-Kr) g = y - 2*(u-128)*(1-Kb)*Kb/Kg - 2*(v-128)*(1-Kr)*Kr/Kg b = y + 2*(u-128)*(1-Kb)
-
-
OK
You would excpect 0.75*255 = 191 for full range 75% white
0 and 255 are reserved for sync.
Here is the broadcast legalizer which works great with lossless libx264 (crf 0). libx265 leaves too many artifacts and is slower than a glacier.
Code:ffmpeg -y -hide_banner -i "C0015.mp4" -vf scale=width=1280:height=720:flags='lanczos',limiter=16:235:1,limiter=16:240:6,setparams=range="tv" -codec:v libx264 -crf 0 -pix_fmt:v yuv422p -color_range "tv" -color_primaries bt709 -color_trc bt709 -colorspace bt709 -movflags +write_colr -r 59.94 -c:a copy limited.mov
-
Avisynth docs equations and internal convertion like ConvertToRGB/YUV() are not completely correct for narrow (limited) RGB<->YUV - they may miss 224/219 different scaling domains of Y and Cb/Cr data in digital form (equal for all current typical digital colour standards 601/709/2020). At least up to 3.7.3 release. As I understand Pinterf first promises to make small fix but later looks like decide to make big redesign of many internal conversion functions for correct precision and performance but lost before 3.7.3 release.
The typically available in the Internet search equations for RGB<->YUV designed to work with all 3 channels data in equal scale. So when user operates with YUV data (encoded in 601/709/2020 standards) in storage/distribution domain - he need to take into math equations equalizing of Y and UV scaling (using pre-computed float coefficients for better precision) before applying standard RGB<->YUV equations. Also after computing YUV from RGB - the UV must be quantized in 224-scale while Y in 219-scale. The idea of different scale domains (before quantization) may be designed to have a bit lower quantization noise in 8 and 10 bit digital UV data in storage/distributuion.
Also typical equations works in range 0..max RGB and YUV - so user typically need to subtrack black offset from Y and 'zero' offset from UV before apply RGB<->YUV equations.
So 'standard digital' storage domain for YUV data includes:
1. 224 scale for UV and 219 scale for Y
2. 16 offset for Y and 128 offset for UV
And 1 + 2 must be reversed before applying YUV->RGB transform. And result produced with zero black RGB (bipolar with negative under-blacks). To encode into digital narrow range RGB - add +16 offset (all in 8bit).
So in AVS currently for correct YUV->RGB (narrow/limited) only external plugins are completely correct or user need to apply 224/219 (or back 219/224) additional UV gain before conversion with internal functions.
Also as many modern EBU docs call non-full datarange as 'narrow' it may be named nRGB (to be different from sRGB).
Also note about better thread naming (coded or analog R and B colour difference data) may be important because that different scaling domains (analog gain in analog form) may be also different between digital and analog Y and RB colour difference data (or signalling).Last edited by DTL2023; 22nd Sep 2023 at 03:53.
Similar Threads
-
RGB Output Through SCART
By nman971 in forum DVD & Blu-ray PlayersReplies: 1Last Post: 13th Jul 2019, 04:34 -
RGB Range help
By attackworld in forum ComputerReplies: 5Last Post: 25th Apr 2019, 03:42 -
error RGB subrip and AVIsub
By Tata in forum SubtitleReplies: 0Last Post: 30th Jan 2019, 15:49 -
Help Converting YUV to RGB
By chris319 in forum Video ConversionReplies: 7Last Post: 24th Sep 2018, 19:51 -
FCC NTSC to RGB
By chris319 in forum Video ConversionReplies: 17Last Post: 18th May 2017, 08:20