color adjust necessary in capture->SVCD?

[george_zhu]

I capture video from analog camcorder and encode it into SVCD or VCD to play on TV. I use CCE for SVCD and TMPG for VCD. In the Avisyth's guide, they suggest some color adjustment about to change YUV value to 0-255. Do I need to do it since the final is also in limited range? Or is it better to input full-range clip as the source in CCE/TMPG?

[trevlac]

I believe it all depends upon your process.

For example:

- If you capture in YUY2, you should have a range of 16-235
- If you ever convert to RGB, you probably now have a range of 0-255
- Capture with an mjpeg codec is an exception. You can get RGB 16-235 out of one of them.

You should match what you have with the encoder options. For example, it is my understanding (from a quick look at the manual), that the 16-235 option for CCE means your input is RGB 0-255 and CCE will convert it to 16-235 YCbCr. The 0-255 option means your input is RGB 16-235 (like from mjpeg) and CCE will not change it when it converts to YCbCr. From what I can tell, this option should only effect RGB input. It also seems backwards, but my comments are based upon the formula they show.

If you are asking if you should intentionally change things, I'd say no.

If you tell me if you have RGB or YUY2 source and what codec you used, and what you do in the middle (like with avisynth), I will be more specific.

:)

[george_zhu]

Thanks. My procedure is: capture at PicMJPG(Q19), edit it in adobe premiere, then encode into SVCD (CCE) or VCD (TMPG).



Originally posted by trevlac
I believe it all depends upon your process.

For example:

- If you capture in YUY2, you should have a range of 16-235
- If you ever convert to RGB, you probably now have a range of 0-255
- Capture with an mjpeg codec is an exception. You can get RGB 16-235 out of one of them.

You should match what you have with the encoder options. For example, it is my understanding (from a quick look at the manual), that the 16-235 option for CCE means your input is RGB 0-255 and CCE will convert it to 16-235 YCbCr. The 0-255 option means your input is RGB 16-235 (like from mjpeg) and CCE will not change it when it converts to YCbCr. From what I can tell, this option should only effect RGB input. It also seems backwards, but my comments are based upon the formula they show.

If you are asking if you should intentionally change things, I'd say no.

If you tell me if you have RGB or YUY2 source and what codec you used, and what you do in the middle (like with avisynth), I will be more specific.

:)

[trevlac]

When you capture do you choose RGB or YUY2? PIC supports both. If you choose RGB, what capture card do you have?

You should capture in YUY2, use YUV only in Adobe, then there should be no problems in CCE.

If you capture in RGB, you probably should pick 16-235 in CCE.
If you capture in YUY2 but use RGB in adobe, you probably should pick 0-255 in CCE.

I don't know what the options in TMpeg do. Regardless, you can test all of this by making a black clip in avisynth (RGB=0) and running it thru the process. If the end product is not black (like RGB=16,16,16) then you have a problem. Use a color picker to see the values all the way thru the process if you can.

To try to answer your original question: You need to know your range from the start. If you do, there is little reason to change. You must tell your encoder the proper range.

Hope this helps.

[Arachnotron]

In TMPEGEnc choose:

MPEG settings,
Quantizise matrix tab,
enable/disable "Output YUV data as Basic YCbCr not CCIR601"

From the Help text:
then, Y range of MPEG YCrCb is not 8-235 but 0-255.
Since DV format is already recorded as CCIR601, better result can be expected if this option is enabled.

I assume the 8 is a typo and should be 16.

I do not know if TMPGEnc accepts pure YUV sources, or converts to RGB first. I read somewhere TMPEGEnc always converts to RGB if you enable one of the filters, but the quote above makes me unsure of this.

If there is a RGB conversion involved, you have to know which codec does that and what that one does.

[george_zhu]

I think Adobe only use RGB32, doesn't it?

Originally posted by trevlac
When you capture do you choose RGB or YUY2? PIC supports both. If you choose RGB, what capture card do you have?

You should capture in YUY2, use YUV only in Adobe, then there should be no problems in CCE.

If you capture in RGB, you probably should pick 16-235 in CCE.
If you capture in YUY2 but use RGB in adobe, you probably should pick 0-255 in CCE.

I don't know what the options in TMpeg do. Regardless, you can test all of this by making a black clip in avisynth (RGB=0) and running it thru the process. If the end product is not black (like RGB=16,16,16) then you have a problem. Use a color picker to see the values all the way thru the process if you can.

To try to answer your original question: You need to know your range from the start. If you do, there is little reason to change. You must tell your encoder the proper range.

Hope this helps.

[Wilbert]

I assume the 8 is a typo and should be 16.
Yup.

I do not know if TMPGEnc accepts pure YUV sources, or converts to RGB first. I read somewhere TMPEGEnc always converts to RGB if you enable one of the filters, but the quote above makes me unsure of this.
Afaik it always converts to RGB24.


enable/disable "Output YUV data as Basic YCbCr not CCIR601"

From the Help text:

quote:

