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.