Yuy2 0-255

[trevlac]

Forgive me if this is a dull question, but I've been puzzeling thru color spaces and specs, and I can't find this one.

Is there anyway to convert the full 0-255 in YUY2 to RGB32? I'd like to do this without compressing down, then back out.

Why, you say, would I care to do this?

Well, from the BT8x8 spec, it is clear that a cap in YCbCr will result in a range from 2-253 YUY2. Now the low side is probably realistically up to around 16 (maybe 21) due to corring, but the 253 is clearly in tact.

So, for example, if my brightness and/or contrast is not right on, and/or my source exceeds IRE100, there should be usefull info between 235 and 253. From some tests, it does appear that a histogram is generally slambed against the right. Pre-cap adjustments are a guess, so I'd like to work post.

In the end, I figure if I convert the full range YUY2 to RGB so I can work in VDub, mess with the colors to get them to spec, and then go to YU12 for DVD, I get the most control.

[sh0dan]

ConvertToRGB32(matrix = "rec709")

[Wilbert]

I'd like to do this without compressing down, then back out.
What do you mean by this?

What's wrong with adding a line

ColorYUV(levels="PC"->"TV")

edit: Ok, I know what you mean. Then the question would be, why do you want to convert to RGB and back.

[trevlac]

@sh0dan

Thanks for the reply. This was unclear to me. I did look at the avisynth source, but when we get into the mmx asm stuff, the matrix used is not too clear. I will give it a try. However, my understanding is that 709 spec would be a different color than 601, and that it too could expand the range from 16-235 to 0-255 without concern to what was above 235 in the YCbCr file. This of course would depend upon how it was implemented.


@Wilbert

I have written a vdub plugin to help me understand color correction. So far I have histograms and ntsc hot pixel support. I will soon add a waveform monitor.

I'd like to work in vdub. The only reason to go back will be to go to dvd. To be honest, I'm not clear what the encoders do. Say I feed an rgb32 file to an encoder. I assume the encoder either converts to YCbCr 4:1:1 or my default rgb codec does. I'm not that far on the process.

I'll probably port my vdub stuff to avisynth, but that would just be for the purpose of learning avisynth. Actually, that is why I wrote the Vdub one too (to learn vdub).

However, when working with the full range in avisynth, it is not clear what the various filters do (some may just clamp past 16 and 235). I suppose as long as contrast/brightness didn't, that could be my 1st step. I'd still have to see the unclamped stuff to know what to do.

So... to be clear on my answer to why yuy2->rgb32->YCbCr 4:1:1 ?

1) I will cap in yuy2 to get the full range (even if contrast/gain are off and/or the source is above IRE100, i get full info)

2) If I can go yuy2 0-255 -> rgb 0-255 then I keep the full cap info

3) Then I manually adjust the rgb back out (brightness/contrast maybe different for different colors). This will clip to the points I want, but not before I can understand the source.

4) Take the rgb 0-255 to YCbCr 16-235 for mpeg.

edit I'm not sure it is really 'bad' to work in rgb, as long as you know what you have AND the conversion does not introduce too many rounding errors. The 'excursion' difference also introduces error. This might be aliviated a bit by working within a 16-235 range in rgb, but then I couldn't really see the result. It's hard to say what really matters in practice. I'm sure if you compound enough problems it will show.

[Wilbert]

I assume the encoder either converts to YCbCr 4:1:1 or my default rgb codec does. I'm not that far on the process.
mpeg2 (on a dvd) is 4:2:0.

I'll probably port my vdub stuff to avisynth, but that would just be for the purpose of learning avisynth. Actually, that is why I wrote the Vdub one too (to learn vdub).
That would be great. Of course, I also would like to see the vdub filter.

However, when working with the full range in avisynth, it is not clear what the various filters do (some may just clamp past 16 and 235).
To be quite honest. I don't know what the various filters and external plugins do when working with the full range.

In any case, you have problems when a filter/plugins performs a yuv-rgb conversion internally.