then, Y range of MPEG YCrCb is not 8-235 but 0-255.
Since DV format is already recorded as CCIR601, better result can be expected if this option is enabled.
If this is true, something weird is going on. Because, in general, it is false. A while ago I made some tests (last 2-3 three posts of mine):

http://www.kvcd.net/forum/viewtopic.php?t=5202&postdays=0&postorder=asc&start=48

My conclusions were:

"conclusion: the scaling (16,235)->(0,255) is performed when the option "output YUV as Basic YCbCr and not CCIR601" is checked."

"My conclusion is that all YUV values with Y<16 is clamped to (Y,U,V)=(16,128,128) when leaving "output YUV as Basic YCbCr and not CCIR601" unchecked.

I guess all values with Y>235 are clamped to (Y,U,V)=(235,128,128), but I didn't check this."

Strangely enough, in the tests, TMPGEnc was feeded with RGB24. So, no color conversions took place.

IMO: If you feed it with DV-avi, it will do the conversion to RGB24 by itself. If the conversion is done correctly, you should uncheck that option. I don't have time to do some tests :(

I think Adobe only use RGB32, doesn't it?
Yup.

[Kika]

Wilbert, i'm sorry, but you are wrong.

TMPGEnc is working this way:
In CCIR-Mode, the range is compressed from 0-255 to 16-235.
In YCbCr-Mode, the range isnt changed. So if your Source is already in 16-235, use YCbCr. Is it in 0-255 then use CCIR.
TMPGEnc never clamps anything.

But be carefull about the Source, it depents on the Conversion (YUV-RGB) what exactly happens.

As an Exampel: If the Source is PICVideo MJPEG from a TV-Card in YUY2-Mode, you have Source with the Range of 16-235. If you are using AVIsynth with AVISource and Pixeltype = YUY2 to open it, the Range is shifted to 0-219! By using Pixeltype = RGB24, the Range is correct. If you are using TMPGEnc on this Source, you MUST use YCbCr-Mode to get the correct Luma-Range.

[Wilbert]

We have had this discussion before on the german forum. That behaviour of PicVideo you saw is somehow caused by PicVideo itself and not by TMPGEnc. If you don't agree, you will have to explain me the results of my tests.

I asked you for:

1) A PicVideo test-avi + codec. So, that I also could have a look at it.

2) Whether you could do this test with other codecs, like huffyuv.

As an Example: If the Source is PICVideo MJPEG from a TV-Card in YUY2-Mode, you have Source with the Range of 16-235. If you are using AVIsynth with AVISource and Pixeltype = YUY2 to open it, the Range is shifted to 0-219!
This is a very important remark, it explains a part of the strange behaviour! How did you check this? Could you try the following:

a) Shift the range back to 16-235 by using ColorYUV(off_y=16)

b) Add (as a last line) ConvertToRGB24 line in AviSynth.

c) Use TMPGEnc which the setting checked _off_

What are the results?

Anyway. I still don't completely understand what's going on. If you open the avi directly in TMPGEnc, then I assume that PicVideo is converting to RGB24 by itself. In your post, you said that the conversion to RGB24 was accurate: "By using Pixeltype = RGB24, the Range is correct." Ok, that's in AviSynth, but that doesn't matter. If you turn of the setting in TMPGEnc, nothing should happen. But remembering, our discussion at the german forum, it is still messed up.

[Kika]

@Wilbert

Since our Discussion i've tested this with a lot of Source-Materials, not only MJPEG. From DV with different Codecs, from MPEG2-Source, i've checked TMPGEncs behavior also with Pictures and many other things. I've used AVISynth or other Methodes to get the Source into TMPGEnc. But the Results are always the same:

YCbCr: It takes the Source as is.
CCIR: It compresses the Range.

That's the TMPGEnc-Part. This Encoder act's like descriped in the Help-Text (look at Arachnotrons Posting).

Do you remember the AVISynth Scipts i postet in our Discussion?

avisource("CAPTURE.00.avi",true,"RGB24")
assumeTFF()
ConvertToYUY2(interlaced=true)


avisource("CAPTURE.00.avi",true,"YUY2")
assumeTFF()

They are just for testing. On my machine, TMPGEnc can read YUY2 directly, but if i use ConvertToRGB24() at the End of the Script, the Results are the same.
Source is MJPEG from my TV-Card in YUY2-Mode.

The first Script is giving me the correct Luma-Range, the Second is shifting the Range. Shifting it back by using ColorYUV corrects this. Guess, that's a fault of PicVideo, but it shows a Problem: What is AVISynth or an other Program using for decoding while Reading an AVI? And does this Codec do a correct Conversion if needet?
The first Script gave me the same Results like opening the MJPEG-Video directly in TMPGEnc. If i'm capturing in HuffYUV than it's also the same. I have to use YCbCr in TMPGEnc to get the correct Luma-Range.

Things are changing completly, if i'm capturing in RGB24, not YUY2. Than i get a Source-Luma Range of 0-255! And than i have to use CCIR-Mode in TMPGEnc.
ConvertToRGB24() as the last line is only needed (on my PC) if anything other used than RGB or YUY2. In most cases, i'm carfull, so i use this Line.

