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.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 18th May 2012, 18:26   #1  |  Link
2Bdecided
Registered User
 
Join Date: Dec 2002
Location: Yorkshire, UK
Posts: 1,673
converttorgb(matrix="PC.709") incorrect?

Here's a simple script...

PHP Code:
colorbarsHD()

converttorgb(matrix="PC.709"
Check out the RGB values of the 100% colour squares about 2/3rds of the way down the screen.

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.
2Bdecided is offline   Reply With Quote
Old 18th May 2012, 19:56   #2  |  Link
Yellow_
Registered User
 
Join Date: Sep 2009
Posts: 378
Colorbars(HD) produces a rec709 clip with 16 - 235?

PC.709 is for full luma ITU BT 709.

ConvertToRGB(matrix="rec709") is for Colorbars(HD)? What does that give you?

Last edited by Yellow_; 19th May 2012 at 07:54.
Yellow_ is offline   Reply With Quote
Old 19th May 2012, 22:45   #3  |  Link
2Bdecided
Registered User
 
Join Date: Dec 2002
Location: Yorkshire, 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.
2Bdecided is offline   Reply With Quote
Old 20th May 2012, 10:07   #4  |  Link
Yellow_
Registered User
 
Join Date: Sep 2009
Posts: 378
http://forum.doom9.org/showpost.php?...&postcount=484

Maybe related?
Yellow_ is offline   Reply With Quote
Old 20th May 2012, 10:16   #5  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,377
Quote:
Originally Posted by 2Bdecided View Post
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?
That's exactly what it's for.

Quote:
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!
Using a PC matrix will give only approximately the same as a scaled 16-235 RGB representation, because it's not taking 16 as black and 235 as white, and because the chroma range is taken as 0-255 instead of 16-240.

Quote:
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!).
The right way to do that (if you want exact 16-235 RGB) is to use a Rec matrix, then use Levels to scale the RGB from 0-255 to 16-235.

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.
__________________
GScript and GRunT - complex Avisynth scripting made easier

Last edited by Gavino; 20th May 2012 at 10:25.
Gavino is offline   Reply With Quote
Old 20th May 2012, 13:04   #6  |  Link
Yellow_
Registered User
 
Join Date: Sep 2009
Posts: 378
Quote:
Originally Posted by Gavino View Post
Using a PC matrix will give only approximately the same as a scaled 16-235 RGB representation, because it's not taking 16 as black and 235 as white, and because the chroma range is taken as 0-255 instead of 16-240.
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.
Yellow_ is offline   Reply With Quote
Old 20th May 2012, 16:29   #7  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,377
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.
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 20th May 2012, 17:29   #8  |  Link
Yellow_
Registered User
 
Join Date: Sep 2009
Posts: 378
Quote:
Originally Posted by Gavino View Post
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.
Does not fit in with regard to bit depth and/or gamut? For example going YCC full luma + chroma 16 - 240 to 10bit YCC or 16bit RGB or 32bit float unbound RGB in an Non Linear Video Editor?

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.
Yellow_ is offline   Reply With Quote
Old 20th May 2012, 18:44   #9  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,377
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.
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 20th May 2012, 19:24   #10  |  Link
Yellow_
Registered User
 
Join Date: Sep 2009
Posts: 378
Gavino, cheers I remember we've been here before about gamut and clipping. I'm currently revisiting the ValidRGB functions thread of yours pointed to in the link you provided above. Apologies.
Yellow_ is offline   Reply With Quote
Old 20th May 2012, 23:05   #11  |  Link
2Bdecided
Registered User
 
Join Date: Dec 2002
Location: Yorkshire, UK
Posts: 1,673
Quote:
Originally Posted by Gavino View Post
Quote:
Originally Posted by 2Bdecided View Post
(I want to) 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!).
The right way to do that (if you want exact 16-235 RGB) is to use a Rec matrix, then use Levels to scale the RGB from 0-255 to 16-235.

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.
Thanks for the clear answer Gavino. So basically, there's no way to do the industry standard ITU-R BT.709 conversions in AVIsynth, unless I learn how to code and write it myself? Fudging it with levels won't cut it - I don't want banding, extra quantisation, or clipping of super-whites/blacks.