Well, from the BT8x8 spec, it is clear that a cap in YCbCr will result in a range from 2-253 YUY2.
That happens also in my case. But then, the video is brighter than it should be (assuming source is TV, and TV is [16,235]). I guess that's also true in your case. If so, you have to correct for that anyhow (with ColorYUV).

[trevlac]

Originally posted by sh0dan
ConvertToRGB32(matrix = "rec709")

I did some test on this and it's not what I was looking for. I'm saying this just to let anyone who sees this, know how it works. Please note. I'm not saying that it does anything wrong. I'm just looking for something different.


BlankClip(length=300, color=$00BF00).convertToYUY2()
ColorYUV(analyze=true)
#ConvertToRGB32(matrix = "rec709")
ConvertToRGB32()


http://www.video-demystified.com/mm/tutor/ch03.pdf

Basically, there should be 4 flavors of RGB. 2 for StdTV 601 and 2 for HDTV 709. I believe the difference is the color of the green primary. For each of these there should be RGB that has a normal range of 0-255 and one who's normal range is 16-235. The second can contain 'out of range' data that could be corrected. Converting from 16-235 YCbCr to 0-255 RGB clips any 'out of range' data.

I tested using the script above and the calcs on page 18 of the link.

1st Line
The color is 75% saturated green (191) for RGB with a range of 0-255. This gets converted to YUY2 using the 601 formula compressing the 0-255 to 16-235.

2nd Line
You can see the results and compare them to the table on page #18.

3rd Line
Using matrix 709 will convert the YUY2 to RGB using a different matrix due to the different color of green. It takes the 16-235 and streatches it to 0-255. I confirmed this in vdub. The green # is 161. It's the same as manually calculating using the 'computer 709 formula' on page #19.

4th Line
Using the default 601 matrix does the same 16-235 to 0-255 giving back (almost) the same 191 number. Almost, because I get 190 due to rounding.

[trevlac]

Originally posted by Wilbert
mpeg2 (on a dvd) is 4:2:0.

You are absolutely correct. I must have had
(NTSC)DV on the brain.


That would be great. Of course, I also would like to see the vdub filter.

Well you asked for it. ;)

http://trevlac.us/clrtools.htm
EditTried to fix link. You can click to it, then right click and save to get the file.

You'll probably have to paste that link into a new browser window to get it to work.

It is indeed an alpha. I really need to clean the code, although speed is of lessor importance because it doesn't really make changes. It's intended to give color info so you can use other filters to do the work. Right now it shows some histograms, color channels, and broadcast 'hot pixels' (oversaturated colors that could be clipped if used thru consumer equipment == they don't look good on a tv). I intend to add a waveform monitor, and of course a write up on how to use all this junk. That is of course after I learn myself. :D


In any case, you have problems when a filter/plugins performs a yuv-rgb conversion internally.

Yes. I would want my 1st step to be to get the color back in range, so I wouldn't have to keep track of what does what. But I'd like to 'see it' before I started using colorYUV or the like.

Thanks for your comments. I wasn't sure if I was a bit 'off' asking about something like this.

[sh0dan]

Instead of relying on some strange YUV->RGB->YUV conversion, I'd recommend that you adjust using this script:

ColorYUV()
Histogram(mode="levels")

It will show you the amount of superblack/superwhite. When you have adjusted the levels you can add opt="coring" to ColorYUV, which will limit the final range to CCIR601.

As an experiment I added "soft limiting" to Overlay. When luma is > 255 (when doing add for instance), the chroma information is slowly removed. I intend to add this functionality to limiter, so superwhite/superblack will desaturate chroma. For instance:
if (Y>max_y) { // Apply overbrightness to UV
int multiplier = max(0,max_y+16-Y); // 0 to 16
U = ((U*multiplier) + (127*(16-multiplier)))>>4;
V = ((V*multiplier) + (127*(16-multiplier)))>>4;
Y = max_y;
}
16 is a good value for limiter, as Y=255 will always result in white.

[trevlac]

@sh0dan

Thanks again for the reply. Honestly, what I am really doing is trying to learn about color and colorspaces. If what you mean by

ColorYUV()
Histogram(mode="levels")

is uses parameters for coloryuv to adjust and histogram to see. Then, that is actually where I started. :) The problem I ran into was that the color difference graphs are a mystery to me. I'm not sure how you really read them. I guess I'm just stuck in rgb mode. I gave up using the above because I thought dropping to yv12 to use it would be a problem.