I think, the Problem isn't TMPGEnc. It realy acts like i wrote, that's proven and it does make a lot of sense. The problem is the Source:
What Decoder is used?
What Luma-Range is used?
If converted, is the conversion correct?

[trevlac]

I would have to humbly disagree with Wilbert's conclusions.


I assume TMPGEnc only accepts RGB. If it accepted YCbCr, I doubt it should be messing with conversions and clamping because it is going to output YCbCr
Any RGB source input into TMPGEnc got that way because of some other program. If it came from Avisynth with an explicit ConvertToRGB, Avisynth did the conversion from YUV to RGB. If it came from Avisynth without conversion, the default system codec did the conversion. If it came in as a direct avi file, the codec for that avi file did the conversion.
TMPGEnc does not clamp. The codec/avisynth whatever does the clamp when it converts.
In Wilbert's test, he created YUV source and did an explicit convert to RGB using Avisynth. This is where the clamp occured.
In the test, Avisynth also mapped from the 16-235 range to 0-255 with the ConvertToRGB command. So when TMPGEnc was "unchecked", it mapped back to 16-235.
Unchecked should be the default. Most RGB is in the range of 0-255.
When MJpeg codecs convert from YCbCr to RGB, they do not seem to change the range. So in this case, if you have YUV in MJPEG check the box in TMPGEnc


Since george has not said if he captured in YUY2 or RGB, I'll assume YUY2. George should use the 0-255 option in CCE and Check the box in TMPGEnc.

Why?

YUY2 is captured in a range of 16-235. If you open the avi in Adobe, PIC will convert to RGB and keep the same range. (It will look washed out in Adobe). Unless Adobe changes the range, it will output RGB in 16-235 Range. In CCE 0-255 means CCE should not mess with the range. This is good if you already have 16-235. In TMPGEnc, checked means TMPGEnc should not mess with the range. Again, this is good if you already have 16-235.

This of course is all just connecting the dots on my part. George should make a black clip and run it thru his process. Pick the color before and after. If it's still the same, regardless of the conversions that take place in the middle, it's probably good enough. :D

[Kika]

@trevlac

That's exactly what i meant. :)


