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 > Capturing Video

Reply
 
Thread Tools Search this Thread Display Modes
Old 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
george_zhu is offline   Reply With Quote
Old 14th February 2004, 03:17   #62  |  Link
trevlac
budala
 
Join Date: Oct 2003
Location: U.S.
Posts: 545
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 ...?
trevlac is offline   Reply With Quote
Old 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.
Kika is offline   Reply With Quote
Old 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.....
trevlac is offline   Reply With Quote
Old 19th February 2004, 10:24   #65  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,293
@Trevlac,

Could you try

ConvertToRGB(clip, "rec709")

I think it should do the same, but I never tested it.
Wilbert is offline   Reply With Quote
Old 19th February 2004, 11:27   #66  |  Link
Kika
Registered User
 
Join Date: Jul 2002
Location: Germany
Posts: 819
@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.
Kika is offline   Reply With Quote
Old 19th February 2004, 15:33   #67  |  Link
trevlac
budala
 
Join Date: Oct 2003
Location: U.S.
Posts: 545
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 is offline   Reply With Quote
Old 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.

trevlac is offline   Reply With Quote
Old 19th February 2004, 20:01   #69  |  Link
Arachnotron
Alias fragger
 
Arachnotron's Avatar
 
Join Date: Jul 2003
Location: the Netherlands
Posts: 863
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"
Arachnotron is offline   Reply With Quote
Old 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.
Kika is offline   Reply With Quote
Old 20th February 2004, 15:30   #71  |  Link
trevlac
budala
 
Join Date: Oct 2003
Location: U.S.
Posts: 545
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.
trevlac is offline   Reply With Quote
Old 20th February 2004, 15:45   #72  |  Link
Kika
Registered User
 
Join Date: Jul 2002
Location: Germany
Posts: 819
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.
Kika is offline   Reply With Quote
Old 20th February 2004, 16:56   #73  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,293
@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.
Wilbert is offline   Reply With Quote
Old 20th February 2004, 17:07   #74  |  Link
Kika
Registered User
 
Join Date: Jul 2002
Location: Germany
Posts: 819
@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
Kika 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 06:26.


Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.