color adjust necessary in capture->SVCD? - Page 4

george_zhu · 14th February 2004, 00:22

Actually my capture in VDub and Pic Mjpg (yuy2) yield min:0/max:255. (showed by avisyth coloryuv(analysize)). I can only open it at avisource("***",pixel_type="yuy2").

Thx

trevlac · 14th February 2004, 03:17

Quote:

Originally posted by george_zhu
Actually my capture in VDub and Pic Mjpg (yuy2) yield min:0/max:255. (showed by avisyth coloryuv(analysize)). I can only open it at avisource("***",pixel_type="yuy2").

George,

You don't provide enough info. YUY2 0-255 on normal source means you have a problem. You are out of range, and maybe way out of range (past 0 and 255). And you can only open it as yuy2 because ...?

Kika · 15th February 2004, 00:14

@george_zhu

I think, there's something wrong.
If your Capture-Card is a BT-Card, it should deliver 16-235 in YUY2-Mode. Did you shurely set the Card to YUY2 and not RGB24?

Second thing..., if you are using BT-Tweaker, there's an otion on it called "Full Luma Range". You should not use this, it gives you a wrong Range in YUY2-Mode.
Maybe this is driver related.

trevlac · 19th February 2004, 05:53

@Kika

This thread got me re-interested in the whole YUV to RGB conversion thing. So I made an avisynth plugin to convert from YUY2 to RGB without changing the range. Basically, I followed Poynton's formulas for studio RGB. The plugin is here. The function is YUY2toRGB219(interpolate=true). Default for interpolation is false. It just does an average across the 2 closest pixels for every other pixel.

I did a bunch of testing and here are my basic findings:

- YUY2 contains about 25% of the colors available in RGB255
- The remapping that occurs for a normal RGB255->YUV235 changes the colors(not by much)
- Converting from RGB->YUV without remapping again changes the colors due to the limits of 8 bit YUV storage
- If you go RGB->10 bit YUV and limited remapping, it appears you do not change the colors

- Going from YUV->RGB219 and not remapping appears to NOT change the colors. RGB is a big enough space and efficiently uses the 8 bits, so there does not appear to be loss.
- Going from YUV->RGB255 can truncate data out of the nominal range. I did not test to see if the remapping looses anything.

So... the good news appears to be that if you start with YUV, going to RGB219 should not loose you anything. Unfortunately, you will have to go back to YUV 4:2:0 for mpeg. I'm not sure what happens in that process ...

PS: My tests were not that scientific. I used the sweep I posted in this thread, and some 75% color bars. A difficulty of the testing is to seperate RGB->YUV conversion errors from YUV->RGB ones. This is because my test material starts life as RGB. I did get better results than overlay, but test for yourself.....

Wilbert · 19th February 2004, 10:24

@Trevlac,

Could you try

ConvertToRGB(clip, "rec709")

I think it should do the same, but I never tested it.

Kika · 19th February 2004, 11:27

@trevlac

Good work. I will test your PlugIn while my Holydays next week.
If it works like i hope it works, you'r my Hero.

Quote:

The remapping that occurs for a normal RGB255->YUV235 changes the colors(not by much)
Converting from RGB->YUV without remapping again changes the colors due to the limits of 8 bit YUV storage
Going from YUV->RGB255 can truncate data out of the nominal range. I did not test to see if the remapping looses anything.

Yes, these are the Problems i discovered by myself.
I bet, most converted Videos don't have the same colors than the original.

trevlac · 19th February 2004, 15:33

Quote:

Originally posted by Wilbert
@Trevlac,

Could you try

ConvertToRGB(clip, "rec709")

I think it should do the same, but I never tested it.

@wilbert,

I will give it a try. sh0dan pointed that out to me a while ago. I think I did look at the source, but it's a bit hard for me to read once we get into the asm. On the surface, a 709 matrix would be a completely different variable/option. 709 uses different color primaries than 601. It is also probably more appropriate for PC display. What "rec709" does, depends on how things are implemented.

Here are the 'standard' flavors of RGB as I see them:

601 primaries, 0-255 nominal range
601 primaries, 16-235 nominal range
709 primaries, 0-255 nominal range
709 primaries, 16-235 nominal range