(and maybe, somedays, my english becomes good enough to write such stuff not the clumsy Way i'm doing now... :rolleyes: )

[Arachnotron]

Quote from Kika:
Things are changing completly, if i'm capturing in RGB24, not YUY2.

To add to the confusion:

According to the specs, my Philips SAA7134 tries to put black at 16 and white at 235 in YUV. If you ask it for RGB, it will keep this range, so 16 is still black in RGB. It does NOT convert the Y 16-235 to 0-255 RGB ! But, this might not be the case for other capture devices.

RGB is hell....:devil:

[edit] corrected a mistake (bold)

[Wilbert]

TMPGEnc does not clamp. The codec/avisynth whatever does the clamp when it converts.
In Wilbert's test, he created YUV source and did an explicit convert to RGB using Avisynth. This is where the clamp occured.
In the test, Avisynth also mapped from the 16-235 range to 0-255 with the ConvertToRGB command. So when TMPGEnc was "unchecked", it mapped back to 16-235.
Ok, I agree with this. Btw, I never disagreed with the latter.

What did you think about the first conclusion:


"conclusion: the scaling (16,235)->(0,255) is performed when the option "output YUV as Basic YCbCr and not CCIR601" is checked."

When MJpeg codecs convert from YCbCr to RGB, they do not seem to change the range. So in this case, if you have YUV in MJPEG check the box in TMPGEnc
Are you saying that the first conversion YCbCr -> RGB is incorrect? This is not the case according to Kika:

"avisource("CAPTURE.00.avi",true,"RGB24")
assumeTFF()
ConvertToRGB24()

(...)

The first Script is giving me the correct Luma-Range"

edit: with incorrect I mean [16,235] YCbCr to [16,235] RGB or something like that.

I'm also wondering about this:
If you are using AVIsynth with AVISource and Pixeltype = YUY2 to open it, the Range is shifted to 0-219!
How is this possible?

[Kika]

Are you saying that the first conversion YCbCr -> RGB is incorrect? This is not the case according to Kika:

Wilbert, that's correct and exactly what i said. The internal Conversion of MJPEG-Codecs (YUY2 -> RGB24) does not touch the Luma-Range.

I'm also wondering about this:
--- snip ---

I guess that's a Bug, no idea where it come from. Maybe it's a Bug in PICVideo, maybe in AVISynth, i don't know.

[trevlac]

Hi,

This is all a bit messy... but I'll try to be clear on what I think.

Originally posted by Wilbert
What did you think about the first conclusion:

"conclusion: the scaling (16,235)->(0,255) is performed when the option "output YUV as Basic YCbCr and not CCIR601" is checked."


TMPGEnc never should go 16,235 -> 0,255. That only makes sense for a YCbCr -> RGB conversion. It should only ever do RGB->YCbCr. Checking the box should tell it that RGB source is in the 16,235 range and it should not change it.


Are you saying that the first conversion YCbCr -> RGB is incorrect? This is not the case according to Kika:

"avisource("CAPTURE.00.avi",true,"RGB24")
assumeTFF()
ConvertToRGB24()

(...)

The first Script is giving me the correct Luma-Range"



I like how PIC converts. It gives RGB without clamping. So incorrect depends on what you are trying to do.

He said that input from PIC RGB or YUV gives different results. At the point of input to Avisynth, they are the same range 16-235. When he inputs to TMPGEnc the YUV one gets converted by his default YUY2 codec (in the registry, probably microsoft) to RGB. Now it is 0-255. So he sees different results in TMPGEnc. If he puts a ConvertToRGB24 at the end of his scripts, it probably does nothing to the RGB input (so it stays as 16-235) and it converts the YUV to RGB 0-255. So his results are the same using ConvertToRGB24 or letting the default codec convert to RGB.

I'm not sure if TMPGEnc really accepts YCbCr. You can test this with PIC. Under the advanced config of the codec you can check "Force YUY2 Output". If you can open some PIC YUY2 source in TMPGEnc with that checked, TMPGEnc is ok with YUY2. VirtualDub for example is not.

His comment about correct is not clear. PIC YUV input to Avisynth as RGB will be in the range 16-235. Same as PIC YUV avi input to TMPGEnc. In these cases I would check the box. That way TMPGEnc does not change the range.


I'm also wondering about this:
AVS and AVISource YUY2 = 0-219
How is this possible?

I don't think that is the case. Regardless, to back that up, one would have to say what the source is, and how it was determined that a shift occured. The codec would more be the suspect than AVS.


BTW: I did a few tests on PIC and tried to explain some other test results in the following thread.

http://forum.doom9.org/showthread.php?s=&threadid=55800&perpage=20&pagenumber=1

[Arachnotron]

quote:
I'm also wondering about this:
AVS and AVISource YUY2 = 0-219
How is this possible?

I don't think that is the case. Regardless, to back that up, one would have to say what the source is, and how it was determined that a shift occured. The codec would more be the suspect than AVS.

This looks like 16-235 which has been given a new offset. substract 16 and you get 0-219.

[Kika]

His comment about correct is not clear.

OK, ok, it's my clumsy english... :o

PIC YUV input to Avisynth as RGB will be in the range 16-235. Same as PIC YUV avi input to TMPGEnc. In these cases I would check the box. That way TMPGEnc does not change the range.

Yes, that's what i wanted to say.

If i use YUY2 as Pixeltype, the Range isn't correct, if i use AVISource without the Pixeltype Statement, the Range also isn't correct. In both cases, this Shifting occurs (0-219). I think, that's a Bug of the Codec. Only with Pixeltype RGB24 i get the correct Luma-Range.
I said correct because the Captures are in YUY2 with the Range of 16-235, so that's what i need in AVIsynth and in TMPGEnc.

Checking the box should tell it that RGB source is in the 16,235 range and it should not change it.

Yes.

TMPGEnc only accepts RGB-Input. Without ConverttoRGB24() at the end of a Script, a System-Codec is used to convert to RGB. And on my maschine, this conversion is not distorting or clamping or compressing the Luma-Range.
BTW: Is there i way to determine which Codec is used to do this?

Edit:

This looks like 16-235 which has been given a new offset. substract 16 and you get 0-219.

Yes, that's what happens. It can be correct by this Line:
ColorYUV(off_y=16)

But i don't like this much. Every time, i use ColorYUV to correct anything, the Histogram shows me a slight distortion of the Levels.

[Arachnotron]

BTW: Is there i way to determine which Codec is used to do this?look in the registry for

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32]

"VIDC.YUV2"="?????????????"

(fill in your codec dll here)

[edit] default is msyuv.dll

[Kika]

Guess i have to try this at Home. On my PC here in the Office (Win98SE) there's no msyuv.dll. :rolleyes:

At home (also Win98SE), i have deleted msyuv while the Testing.
Whatever, it works, that's what realy matters. :D

[Arachnotron]

Sorry! This is for w2k/winXP only. Windows 98 does not have this key; don't know where they keep it there.
Perhaps somewhere in the system.ini or win.ini

[Kika]

No problem, if it is somewhere in the Registry or the INIs i will find it. ;)
Thanks.

[Arachnotron]

Or try the avicodec util, over here (http://sourceforge.net/projects/mediainfo/)

[Wilbert]

His comment about correct is not clear. PIC YUV input to Avisynth as RGB will be in the range 16-235.
Well, this is not what Kika said. Maybe he can provide some screen shots as proof :)

[Kika]

@Wilbert

That's exactly what i said:

Source is MJPEG from my TV-Card in YUY2-Mode.
avisource("CAPTURE.00.avi",true,"RGB24")


And that's, what trevlac wrote:

PIC YUV input to Avisynth as RGB will be in the range 16-235.

[Wilbert]

:confused: :confused: :confused: RGB should be 0-255 if has to look like the original (when viewing the script in vdub for example).

