Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
18th May 2012, 18:26 | #1 | Link |
Registered User
Join Date: Dec 2002
Location: UK
Posts: 1,673
|
converttorgb(matrix="PC.709") incorrect?
Here's a simple script...
PHP Code:
Red should be 235,16,16 Red is output as 240,15,15 Blue should be 16,16,235 Blue is output as 16,16,241 Cyan should be 16,235,235 Cyan is output as 11,236,236 Yellow should be 235,235,16 Yellow is output as 235,235,10 You can download ITU-R BT.709 for free from here: http://www.itu.int/rec/R-REC-BT/en The formulae are on printed page 19 / PDF page 21. The following pages are correct: http://avisynth.org/mediawiki/ColorBars_theory Specifically the "100/0/100/0 bars using Rec.709 coefficients / Y,Cb,Cr [16,235]" table is correct. http://avisynth.org/mediawiki/Color_conversions The formulae place a factor of two in a different part when converting to digital values, but give the same result in the end. The YUV values of ColorBarsHD appear to be correct, so it seems to me that converttoRGB(matrix="PC.709") must be wrong. Black and White are correct, so the error seems to be in one of the colour difference coefficients. But this seems so unlikely, given that it's been in AVIsynth for so long! What am I missing here? Am I doing something wrong? Cheers, David. |
19th May 2012, 22:45 | #3 | Link |
Registered User
Join Date: Dec 2002
Location: UK
Posts: 1,673
|
Rec709 will give me 0-255 RGB. I'll have to check if it gives the correct values for all colours, but this doesn't help me anyway...
I want 16-235 RGB, but I want the correct values. As found in ITU BT 709. Is PC.709 trying to solve some other problem? e.g. starting with 0-255 RGB, then for some reason using PC.709 to get 0-255 YUV, and then using PC.709 to get back to 0-255 RGB? If so, that's not what I want to use PC.709 for. I often want to start with 16-235 YUV, and go to 16-235 RGB to maintain headroom but process in RGB (without the clipped expansion to 0-255 that Rec709 causes), and then go back to 16-235 YUV. I often do that, using PC.709 both ways. Works a treat - or I used to think so! However, in my current use case, only want to do the first part: start with 16-235 YUV, go to 16-235 RGB using PC.709, and then check some levels in RGB space. But unfortunately, the RGB levels created by converttorgb in this case are wrong for all saturated colours (but fine for greyscale!). Cheers, David. |
20th May 2012, 10:16 | #5 | Link | |||
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Quote:
Quote:
Quote:
ConvertToRGB(matrix="Rec709") Levels(0, 1.0, 255, 16, 235) and the reverse operation if you want to convert back. But then of course anything outside 16-235 in your source is clipped. Last edited by Gavino; 20th May 2012 at 10:25. |
|||
20th May 2012, 13:04 | #6 | Link |
Registered User
Join Date: Sep 2009
Posts: 378
|
re chroma, the assumption with 'PC' that chroma is 0 - 255 is from RGB to YCC conversions only? or as well as converting from YCC to RGB, for example if I have a full luma but 16 - 240 chroma clip and I want 'correct' RGB color representation of that then 'PC' 709 or 601 is correct? Depending on matrix used in the original encoding? Full chroma & luma in YCC would be xvYCC? Where does JFIF fit in here?
Last edited by Yellow_; 20th May 2012 at 13:12. |
20th May 2012, 16:29 | #7 | Link |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
The only conversions supported by Avisynth ConvertXXX() functions are:
Rec601 and Rec709 matrices Y[16,235]+UV[16,240] <-> RGB[0,255] PC.601 and PC.709 matrices YUV[0,255] <-> RGB[0,255] See http://avisynth.org/mediawiki/Color_conversions So a clip with full luma but 16-240 chroma does not fit in and would need to be tranformed to one of the standard forms before conversion. I don't know enough about xvYCC or JFIF to comment on those. |
20th May 2012, 17:29 | #8 | Link | |
Registered User
Join Date: Sep 2009
Posts: 378
|
Quote:
Would be ok to convert via a 3D LUT for example yCMS to 16bit? http://forum.doom9.org/showthread.php?t=154719 Or maybe does not fit in with regard to gamut? Perhaps widen the gamut? Is it to do with chroma saturation? Gamut clipping? Is desaturated chroma less likely to clip and therefore fit? But RGB color values would be skewed from original RGB captured or generated? Then use Dither stacked lsb / msb 16bit tools and go to 10bit YCC or 16bit images as Avisynth does not support >8bit as we know. http://forum.doom9.org/showthread.ph...59#post1386559 Query is more to do with theory and suitability rather than knowledge of the plugins and tools. Last edited by Yellow_; 20th May 2012 at 18:15. |
|
20th May 2012, 18:44 | #9 | Link |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
All I'm saying is the ConvertXXX() functions are limited to the options mentioned, as the conversions are based on assumptions about what values represent the white/black points and extremes of chroma.
However, in theory anything is possible if you can find another suitable function or tool. |
20th May 2012, 23:05 | #11 | Link | |||
Registered User
Join Date: Dec 2002
Location: UK
Posts: 1,673
|
Quote:
Quote:
Cheers, David. |
|||
21st May 2012, 10:18 | #12 | Link | |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Quote:
(Even using PC-range, not all YUV combinations are 'valid', as I demonstrated here.) You should be OK if your super-whites+blacks are close to greyscale (chroma=128). |
|
21st May 2012, 11:25 | #13 | Link |
Registered User
Join Date: Sep 2009
Posts: 378
|
Revisiting the ValidRGB thread and testing it on a few BT709 color primary, BT601 matrixed h264, I get identical 'invalid' pixels for using full luma +pcRange=true compared to doing ColorYUV PV->TV and pcRange=false results are the same so as I think you've mentioned previously even 16 - 235 luma + 16 - 240 chroma can give invalid RGB.
Regarding levels adjustments, this is what many NLE's do, even with 32bit float workspace. QT for example range converts full luma YV12 to YUY2 16 - 235 at decompression. Gavino, please disregard my PM regarding PhotoYCC if you haven't already, as it seem to be a 'dead' format, it was just an interesting read about how kodak combined BT709 primaries + BT601 matrix over full luma to get expanded gamut and superwhites. I've always wondered why Canon and Nikon used the mixed combination in their h264, although probably not utilised by the media player as they force a luma conversion to 16 - 235 by flagging them full range. yCMS 3D LUT tool for Avisynth via triticals t3dlut plugin, suggests a yRGB expanded color space can hold the full YCbCr color space in RGB. http://forum.doom9.org/showthread.php?t=154719 t3dlut plugin & download: http://bengal.missouri.edu/~kes25c/#c4 http://bengal.missouri.edu/~kes25c/t3dlut.zip Last edited by Yellow_; 21st May 2012 at 11:31. |
21st May 2012, 12:21 | #14 | Link | |||
Registered User
Join Date: Dec 2002
Location: UK
Posts: 1,673
|
Quote:
Quote:
Quote:
I'm going to start another thread... http://forum.doom9.org/showthread.php?p=1575454 Cheers, David. Last edited by 2Bdecided; 21st May 2012 at 12:27. |
|||
21st May 2012, 18:39 | #15 | Link |
Registered User
Join Date: Sep 2007
Posts: 5,346
|
What are the equations used for PC range YCbCr<=>RGB in avisynth?
edit: they are here, but they look different than the standard equations. I guess "PC" range isn't equivalent to "Studio RGB" http://avisynth.org/mediawiki/Color_conversions Programs that use that have ability to use "studio RGB" (e.g Sony Vegas) will scale the 100% colorbars correctly from YCbCr test video You can find "studio RGB" equations in various books and online resource (google books will give a preview of some of the books and the equations), maybe it can be written for an avisynth function? e.g. google books preview for "Video Demystified: A Handbook for the Digital Engineer" lists all the equations Last edited by poisondeathray; 21st May 2012 at 18:41. |
22nd May 2012, 11:26 | #16 | Link |
Registered User
Join Date: Dec 2002
Location: UK
Posts: 1,673
|
Putting them into the format of the "programming" formulae from this page...
http://avisynth.org/mediawiki/Color_conversions ...the "studio" / "CE" RGB conversions (16-235 YUV <> 16-235 RGB) are as follows... Code:
y = Kr*r + Kg*g + Kb*b v - 128 = (112/219)*(r-y)/(1-Kr) = (112/219)*r - (112/219)*Kg*g/(1-Kr) - (112/219)*Kb*b/(1-Kr) u - 128 = (112/219)*(b-y)/(1-Kb) = - (112/219)*Kr*r/(1-Kb) - (112/219)*Kg*g/(1-Kb) + (112/219)*b r = y + (219/112)*(v-128)*(1-Kr) g = y - (219/112)*(u-128)*(1-Kb)*(Kb/Kg) - (219/112)*(v-128)*(1-Kr)*(Kr/Kg) b = y + (219/112)*(u-128)*(1-Kb) It's basically the existing yuv [0,255] <-> rgb [0,255] conversion, but with the 2* and 0.5* scale factors replaced by (219/112) and (112/219). (I didn't just make this simple change - I worked from the ITU formulae and re-arranged them - but this is where I ended up) (You could collect these factors into a single place in each equation, but I left them separate to match the equations in the wiki.) So if anyone would like to add matrix="STU601" and matrix="STU709" to converttoRGB/YUV/YV12 using these formulae, that would be just wonderful! The appropriate code must be very similar to what's there already, but I wouldn't know where to start. Cheers, David. P.S. there will be rounding errors and losses. I'm guessing YUV>RGB>YUV could be lossless for colours that are in-range for both colour spaces (depending on chroma sub-sampling), while RGB>YUV>RGB will not be (8-bit precision throughout prevents lossless transformation?). By definition, greyscale images are transformed losslessly both ways. P.P.S. the only advantage to doing this (i.e. using Studio RGB instead of AVIsynth's "PC levels" conversion matrices) is fractionally more headroom - and meeting the "standard" 16-235 studio RGB used elsewhere. In terms of what I was using it for (i.e. converting YUV video into RGB space for processing, and then converting back to YUV again), the existing PC.601 and PC.709 matrices do just as well: maintaining super-white and blacker-than-black, and preventing re-quantisation of luma/greyscale data. Last edited by 2Bdecided; 22nd May 2012 at 11:39. |
22nd May 2012, 18:45 | #17 | Link | ||
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Quote:
Quote:
|
||
23rd May 2012, 13:02 | #18 | Link | |
Registered User
Join Date: Dec 2002
Location: UK
Posts: 1,673
|
Quote:
EDIT: Hmm, not sure now. Will investigate further. Last edited by 2Bdecided; 23rd May 2012 at 17:26. |
|
27th May 2012, 12:18 | #19 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
Just came across the post linked below and remembered your Studio RGB requirement:
http://forum.doom9.org/showthread.ph...432#post639432 Converts YUY2 to Studio RGB, have not tried it, By Trevlac.
__________________
I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? |
Thread Tools | Search this Thread |
Display Modes | |
|
|