Also in that ColorYUY2 dll, there were some 'straight' convert matrices. (Not fully implemented). These seem to go directly from YCbCr to RGB without adjusting for the fact that YCbCr is 16-235,16-240,16-240 and RGB should be 16-235,16-235,16-235. This does not seem correct.

@Kika

Personally, I think the color conversion debate has the wrong focus. In my experience, the signal makes the biggest difference. I get a completely different signal from my CATV vs DVB vs etc.... Once you know your signal you should capture as much of it as possible in the widest range as possible. The losses that occur due to YUV->RGB->YUV are nothing (if you do limited conversions in a reasonable way) compared to clipping your signal, getting the wrong black level, squishing your signal, etc. On the surface, RGB is a better color space than 8 bit YUV.

But I do have limited experience. I've been searching for a professional paper that says why YUV is better than RGB. Arachno tells me the latest premier takes YUV as input. Also, I belive pro product like quantel and avid store in YUV. I suspect this is 10 bit though.

Interesting pro discussion

And another thing
http://www.cinemacraft.com/files/doc/ccl_264e.pdf
On page 19 of the CCE doc it says if you use the 0-255 option, they use the same basic formula as the Poynton one I used. They however, work in the nearest integer which is exactly what is specified in spec 601 in section 3.5.4. I don't know the differences (using integers vs using float), but it's hard to discount the spec and/or Poynton.

trevlac · 19th February 2004, 19:02

@Wilbert

Some more tests

I used the following 75% colorbars script, ColorYUV(Analyze) and my RGB histograms in VDub to test various ways to convert YUV to RGB. Ideally, a conversion (all rgb channels) would exactly match the luma range in YUV. This is hard to test if mapping occurs, but you can start with RGB and see what you get back.

Code:

#LoadPlugin("YUY2toRGB219.dll")

black = BlankClip(width=10,height=240,length=300, color=$000000)
white = BlankClip(width=90,height=240,length=300, color=$BFBFBF)
yellow = BlankClip(width=90,height=240,length=300, color=$BFBF00)
cyan = BlankClip(width=90,height=240,length=300, color=$00BFBF)
green = BlankClip(width=90,height=240,length=300, color=$00BF00)
magenta = BlankClip(width=90,height=240,length=300, color=$BF00BF)
red = BlankClip(width=90,height=240,length=300, color=$BF0000)
blue = BlankClip(width=90,height=240,length=300, color=$0000BF)
set1 = StackHorizontal(black,white,yellow,cyan,green,magenta,red,blue)
set2 = StackHorizontal(black,blue,red, magenta,green, cyan, yellow,white)
stackVertical(set1,set2)
#1 -- No Conversions

#2 -- ConvertToYUY2 
#ConvertToYUY2()
#ColorYUV(Analyze=true)

#3 -- ConvertToRGB 
#ConvertToYUY2()
#ConvertToRGB()

#4 -- Default OS
#ConvertToYUY2()

#5 -- ConvertToRGB(709) 
#ConvertToYUY2()
#ConvertToRGB(matrix="rec709")

#6 -- YUY2toRGB219 
#ConvertToYUY2()
#YUY2toRGB219()

#7 -- Overlay 
#ConvertToYUY2()
#ovr = blankclip(width=1,height=1,color=$000000)
#overlay(ovr,mode="Add",output="RGB24",pc_range=true)


# --------- Results --------------
# R(min/max) G(min/max) B(min/max) Luma(min/max)

#1 -- RGB Colorbars   R(0/191) G(0/191) B(0/191) Luma(0/191)
#2 -- ConvertToYUY2   U(44/212) V(44/212) Luma(16/180)

#3 -- ConvertToRGB()  R(0/191) G(0/191) B(0/192) Luma(0/191)
#4 -- default OS      R(0/191) G(0/190) B(0/191) Luma(0/190) 
#5 -- ConToRGB(709)   R(0/208) G(0/191) B(0/200) Luma(0/191)  
#6 -- YUY2toRGB219    R(16/180) G(16/180) B(16/180) Luma(15/181) 
#7 -- Overlay         R(14/184) G(14/181) B(14/185) Luma(15/179)

Conclusions
ConvertToYUY2 changes the range from 0-191 to 16-180. Any Conversion that goes back to 0-191 is stretching back out. Matrix="rec709" still changes the range. #6 and #7 are the only ones that do not change the range.

