color adjust necessary in capture->SVCD?

[Arachnotron]

BTW: My YUV-System Codec is msyuv.dll.

Now that is interesting. That implies msyuv.dll acts just like Picvideo when converting from YUV to RGB i.e. it leaves the luma range untouched.

Kinda confirms Trevlac's quotes from Microsoft.

[edit]@Kika.. Your English is excellent! :)

[Wilbert]

This Shifting-Thing... i still have no idea why this happens. It can be solved by using ColorYUV(off_y=16). But i think, it's a better way to open PicVideo-Source in RGB24, not YUY2.
Strange, that Trevlac doesn't see it in his avs-pic-avs test. Do you (and Trevlac) use different versions of PicVideo?

[Arachnotron]

What if TMPGenc, like avisource with pixeltype rgb24, also requests RGB from the codec?

So, if you read the AVI directly in TMPGenc, PICvideo delivers RGB directly. No conversion needed by the default system codec!

If you open in avisynth with pixeltype=RGB24, again picvideo delivers RGB to avisynth, which passes it on unchanged to TMPGenc

But if you ask for YUY2 in avisynth with pixeltype=YUY2, TMPGenc gets YUV2 and has to convert by the system YUV2 codec. Only now it is MSyuv.dll for Kika.

Trev uses PIC as default YUV2, so for him all three cases get the same result.

So, the shift bug is in MSyuv NOT picvideo

Should be easy to test by changing the system yuv2 codec.

[Kika]

@ Arachnotron

I agree absolutly.


Should be easy to test by changing the system yuv2 codec.

That's interesting, but..., how to do this? Such Things arent my special field (Windows... argl! ;) )

]@Kika.. Your English is excellent!

That's kind, thanks, but i know my weakness. ;)

@Wilbert
I'm using PicVideo 2.10.0.21

[Arachnotron]

@kika

In windows 98 this info is in the system.ini.
open the c:\windows\system.ini in notepad

look for the [drivers32] header. It should look something like this:

[drivers32]
msacm.lhacm=lhacm.acm
VIDC.IV50=ir50_32.dll
msacm.iac2=C:WINDOWSSYSTEMIAC25_32.AX
VIDC.IR32=C:WINDOWSSYSTEMIR32_32.DLL
VIDC.IR31=C:WINDOWSSYSTEMIR32_32.DLL
VIDC.IR41=C:WINDOWSSYSTEMIR41_32.AX
VIDC.MPG4=C:WINDOWSSYSTEMmpg4c32.dll
VIDC.MP42=C:WINDOWSSYSTEMmpg4c32.dll
VIDC.MP43=C:WINDOWSSYSTEMmpg4c32.dll
VIDC.IV41=ir41_32.dll
msacm.msaudio1=msaud32.acm
VIDC.MPG4=mpg4c32.dll
VIDC.MP42=mpg4c32.dll
VIDC.VIVO=ivvideo.dll
VIDC.TR20=tr2032.dll
VIDC.YVU9=iyvu9_32.dll
VIDC.CVID=iccvid.dll
VIDC.MKVC=KMVIDC32.DLL
VIDC.YUY2=msyuv.dll
VIDC.UYVY=msyuv.dll
VIDC.YVYU=msyuv.dll
etc. etc........

change this line to:

VIDC.YUY2=pvmjpg20.dll

(it might also be pvmjpg21.dll)

Safe, re-boot and try.

I'm not absolutely certain about the name of the picvideo dll file.

[trevlac]

Hi,

On my work machine NT4.0 I had what ever is on PICs site today.
At home w2k I have 2.10.0.25. I get the same results.

At home for VICD.YUY2 I have huffyuv.dll. However it does not seem to matter. It still seems to call MSYUV.dll regardless.

There seem to be different versions of this that do different things.

Some MSYUV links:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/directx/htm/msyuvcolorspaceconvertercodec.asp
http://lists.mpegif.org/pipermail/mp4-tech/2002-July/001030.html

There are reports of 5 bit truncation, but I did some tests and did not find that.

------------------