Quote:
Originally Posted by 2Bdecided View Post
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!
Quote:
Originally Posted by Gavino View Post
Using a PC matrix will give only approximately the same as a scaled 16-235 RGB representation, because it's not taking 16 as black and 235 as white, and because the chroma range is taken as 0-255 instead of 16-240.
I guess, in this case where it's taking a round trip YUV>RGB>YUV, then it won't matter that I've been "misusing" PC.709 all these years, a long as there's no process in RGB space which requires absolutely correct values? As a trick to allow super-whites+blacks in RGB space, it's OK?

Cheers,
David.
2Bdecided is offline   Reply With Quote
Old 21st May 2012, 10:18   #12  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,377
Quote:
Originally Posted by 2Bdecided View Post
I guess, in this case where it's taking a round trip YUV>RGB>YUV, then it won't matter that I've been "misusing" PC.709 all these years, a long as there's no process in RGB space which requires absolutely correct values? As a trick to allow super-whites+blacks in RGB space, it's OK?
As long as your source YUV values, when assumed to have black=0 and white=255, represent 'valid RGB'.
(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).
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 21st May 2012, 11:25   #13  |  Link
Yellow_
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.
Yellow_ is offline   Reply With Quote
Old 21st May 2012, 12:21   #14  |  Link
2Bdecided
Registered User
 
Join Date: Dec 2002
Location: Yorkshire, UK
Posts: 1,673
Quote:
Originally Posted by Gavino View Post
As long as your source YUV values, when assumed to have black=0 and white=255, represent 'valid RGB'.
I'm going to scratch my head for hours now, trying to figure out if that's more or less restrictive that what I thought I was doing. No, ignore that, it didn't take hours: I think it's slightly more restrictive (i.e. it'll create invalid RGB slightly earlier than I expected), not that it really matters for anything practical.

Quote:
(Even using PC-range, not all YUV combinations are 'valid', as I demonstrated here.)
Yes, I understand that bit.

Quote:
You should be OK if your super-whites+blacks are close to greyscale (chroma=128).
When they're not, using PC range doesn't help much anyway, and I have to fix them in YUV space. But it's just another thing to worry about.

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.
2Bdecided is offline   Reply With Quote
Old 21st May 2012, 18:39   #15  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,640
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.
poisondeathray is offline   Reply With Quote
Old 22nd May 2012, 11:26   #16  |  Link
2Bdecided
Registered User
 
Join Date: Dec 2002
Location: Yorkshire, 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.
2Bdecided is offline   Reply With Quote
Old 22nd May 2012, 18:45   #17  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,377
Quote:
Originally Posted by 2Bdecided View Post
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).
Yes, as I suggested in post#5, that comes about because the YUV chroma range is 224 (or 2*112) while the luma range is 219, so a slightly different scaling is involved. Since 219/112 is close to 2, the difference is not large for chroma close to 128, which is why you got acceptable results using PC.709.

Quote:
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?).
Rounding errors from the 8-bit precision will occur in both directions (except for greyscale).
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 23rd May 2012, 13:02   #18  |  Link
2Bdecided
Registered User
 
Join Date: Dec 2002
Location: Yorkshire, UK
Posts: 1,673
Quote:
Originally Posted by Gavino View Post
Rounding errors from the 8-bit precision will occur in both directions (except for greyscale).
Yes, you're right!

EDIT: Hmm, not sure now. Will investigate further.

Last edited by 2Bdecided; 23rd May 2012 at 17:26.
2Bdecided is offline   Reply With Quote
Old 27th May 2012, 12:18   #19  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 6,199
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 ???
StainlessS is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 22:09.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.