#3, #4, #6 all have very small errors. I believe all of these errors are due to the 8bit conversion to YUV. If I run the numbers thru a calculator and 'store' 9bit YUV numbers, the errors go away. The differences between #3 & #4 are probably due to the truncation/rounding in the calculations used.

#7 had worse results than I expected. I'm not sure of the process inside. Overlay was clearly not intended for this use, it just seemed a work around.

#5 is interesting because it clearly changes the colors, but it also appears to map the colors differently.

Interpolation - This is easy to see on the waveform monitor. If there are dots around the color change, the threshold pixels moved due to interpolation. The default OS #3 and Overlay #7 do not interpolate. #3,#5,#6 do interpolate. For viewing, interpoplation is clearly a good thing. If you are going to convert back to YUV, I'm not sure.

Opinion
Changing the range gains no processing advantages. It may however clip your range. Processing in YUV may also have some disadvantages over RGB. There is less range to work with in YUV. However, since most of our source comes from YUV, I'm not sure how you create that xtra range, or if it's worth it.

Arachnotron · 19th February 2004, 20:01

Quote:

I've been searching for a professional paper that says why YUV is better than RGB.

I think it is simply a matter of conveniance. Since analogue CVBS, Y/C and component video already existed, simply digitizing them would be the easiest to do, since you can go back to analogue again without colorspace conversions. It's not really better, it is more "backwards compatible"

Kika · 20th February 2004, 10:08

OK, to come to a kind of outcome, here three simple rules:

1. If we are converting Videos, we should know the color space of the source and the target. (it's recommendet to use it in the Source line of AVISynth).

2. Try not to change the color space while converting. It may change the colors, the contrast and the brightness too.

3. If you must change the color space in case of using a special filter, don't do two YUV-Conversion by turns.

What do you think about that, any further suggestions?

trevlac · 20th February 2004, 15:30

I like simple, but I think this really all depends upon your process. If people understood the process and knew how to check what they had, it would be simple.

If they don't want to check/know, your rules are reasonable

Quote:

Originally posted by Kika
OK, to come to a kind of outcome, here three simple rules:

1. If we are converting Videos, we should know the color space of the source and the target. (it's recommendet to use it in the Source line of AVISynth).

You should know what happens in your entire process. Almost all source was digital YCbCr at one point. If you have RGB, it was probably converted at some point. If you stick an editor in the middle you are probably converting to RGB. TMPGEnc also only takes RGB as input. CCE takes both YCbCr and RGB. I think it depends on how you use MainConcept.

Quote:

2. Try not to change the color space while converting. It may change the colors, the contrast and the brightness to.

3. If you must change the color space in case of using a special filter, don't do two YUV-Conversion by turns.

Depending on your process, you may be able to stay with YCbCr all the way. For simple processing and using CCE, this would probably be good.

I may get flamed for this, but if you are using TMPGEnc or an editor that uses RGB, or if you are doing complex filtering, you should switch to RGB219 as soon as you can. The reason I say this is because you will switch at some point, so it is best to do it intentionally. Also, if you look at the color space as the place where the intermediate results of complex filtering are saved, 8 bit RGB4:4:4 has about 4x more precision than 8 bit YCbCr4:2:2. AKA uncompressed YUY2 is more lossy than uncompressed RGB, especially when it comes to color.

Kika · 20th February 2004, 15:45

Quote:

I may get flamed for this

Not by me, i agree to you.

Quote:

If they don't want to check/know, your rules are reasonable

I thought about the guys who are using some simple Guides or own Filtercombinations without knowing anything (or much) about colorspaces or colorspace conversions.
In some Scripts i have seen in the past, you will end up at a Luma range of somewhat like 48-207...

Or they have done so much shinkings and expandings of the range, that the resulting Video will have very pale colors.

Wilbert · 20th February 2004, 16:56

@Kika,

Your suggestions are incomplete. I mean they are fine if you use CCE. But if you use TMPGEnc, there must be conversions YUV-> RGB, RGB->YUV somewhere.

I don't think you can capture this case in a simple rule (ok, rules are simple, but the understanding is not simple). It is either:

Best advice in that case, is to open the source in YUY2 in AviSynth, and convert to RGB in AviSynth (at some point).[*] Uncheck that option in TMPGEnc.

Open the source as RGB in AviSynth, or directly in TMPGEnc itself. Check that option in TMPGEnc.
[*] modulo this luma shift. If we know what caused it. I have to reread the thread, forgot the conclusions about this.

Kika · 20th February 2004, 17:07

@Wilbert

Yeah, things never are realy simple.

Quote:

But if you use TMPGEnc, there must be conversions YUV-> RGB, RGB->YUV somewhere

trevlay already did a good conclusion about TMPGEnc and RGB.

This shifting thing doesn't matter, it happens only with PicVideo. ANy other source does not have this "problem".

And about TMPGEnc and the Luma range:
If the Source is in 16-235, use YCbCr-Mode
If the source is in 0-255, use CCIR-Mode

19th February 2004, 19:02	#68 \| Link
trevlac budala Join Date: Oct 2003 Location: U.S. Posts: 545	@Wilbert Some more tests I used the following 75% colorbars script, ColorYUV(Analyze) and my RGB histograms in VDub to test various ways to convert YUV to RGB. Ideally, a conversion (all rgb channels) would exactly match the luma range in YUV. This is hard to test if mapping occurs, but you can start with RGB and see what you get back. Code: #LoadPlugin("YUY2toRGB219.dll") black = BlankClip(width=10,height=240,length=300, color=$000000) white = BlankClip(width=90,height=240,length=300, color=$BFBFBF) yellow = BlankClip(width=90,height=240,length=300, color=$BFBF00) cyan = BlankClip(width=90,height=240,length=300, color=$00BFBF) green = BlankClip(width=90,height=240,length=300, color=$00BF00) magenta = BlankClip(width=90,height=240,length=300, color=$BF00BF) red = BlankClip(width=90,height=240,length=300, color=$BF0000) blue = BlankClip(width=90,height=240,length=300, color=$0000BF) set1 = StackHorizontal(black,white,yellow,cyan,green,magenta,red,blue) set2 = StackHorizontal(black,blue,red, magenta,green, cyan, yellow,white) stackVertical(set1,set2) #1 -- No Conversions #2 -- ConvertToYUY2 #ConvertToYUY2() #ColorYUV(Analyze=true) #3 -- ConvertToRGB #ConvertToYUY2() #ConvertToRGB() #4 -- Default OS #ConvertToYUY2() #5 -- ConvertToRGB(709) #ConvertToYUY2() #ConvertToRGB(matrix="rec709") #6 -- YUY2toRGB219 #ConvertToYUY2() #YUY2toRGB219() #7 -- Overlay #ConvertToYUY2() #ovr = blankclip(width=1,height=1,color=$000000) #overlay(ovr,mode="Add",output="RGB24",pc_range=true) # --------- Results -------------- # R(min/max) G(min/max) B(min/max) Luma(min/max) #1 -- RGB Colorbars R(0/191) G(0/191) B(0/191) Luma(0/191) #2 -- ConvertToYUY2 U(44/212) V(44/212) Luma(16/180) #3 -- ConvertToRGB() R(0/191) G(0/191) B(0/192) Luma(0/191) #4 -- default OS R(0/191) G(0/190) B(0/191) Luma(0/190) #5 -- ConToRGB(709) R(0/208) G(0/191) B(0/200) Luma(0/191) #6 -- YUY2toRGB219 R(16/180) G(16/180) B(16/180) Luma(15/181) #7 -- Overlay R(14/184) G(14/181) B(14/185) Luma(15/179) Conclusions ConvertToYUY2 changes the range from 0-191 to 16-180. Any Conversion that goes back to 0-191 is stretching back out. Matrix="rec709" still changes the range. #6 and #7 are the only ones that do not change the range. #3, #4, #6 all have very small errors. I believe all of these errors are due to the 8bit conversion to YUV. If I run the numbers thru a calculator and 'store' 9bit YUV numbers, the errors go away. The differences between #3 & #4 are probably due to the truncation/rounding in the calculations used. #7 had worse results than I expected. I'm not sure of the process inside. Overlay was clearly not intended for this use, it just seemed a work around. #5 is interesting because it clearly changes the colors, but it also appears to map the colors differently. Interpolation - This is easy to see on the waveform monitor. If there are dots around the color change, the threshold pixels moved due to interpolation. The default OS #3 and Overlay #7 do not interpolate. #3,#5,#6 do interpolate. For viewing, interpoplation is clearly a good thing. If you are going to convert back to YUV, I'm not sure. Opinion Changing the range gains no processing advantages. It may however clip your range. Processing in YUV may also have some disadvantages over RGB. There is less range to work with in YUV. However, since most of our source comes from YUV, I'm not sure how you create that xtra range, or if it's worth it.

20th February 2004, 10:08	#70 \| Link
Kika Registered User Join Date: Jul 2002 Location: Germany Posts: 819	OK, to come to a kind of outcome, here three simple rules: 1. If we are converting Videos, we should know the color space of the source and the target. (it's recommendet to use it in the Source line of AVISynth). 2. Try not to change the color space while converting. It may change the colors, the contrast and the brightness too. 3. If you must change the color space in case of using a special filter, don't do two YUV-Conversion by turns. What do you think about that, any further suggestions? Last edited by Kika; 20th February 2004 at 16:09.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

14th February 2004, 00:22	#61 \| Link
george_zhu Registered User Join Date: Feb 2003 Posts: 72	Actually my capture in VDub and Pic Mjpg (yuy2) yield min:0/max:255. (showed by avisyth coloryuv(analysize)). I can only open it at avisource("***",pixel_type="yuy2"). Thx

15th February 2004, 00:14	#63 \| Link
Kika Registered User Join Date: Jul 2002 Location: Germany Posts: 819	@george_zhu I think, there's something wrong. If your Capture-Card is a BT-Card, it should deliver 16-235 in YUY2-Mode. Did you shurely set the Card to YUY2 and not RGB24? Second thing..., if you are using BT-Tweaker, there's an otion on it called "Full Luma Range". You should not use this, it gives you a wrong Range in YUY2-Mode. Maybe this is driver related.

19th February 2004, 05:53	#64 \| Link
trevlac budala Join Date: Oct 2003 Location: U.S. Posts: 545	@Kika This thread got me re-interested in the whole YUV to RGB conversion thing. So I made an avisynth plugin to convert from YUY2 to RGB without changing the range. Basically, I followed Poynton's formulas for studio RGB. The plugin is here. The function is YUY2toRGB219(interpolate=true). Default for interpolation is false. It just does an average across the 2 closest pixels for every other pixel. I did a bunch of testing and here are my basic findings: - YUY2 contains about 25% of the colors available in RGB255 - The remapping that occurs for a normal RGB255->YUV235 changes the colors(not by much) - Converting from RGB->YUV without remapping again changes the colors due to the limits of 8 bit YUV storage - If you go RGB->10 bit YUV and limited remapping, it appears you do not change the colors - Going from YUV->RGB219 and not remapping appears to NOT change the colors. RGB is a big enough space and efficiently uses the 8 bits, so there does not appear to be loss. - Going from YUV->RGB255 can truncate data out of the nominal range. I did not test to see if the remapping looses anything. So... the good news appears to be that if you start with YUV, going to RGB219 should not loose you anything. Unfortunately, you will have to go back to YUV 4:2:0 for mpeg. I'm not sure what happens in that process ... PS: My tests were not that scientific. I used the sweep I posted in this thread, and some 75% color bars. A difficulty of the testing is to seperate RGB->YUV conversion errors from YUV->RGB ones. This is because my test material starts life as RGB. I did get better results than overlay, but test for yourself.....

19th February 2004, 10:24	#65 \| Link
Wilbert Moderator Join Date: Nov 2001 Location: Netherlands Posts: 6,364	@Trevlac, Could you try ConvertToRGB(clip, "rec709") I think it should do the same, but I never tested it.

20th February 2004, 16:56	#73 \| Link
Wilbert Moderator Join Date: Nov 2001 Location: Netherlands Posts: 6,364	@Kika, Your suggestions are incomplete. I mean they are fine if you use CCE. But if you use TMPGEnc, there must be conversions YUV-> RGB, RGB->YUV somewhere. I don't think you can capture this case in a simple rule (ok, rules are simple, but the understanding is not simple). It is either: Best advice in that case, is to open the source in YUY2 in AviSynth, and convert to RGB in AviSynth (at some point).[] Uncheck that option in TMPGEnc. Open the source as RGB in AviSynth, or directly in TMPGEnc itself. Check that option in TMPGEnc. [] modulo this luma shift. If we know what caused it. I have to reread the thread, forgot the conclusions about this.