[trevlac]

Originally posted by Wilbert
:confused: :confused: :confused: RGB should be 0-255 if has to look like the original (when viewing the script in vdub for example).

You are correct. It will not look correct in VDub (or Adobe for George).

However, "microsoft" seems to think that (16-235) "is the preferred RGB definition for video in Windows" .

http://forum.doom9.org/showthread.php?s=&threadid=69866

Now that's confusing. ;)


BTW: phaeron, sh0dan, and quite a few others think PIC is wrong/buggy.


I was just trying to clearify how this all seems to work.....

[Kika]

OK, let's try to make things a little more clear.

We are talking about two different topics here:

1. How is TMPGEnc working in CCIR and YCbCr Mode
I think that's clear now.
CCIR compresses the range from 0-255 to 16-235
YCbCr takes the Source as is. Usefull if the Source is already in 16-235

2. What the heck is PicVideo doing?
That's an other Story.
Most Capture-Cards are working with the Range of 16-235 in YUY2-Mode.
If we capture YUY2-Source with PicVideo, we have to Read this in RGB24-Mode to get the correct Luma Range.
Opening the Video directly in TMPGEnc is the same than using AVISynth with avisource("CAPTURE.00.avi",true,"RGB24")

Why it is acting like this... no idea, it IS acting like this.

[trevlac]

Originally posted by Kika
If we capture YUY2-Source with PicVideo, we have to Read this in RGB24-Mode to get the correct Luma Range.


I'm not sure what you mean. I'm not sure what the issue is. If you encode anything in PIC, it does not convert the range. So, if you like the range you encoded, you are set. YUY2 should be just as good as RGB. I did some tests (see link in prior post). PIC YUY2 did not change anything in my tests.

Personally, I like the fact that PIC does not change range. This is because changing range requires the conveter to "clamp". Meaning anything below black or above white is made to equal black or white.

Most people would say that there is nothing outside of the nominal range, but in my experience, with my devices, there is. PIC is an easy method to look outside of the nominal range in RGB.

----
If you mean avisource type=yuy2 does not work; this is because your default codec is changing the range. YUY2 is going out of avisynth. TMPGEnc is asking for RGB. PIC is not converting. Your default codec is. In this case CCIRC 601 in TMPGEnc.

[Kika]

Again, on my PC, there is a difference between

avisource("CAPTURE.00.avi",true,"RGB24")

and

avisource("CAPTURE.00.avi",true,"YUY2")

if i use PicVideo for Capturing from my BT-Card in YUY2-Mode.

With RGB24, all is OK, nothing is clamped, nothing changed.
With YUY2, this shifting i mentioned occurs.

An Example:

avisource("CAPTURE.00.avi",true,"RGB24")
assumeTFF()
ConvertToYUY2(interlaced=true)
#do something what needs YUY2 Colorspace
ConvertToRGB24(interlaced=true)

This works perfectly with any Program i use to open this Script.
The following Script gives me the wrong range (shifted):

avisource("CAPTURE.00.avi",true,"YUY2")
assumeTFF()
#do something what needs YUY2 Colorspace
ConvertToRGB24(interlaced=true)

No matter what Program i use to open this Script, the range is always wrong.

And the following Script corrects this Problem with slightly distorted Luma-Levels but the correct range:

avisource("CAPTURE.00.avi",true,"YUY2")
assumeTFF()
ColorYUV(off_y=16)
#do something what needs YUY2 Colorspace
ConvertToRGB24(interlaced=true)

[Arachnotron]

@Kika,

Which codec is the standard codec for YUV2 on your system? (try the util I posted or look under the [drivers32] heading in your system.ini)

@Wilbert
Perhaps it would be an idea to create a list of common codecs used for capping and what they do with YUV2 > RGB conversions. I don't know if this warrants inclusion in the capture guide. I suppose this is an issue for any video processing program down the line which works in RGB.

[trevlac]

Ok, How about this ....

Originally posted by Kika
An Example:

1. avisource("CAPTURE.00.avi",true,"RGB24")
assumeTFF()
2. ConvertToYUY2(interlaced=true)
#do something what needs YUY2 Colorspace
3. ConvertToRGB24(interlaced=true)

This works perfectly with any Program i use to open this Script.

Step 1 opens the source in 16-235 range (Black = 16)
Step 2 changes the range to something like 32-220 (Black = 32)
Step 3 changes the range back to 16-235 (Black = 16)


The following Script gives me the wrong range (shifted):

1. avisource("CAPTURE.00.avi",true,"YUY2")
assumeTFF()
#do something what needs YUY2 Colorspace
2. ConvertToRGB24(interlaced=true)

No matter what Program i use to open this Script, the range is always wrong.

Step 1 opens the source in 16-235 range (Black = 16)
Step 2 changes the range to 0-255 (Black = 0)


And the following Script corrects this Problem with slightly distorted Luma-Levels but the correct range:

1. avisource("CAPTURE.00.avi",true,"YUY2")
assumeTFF()
2. ColorYUV(off_y=16)
#do something what needs YUY2 Colorspace
3. ConvertToRGB24(interlaced=true)