I did some more tests with the following script. You can change betweew YUY2 and RGB24 using the mode. Also, you can switch between the OS converter and AVS commenting/uncommenting the ConvertToRGB24().

From this you get the entire grey scale. If you ask blankclip for RGB24, it looks good. If you ask for YUY2 there are rounding errors all along the way. If the default OS converter converts to RGB, you get rounding errors and truncation at the end.


mode="YUY2"

black = blankclip(width=400,height=1,pixel_type=mode,color=$000000)
addBlack(black,1,mode)
converttorgb24()

function addBlack(clip c, int num, string mode) {
clr = num * 256 + num + (num * 65536)
return (num > 255) ? c \
: addBlack(stackVertical(c,blankclip(width=400,height=1,pixel_type=mode,color=clr)),num+1,mode)

}


I see the errors with the vdub histo.
I also, saved the vid to PIC. Then asked PIC for YUY2 (which would have been a RGB->YUY2 conversion by PIC). With the histo in AVS, I see no rounding errors.

I plan to do more testing. sh0dan pointed out the gory conversion details in Overlay.

[Kika]

@Arachnotron

Thanks, guess i can handle this. ;)

@trevlac
This Rounding Errors are the Reason why im begging for a way to change the Color space in AVIsynth without changing the Luma Range or anything else.
If the only reason for changing the Color space is to use a Filter which needs a special Color space, i does not make much sense (imho) to change anything in the Video.

[trevlac]

@Kika


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


If you use the above instead of convertToRGB24() it will give you RGB in 16-235 range. There seem to be a few little problems, so use it at your own risk or research it. Latest AVS 2.5.4

Problems:
- There are still some rounding errors causing Red and Blue to shift up by 1 and luma and green down by 1.
- Also, rounding causes some pixels to shift, but there appear to be no gaps like you get from convertToRGB24()
- It is not clear what is done for the chroma upsampling. To go from YCbCr 4:2:2 (YUY2) to RGB you need to double the chroma. I don't know how sh0dan does this in overlay. There are some reasons not to interpolate but just double the pixels. However, if you use it as a converter, you would want the chroma interpolated.


Another option:
I saw Wilbert point to a .jp page that seemed to have a convert pulgin that may give you the options.

http://members.at.infoseek.co.jp/kiraru2002/

colorYUY2 appears to do it all. How's your Japanese ? :D

BTW: I think your english is as good as mine. Arachno's is better than mine, und Englisch ist alles, das ich spreche. (Babel Fish Translation ... did it work?)

[Kika]

@trevlac

I didn't try the Overlay Command yet, enough other problems to solve. ;) I will give it a try.

This PlugIn looks interesting.

How's your Japanese ?
Ž„‚Í“ú–{Œê‚ð˜b‚³‚È‚¢ :devil:
(edit: Guess it looks wrong in the Browser)

(Babel Fish Translation ... did it work?)

Yeah, kind of... ;)

[trevlac]

colorYUY2 appears to do it all.


ColorYUY2 does not appear to convert to RGB. It has the input options, but reading the code (and testing) it seems to convert to RGB for some processing, and then back to YUV. There is code that converts 4:2:2 to 4:1:1.

Not sure what convert="RGB24" was not implemented. :(

[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").

Thx

[trevlac]

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]

@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]

@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 (http://www.poynton.com/notes/colour_and_gamma/ColorFAQ.html#RTFToC31). The plugin is here (http://trevlac.us/colorCorrection/YUY2toRGB219.zip). 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]

@Trevlac,

Could you try

ConvertToRGB(clip, "rec709")

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

[Kika]

@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. ;)



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]

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 (http://tig.colorist.org/twiki/bin/view/Main/BitDiscussion)

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]

@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.


#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]

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]

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]

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. :D

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


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.


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]

I may get flamed for this

Not by me, i agree to you.

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... :eek:
Or they have done so much shinkings and expandings of the range, that the resulting Video will have very pale colors.

[Wilbert]

@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]

@Wilbert

Yeah, things never are realy simple. ;)

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