But after your suggestion (maybe this is what you mean), I see I could convert to yv12, use the luma chart to know what super white to recover, and then use ColorYUV to adjust the original yuy2 back to a normal range.

Thanks for the tip. That should work! I assume converttoyv12 does not clamp, but I'll check the code.

BTW: I'm not sure 16-235 rgb is all that strange. Video Demystified has formulas for it, and there are quite a few other sources that use those formulas. It seems to sometimes be referred to as studio rgb. I guess this is also why the mpeg2 encoders want to know the range of your rgb. But I'm just trying to puzzle it out. :D

[Wilbert]

is uses parameters for coloryuv to adjust and histogram to see. Then, that is actually where I started. The problem I ran into was that the color difference graphs are a mystery to me. I'm not sure how you really read them.
Just curious. You read the analog capture guide right? There is a section devoted about how to do this and how to read the results.

Btw, converting from yuy2 to yv12 (or back) doesn't change the luma range.

But after your suggestion (maybe this is what you mean), I see I could convert to yv12, use the luma chart to know what super white to recover, and then use ColorYUV to adjust the original yuy2 back to a normal range.
Yup. But, I will tell you. The results will be the same as ColorYUV(levels="PC->TV").

Thanks for the tip. That should work! I assume converttoyv12 does not clamp, but I'll check the code.
No, well it clamps to [0,255] I guess :), provided the source is YUY2. If the source is RGB, then it will scale to [16,235].

[trevlac]

@Wilbert,

Thanks for pointing me back to the guide. I've read that part, but did not recall it when I started to learn about color.


Yup. But, I will tell you. The results will be the same as ColorYUV(levels="PC->TV").



I'm not sure this is true. For example, if you cap and get info in the range of 22-253 a PC->TV would probalby shrink the entire 0-255 to 16-235. Now you have valid info in the range of about 38-234. If however, you 1st knew what you had (say 22-253), reduced the gain for the entire picture so you have 16-247 or maybe even 14-245, and then reduced the contrast and clamp so you hit 16-235, you would get different results. The non 'PC->TV' method allows you to decide what is valid and what is not and to keep a fuller range for the valid info. It is also a lot more work.

Honestly, I'm not sure I know how to do this in YUV because the UV run 16-240, and I have trouble just thinking what UV really are. I would also like to adjust the RGB color seperately. Say you have a red cast and you can just adjust the red gain to get it down and still keep the 'fuller' range of the other colors.

This might all be overkill on my part. I can't really say that there is one bit of difference in the way I am talking about, vs the PC-TV way you describe. :)

BTW: I did some testing on my filter for the 'hot pixel' option. I don't think it quite works. The calculation I'm using uses a 7.5 pedestal for NTSC, which I don't think exists in YCbCr. AKA: When a card converts from YIQ to YCbCr, it removes the pedestal by mapping 7.5IRE to 16 and 100IRE to 235 for NTSC and 0IRE to 16 and 100IRE to 235 for PAL and NTSC-J. Also, there is no difference between PAL and NTSC-J. The only difference would be if the source was not gamma corrected. I disabled this option because it does not seem one would normally have such video unless you went out of your way to un-gamma correct.

Where can I post info about my filter when it is closer to done?

edit
Here is a write up from a chip manufacturer on the subject of ycbcr to rgb conversions. They clearly talk about both 16-235 and 0-255 rgb. They also imply that official 601 YCbCr->RGB conversion does not expand the range from 16-235 but copies the full info. They speak of the range change as a convience for proper viewing on a pc.

It's only 2 pages and dated back to 1997: http://www.intersil.com/data/an/an9717.pdf

There is also some info on gamma correction. They also seem to imply that video manipulations (maybe intensity changes) are only properly done in non-gamma corrected pixels. :(