Step 1 opens the source in 16-235 range (Black = 16)
Step 2 moves the range to 32-251 (Black = 32)
Step 3 changes the range to 16-255 (Black = 16)(if not for clamp it would be 16-271)

Open anyone of those scripts in vdub. Use This (http://trevlac.us/colorCorrection/clrtools.vdf) plugin. Change the default settings from 0-255 to 16-235 and uncheck the Red, Green, & Blue channels boxes. You will see the full range histogram. It will move around depending on the script. If you open the PIC source directly in VDub you will see what PIC gives Avisynth in all of the step 1(s) above. Note the min and max numbers.

Convert to YUY2 in avs will compress the range.
Convert to RGB in avs will expand the range.
Off_y=16 is the same thing as moving the brightness up.

What do you think ?

[Wilbert]

What do you think ?
I think that either:

You don't want to read properly, or you don't trust Kika's observations :)

I will repeat them one more time:

a) avisource("CAPTURE.00.avi",true,"YUY2")

Gives a shifted luma range of 0-219. This can easily be checked by using the histogram:

avisource("CAPTURE.00.avi",true,"YUY2")
converttoyv12
histogram

Is the luma indeed always smaller than 219? Is it between 0-16 sometimes?

b) avisource("CAPTURE.00.avi",true,"RGB24")

Gives correct output. That means, the luma range is 0-255, and not 16-235. Because if the latter would be true, it would look not correct in vdub. But Kika said it looked correct. I guess this can be checked by using your plugin.

Maybe Kika can do those checks?

[trevlac]

@Wilbert

Sorry...

I read Kika's "looks correct" as 16-235.
And I don't think 'avisource("CAPTURE.00.avi",true,"YUY2")' shifts any values.... it is the ConvertToRGB24 that does the shifting.


I am a bit of a dope you know. Probably don't know what I am talking about. ;)

Trev

[Arachnotron]

Perhaps a bit off-topic, but I have a newbe question about the avisource command.:)
From the manual:

From v2.06 the pixel_type parameter (default YUY2) allows you to choose the output format of the decompressor. Valid values are "YUY2", "RGB32" and "RGB24". If omitted, AviSynth will use the first format supported by the decompressor (in the following order: YUY2, RGB32, RGB24). This parameter has no effect if the video is in an uncompressed format (YUY2, RGB32 or RGB24), because no decompressor will be used in that case. From v2.5 the default pixel_type parameter is changed to YV12. To put it in different words: if you don't specify something it will try to output the AVI as YV12, if that isn't possible it tries YUY2 and if that isn't possible it tries RGB.

Am I correct in assuming that if I have a source which is YUV2 and open it without defining a pixeltype it will default to yv12 and so in effect do a conversion to YV12? (That would mean I have been working in YV12 for a while wiyjout knowing it :) )

The second part I don't get is the phrase "if that isn't possible it tries YUY2 and if that isn't possible it tries RGB"
If these conversions are done inside avisynth, how can they be impossible? I would assume that provided the file can be read, any colorspace supported by avisynth is possible. Or does avisynth depend on the codec in question to do the first conversion, and the result depends on the codec used? Now that would explain a lot.

[edit]

I should have read better.

Some MJPEG/DV codecs do not give correct CCIR 601 compliant output when using AVISource. The problem could arise if the input and output colorformat of the codec are different. For example if the input colorformat is YUY2, while the output colorformat is RGB, or vice versa. There are two ways to resolve it:

1) Force the same output as the input colorformat. Thus for example (if the input is RGB):

So the conversion is (of course) done by the codec, and the pixeltype just tells the codec what to deliver (if possible)

[Kika]

Argl... why things are this complicated?

We had this solved yesterday, why again this complication?

avisource("CAPTURE.00.avi",true,"RGB24")

This Line gives the correct(!) Range: 16-235
There is no coversion be done. The AVI and the AVS do look absolutly similar if opened with TMPGEnc and also VirtualDub.

avisource("CAPTURE.00.avi",true,"YUY2")

This gives the shifted Range of 0-219. As i mentioned yesterday, i think, this is a Bug of PICVideo.

I've checked all of this with different Histogram-Fuctions before and after the Conversion to MPEG. In AVISynth and in exported Pictures, it is always the same. Try it by yourself. Maybe this Shifting is a Bug of PICVideo or the Conversion-Codec on my PC, i have to check out, which one is used.
I think, AVISynth should not do any Range-Conversion by itself, it should do it only if needet by the User.


So the conversion is (of course) done by the codec, and the pixeltype just tells the codec what to deliver (if possible)

That's it.
TMPGEnc always askes for RGB24, in AVISynth, you have to tell the Codec what he should deliver.

[Arachnotron]

avisource("CAPTURE.00.avi",true,"RGB24")

This Line gives the correct(!) Range: 16-235
There is no coversion be done. The AVI and the AVS do look absolutly similar if opened with TMPGEnc and also VirtualDub.

avisource("CAPTURE.00.avi",true,"YUY2")

If I understand this (big IF):

Case 1: file opens in avysynth, and avisynth requests codec to deliver RGB24,passes on to TMPGenc, TMPGenc is happy

case 2: pic codec delivers YUY2 to TMPGenc, TMPGenc requests standard YUV2 codec of system to convert to RGB. For you this is also PIC, so result is the same, but perhaps somewhat slower because of the two calls to pic codec

case 3: I haven't got a clue. If this reasoning is correct, the result should be the same as case 2 unless for some reason the picvideo codec does not understand avisynths request for yuy2 and Avisynth defaults to something else.

And of-course I may not understand all this at all. Very probable I'm afraid:D

[Wilbert]

So the conversion is (of course) done by the codec, and the pixeltype just tells the codec what to deliver (if possible)
Yup, I guess I should it write it down more clearly :)


avisource("CAPTURE.00.avi",true,"RGB24")

This Line gives the correct(!) Range: 16-235
There is no coversion be done. The AVI and the AVS do look absolutly similar if opened with TMPGEnc and also VirtualDub.

As far as I known, this is not true. Forget about TMPGEnc for a while (separate issue :)). When viewing a rgb clip in vdub, 0 is black and 255 is white. If you deliver it rgb 16-235, there won't be pure black and there won't be pure white in it. So, in that case, they will look different. I guess ...

You can easily check this by making a script:
Use blankclip to make a pure black clip. It will have yuv=(16,128,128). Use ColorYUV("PC->TV") to scale it to yuv=(0,128,128). Convert it to rgb. If I understood it correctly you will get rgb=(16,16,16). Open this in vdub. Is it pure black? I don't think so.

Will check it, when I'm at home :)

[Kika]

@Wilbert

OK, let's put TMPGEnc aside ;)
Using blankclip is an other thing. You are producing a Clip with the given Luma-Range/Color-Format.

Opening an AVI with the Pixeltype-Command isn't doing any conversion. It tells the Codec what to deliver to AVISynth. That's the trick. PICVideo does not do a Range-Conversion, it delivers the Range as is - in my case as 16-235.

[Arachnotron]

Use blankclip to make a pure black clip. It will have yuv=(16,128,128). Use ColorYUV("PC->TV") to scale it to yuv=(0,128,128).

should this not be TV->PC :confused:

[Wilbert]

Yes, thanks for the correction!

[Kika]

OK, and here the results for BlankClip and VirtualDub:


BlankClip(color=$ffffff, pixel_type="YUY2")
Converttorgb24()

The RGB-Values are: 255,255,255

BlankClip(color=$ffffff, pixel_type="RGB24")

The RGB-Values are: 255,255,255

BlankClip(color=$ffffff, pixel_type="RGB24")
Converttoyuy2()
Converttorgb24()

The RGB-Values are: 255,255,255

BlankClip(color=$ffffff, pixel_type="RGB24")
Converttoyuy2()

The RGB-Values are: 253,253,253 <- :eek:

BlankClip(color=$ffffff, pixel_type="RGB24")
Converttoyuy2()
coloryuv(levels="PC->TV")
Converttorgb24()

The RGB-Values are: 235,235,235

BlankClip(color=$ffffff, pixel_type="YUY2")
coloryuv(levels="PC->TV")
Converttorgb24()

The RGB-Values are: 235,235,235

As expected (except this "253-Thing")

[trevlac]

I don't see the confusion if you agree with the following:

PIC delivers YUY2 as it came in
PIC delivers YUY2 as RGB as it came in
Converts in AVS change the range
If you have YUY2 going out of an AVS script the OS will convert it to RGB. Most every program wants RGB.


@Kika,

253 happens because your defalut OS YUY2 to RGB converter has a bad calculation/method. I get the same on an NT 4.0 machine.


@Wilbert,

What's 'correct' may be up for debate. What happens should be clear...no?

[trevlac]

OK.... how about this....

Make a YUY2 clip in AVS, black and white:

black = blankclip(width=200,height=400,pixel_type="YUY2",color=$000000)
white = blankclip(width=200,height=400,pixel_type="YUY2",color=$FFFFFF)
stackHorizontal(black,white)
ColorYUV(Analyze=true)


Check it out in vdub. Min=16 and Max=235
http://trevlac.us/wilbert/YUY2Clip.bmp

Remove the last line and fast recompress 1 frame to PIC.



Now use this to see what PIC gives you for YUY2. Crop the PIC logo if you need to.


Avisource("Pic.avi",pixel_type="YUY2")
Crop(0, 100, 400, 200)
ColorYUV(Analyze=true)

Check it out in vdub. Min=16 and Max=235
http://trevlac.us/wilbert/YUVfromPIC.bmp


Now get pic to give you RGB. Convert it to YUV so you can use ColorYUV()


Avisource("Pic.avi",pixel_type="RGB24")
ConvertToYUY2()
Crop(0, 100, 400, 200)
ColorYUV(Analyze=true)

Check it out in vdub. Min=30 and Max=218. This is because PIC delivers RGB as 16-235
and converttoyuy2() shrinks the range some more.
http://trevlac.us/wilbert/RGBfromPIC.bmp


This is what I was saying when I commented on Kika's scripts. Well I said "something like 32-220". But 30-218 is close considering my math skills. :D

[Wilbert]

What happens should be clear...no?
No, not to me.

You say that the clip is opened as rgb 16-235. Fine. Kika says, the clip (opened as rgb) looks fine (that is, it looks the same as the yuy2 one). I don't see how that's possible.

Imo, it should be scaled to rgb 0-255 so that it will look like the original yuy2 (in vdub for example). But now, I'm repeating myself.

You know, the display is asymmetric. When viewing a YUV clip (with whatever player, using whatever filter), it assumes 16-235. When viewing a RGB clip (with whatever player, using whatever filter), it assumes 0-255.

edit:

Check it out in vdub. Min=30 and Max=218. This is because PIC delivers RGB as 16-235 and converttoyuy2() shrinks the range some more.
Ok, I agree with you here. But, I will repeat it again:


Originally posted by Wilbert
RGB should be 0-255 if has to look like the original (when viewing the script in vdub for example).

You are correct. It will not look correct in VDub (or Adobe for George).

The problem is that Kika disagrees with this.

[trevlac]

Originally posted by Wilbert
You know, the display is asymmetric. When viewing a YUV clip (with whatever player, using whatever filter), it assumes 16-235. When viewing a RGB clip (with whatever player, using whatever filter), it assumes 0-255.


This is how I understand it. When viewing a YUV clip something must convert it to RGB. If the clip is MJPEG, the MJPEG codec will convert it for you. When PIC does this, it does not change the range. If you pass raw YUV out of AVS, the OS must convert it to RGB. It will change the range. (And appearently dampen white a bit.)

So, YUV is never displayed. It is always converted to RGB. If the converter does not change the range, it may look washed out.

When Kika says YUV and RGB look the same, it is because both are RGB 16-235 when displayed. He feels that this 'looks fine'.



The problem is that Kika disagrees with this.


AKA: 16-235 RGB 'looks better' than 0-255 RGB


I can think of reasons for why Kika disagrees, and why I just said may look washed out. Correct is subjective. It depends on the original source, on the monitor adjustment, and on opinion. For example, if Kika gets captured YUY2 out of the nominal range, it may look good as 'RGB16-235'. He should probably adjust this before an encode, but it depends on his process, and to each his own.

Personally, I'd say for PC display, Black should=0 and White should=255.

I have recently put a lot of effort into testing/learning this. You may find this funny, but You gave me some of my 1st pointers. YQI vs YIQ .. ;) Nice part is one can actually measure everything and not have to worry too much about what it looks like .... until your final tests.

Cheers

[Kika]

@Wilbert

Guess we are talking about the same things, but we don't understand each other.

I agree absolutly with the results of trevlac. I always get the same results here.

Why i said "better"? That's because my Source from my Capture Card has the range of 16-235 - and that's the range it should have after a propper MPEG-Encoding. MPEG should ever have the range of 16-235.

RGB should be 0-255 if has to look like the original (when viewing the script in vdub for example).

That's ok, but that's not, what PICVideo is doing. It delivers RGB in the "Source range". Like trevlac wrote:

When Kika says YUV and RGB look the same, it is because both are RGB 16-235 when displayed. He feels that this 'looks fine'.

That's what i tried to explain since yesterday. ;)

OK, back to the start. PICVideo is acting like this, and that's because TMPGEnc must be set to YCbCr-Mode in this case.

Simply try the following Script:

blankclip(color=$ffffff, pixel_type="RGB24")
converttoyuy2()
coloryuv(levels="PC->TV")
converttorgb24()

Encode it in CCIR and in YCbCr Mode. Only YCbCr Mode will give you a correct clean color of white - as it should be.

And that's what i like on PICVideo and i dislike in AVISynth. I beg for a kind of Color-Space-Conversion without touching the Luma Range.

[Wilbert]

Guess we are talking about the same things, but we don't understand each other.
;) Nice ...

I will link this thread in the TMPGEnc faq. I will also add something about this in the AviSynt docs.

[Arachnotron]

@Kika, @Trevlac

Excuse my ignorance :(, but I still don't get this part:

avisource("CAPTURE.00.avi",true,"YUY2")

This gives the shifted Range of 0-219. As i mentioned yesterday, i think, this is a Bug of PICVideo.

Has this been resolved now?

[Kika]

I will also add something about this in the AviSynt docs.

That's a good idea, i guess, there are a lot of misunderstandings about how the Pixel_Type Argument in AVISource works.

I think, most people are thinking "Ok, if i use RGB24, the Range is converted to 0-255.". But that's not correct, it depends on (to?) the Codec what exactly happens.

I always talked about PicVideo here, other Codec may act different.

Oh, and sorry for this endless thread. Guess my bad english has complicated things... :o Maybe i should stay at the german boards. *snif*

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

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

[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