Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 17th June 2003, 18:40   #1  |  Link
kevina
Registered User
 
Join Date: Jun 2003
Posts: 71
MJPEG AviSynth Color Clipping

I recently discovered a rather disturbing thing, the color gets clipped. That is very dark colors and very light colors get crushed together and the other colors are spread out. After searing this form I discovered there is a filter mjpegcorrect which can help with this problem. I also figured out that using:
Code:
AVISource("file.avi", pixel_type="RGB32")
ConvertToYuy2()
Fixes this problem.

My question is, what is causing this?

I also have a request, could you please make a note of this in the manual under the AVISource section. By not using pixel_type="RGB32" color information is lost. However, the effects of this are not easy to notice, and thus the casual user may not notice until it is too late.

This is especially disturbing to be since I carefully adjust the levels to get the full range after I capture the video. Thus important color information is at both ends of the spectrum and will thus get lost if using Avisource with mjpeg.
kevina is offline   Reply With Quote
Old 17th June 2003, 20:40   #2  |  Link
sh0dan
Retired AviSynth Dev ;)
 
sh0dan's Avatar
 
Join Date: Nov 2001
Location: Dark Side of the Moon
Posts: 3,480
MJPEG is stored in YUV - so what you are getting is actually the correct colors.

I however depends on whether the MJPEG codec upscales the YUV colors, before sending them on. Some have this effect, which is quite undesirable.

Instead of adding a YUV -> RGB32 -> YUV colorspace conversion simply try:

ColorYUV(levels="PC->TV") - this will give you the correct CCIR 601 compliant output.

[unaffiliated note]
I can personally recommend buying Morgan MJPEG - it provides correct luma range, and it even has YV12 in their latest beta.
[/unaffiliated note]
__________________
Regards, sh0dan // VoxPod

Last edited by sh0dan; 17th June 2003 at 20:47.
sh0dan is offline   Reply With Quote
Old 17th June 2003, 21:19   #3  |  Link
kevina
Registered User
 
Join Date: Jun 2003
Posts: 71
Quote:
Instead of adding a YUV -> RGB32 -> YUV colorspace conversion simply try: ColorYUV(levels="PC->TV")
I tried that and it works. However the histogram is not as smooth as given by VirtualDub. And since VirtualDub converts back to RGB it semas that YUV->RGB->YUV->RGB gives better results than YUV->Fix->RGB. Of course if I drop the ConvertToYUY2 I get the best results.

Anyway a mention of this in the AVISynth manual would be very helpful.
kevina is offline   Reply With Quote
Old 17th June 2003, 21:21   #4  |  Link
sh0dan
Retired AviSynth Dev ;)
 
sh0dan's Avatar
 
Join Date: Nov 2001
Location: Dark Side of the Moon
Posts: 3,480
The reason is looks more "smooth" is because of the errors introduced by YUV->RGB->YUY conversion . This is not without loss. Trust me - the result is better, if you avoid doing the conversions, being more true to the original.
__________________
Regards, sh0dan // VoxPod
sh0dan is offline   Reply With Quote
Old 17th June 2003, 22:35   #5  |  Link
waka
Registered User
 
Join Date: Jul 2002
Posts: 29
If you can encode and decode in the same colorspace, preferably YUV, there shouldn't be any problems. If you are capturing to mjpeg in YUV, don't open the mjpeg directly with virtualdub to check the levels. It would be decoded to RGB and what you see in virtualdub is incorrect.

If you are re-encoding to mjpeg, do all your filtering in avisynth so you can use fast recompress in virtualdub. Otherwise you will encode from RGB and likely decode to YUV, again screwing things up.
waka is offline   Reply With Quote
Old 18th June 2003, 04:27   #6  |  Link
kevina
Registered User
 
Join Date: Jun 2003
Posts: 71
waka wrote: If you can encode and decode in the same colorspace, preferably YUV, there shouldn't be any problems.

The problem has nothing to do with colorspace conversion. It has to do with the fact that some "MJPEG codec upscales the YUV colors, before sending them on", as sh0dan pointed out.
kevina is offline   Reply With Quote
Old 18th June 2003, 17:39   #7  |  Link
waka
Registered User
 
Join Date: Jul 2002
Posts: 29
For me, the issue does seem to be caused by colorspace conversions performed by the codec. Everything is fine with zero or two(letting the codec fix itself) conversions. With one conversion, either encoded RGB/decoded YUV or encoded YUV/decoded RGB, there are problems.

Using blankclip(color=$0000f0,pixel_type="yuy2"), starting clip has YUV values of 39, 234, 111. Picvideo mjpeg encoded with fast recompress for YUV or full processing for RGB. Resulting mjpeg opened with avisynth using pixel_type="yuy2" or "rgb32". Values checked with coloryuv(analyze=true), converttoyuy2() as necessary. Last two used coloryuv(levels="tv->pc") or "pc->tv" for correction.

Code:
EncodeYUV/DecodeYUV   Y:39 U:234 V:111
EncodeRGB/DecodeRGB   Y:39 U:234 V:111
EncodeYUV/DecodeRGB   Y:50 U:221 V:113
EncodeRGB/DecodeYUV   Y:27 U:248 V:108
EncYUV/DecRGB tv->pc  Y:40 U:234 V:111
EncRGB/DecYUV pc->tv  Y:39 U:233 V:111
I think sh0dan and myself are more or less describing the same thing. I hope I didn't give him the wrong idea in a previous discussion. I could also be totally wrong.
waka is offline   Reply With Quote
Old 18th June 2003, 20:39   #8  |  Link
sh0dan
Retired AviSynth Dev ;)
 
sh0dan's Avatar
 
Join Date: Nov 2001
Location: Dark Side of the Moon
Posts: 3,480
Silly - I guess the only thing I can learn from that is that Input colorspace and output colorspace from Picvideo MJPEG should be the same. Great test!

Could be funny to crosstest with Morgan to see what it actually stores.
__________________
Regards, sh0dan // VoxPod
sh0dan is offline   Reply With Quote
Old 4th July 2003, 10:23   #9  |  Link
kevina
Registered User
 
Join Date: Jun 2003
Posts: 71
Sh0dan, I removed PicVideo and installed Morgan MJPEG v 3.0.0.9 and I have the exact same problem.

With your codec can you please try the waka test using your codec. Thanks.
kevina is offline   Reply With Quote
Old 25th January 2004, 09:54   #10  |  Link
FulciLives
Registered User
 
Join Date: Apr 2002
Posts: 106
Need help understanding

I capture using PICVideo MJPEG and then I use AviSynth 2.5x and open that in CCE

Do I need to do anything?

I tried the AviSynth script line:

ColorYUV(levels="PC->TV")

and in CCE selected 0-255

The result seemed pleasing to my eyes.

BTW this was with a USA NTSC capture and my capture card was set to NTSC_M

Any advice on this would be most welcomed

- John "FulciLives" Coleman
FulciLives is offline   Reply With Quote
Old 26th January 2004, 19:42   #11  |  Link
trevlac
budala
 
Join Date: Oct 2003
Location: U.S.
Posts: 545
I wanted to comment on this mystery. I'm not sure this behavior is a bad thing. It's just that one should know what is going on to properly use the tools.

The differences are due to mapping from YUV to RGB. This means going from a 16-235 range to a 0-255 range (or not).

I've done a bunch of reading, and it seems that 'video people' think mappping is a bad thing, because 1) it removes headroom, 2) introduces more rounding errors. We PC people do not (as much).

Here is a link to comments from a serious 'video person'.


Quote:
Originally posted by waka

Code:
1. EncodeYUV/DecodeYUV   Y:39 U:234 V:111
2. EncodeRGB/DecodeRGB   Y:39 U:234 V:111
3. EncodeYUV/DecodeRGB   Y:50 U:221 V:113
4. EncodeRGB/DecodeYUV   Y:27 U:248 V:108
5. EncYUV/DecRGB tv->pc  Y:40 U:234 V:111
6. EncRGB/DecYUV pc->tv  Y:39 U:233 V:111
The possible steps in this test were:
  1. Create YUV clip in Avisynth
  2. PC default YUV codec converts to RGB for VDub
  3. PIC MJpeg Encodes RGB or YUV
  4. PIC MJpeg Decodes and may convert RGB->YUV or YUV->RGB
  5. Convert2YUV may be used to measure with ColorYUV()
  6. TV to PC or PC to TV

I show the paths below. A (+) indicates that the range 16-235 was changed to 0-255, and a (-) indicates that the range 0-255 was changed to 16-235. The different results are because PIC does not map.

Code:
1. (a)YUV -> (b)n/a -> (c)YUV -> (d)YUV -> (e)n/a -> (f)n/a   Y:39
2. (a)YUV -> (b)RGB+ -> (c)RGB -> (d)RGB -> (e)YUV- -> (f)n/a Y:39
3. (a)YUV -> (b)n/a -> (c)YUV -> (d)RGB -> (e)YUV- -> (f)n/a  Y:50
4. (a)YUV -> (b)RGB+ -> (c)RGB -> (d)YUV -> (e)n/a -> (f)n/a  Y:27
5. (a)YUV -> (b)n/a -> (c)YUV -> (d)RGB -> (e)YUV- -> (f)YUV+ Y:40
6. (a)YUV -> (b)RGB+ -> (c)RGB -> (d)YUV -> (e)n/a -> (f)YUV- Y:39
As you can see, if you do an xtra down size you get Y:50. If you do an xtra upsize, you get Y:27. Also, all the converting can cause a small shift.

What I thought was most interesting was the shift of the U:221. This is due to the PIC conversion from YUV to RGB. This conversion requires 4:4:4, and YUV here has 4:2:2. When pic upconverts, they may do more than just double the values, and this causes a shift.

-----------------------
John,

I'd say CCE expects RGB data. If you choose the 0-255 option, CCE will not remap it to 16-235. If you pic 16-235, it will. This means the following would be a working process from capture to encode.

1. Cap PIC YUV 16-235 (Correct for video/Bad for PC viewing)
2. CCE requests RGB from PIC. PIC gives RGB without mapping (Still correct for Video)
3. CCE option 0-255. CCE takes RGB, changes to YUV and does not map (Still correct for video)

So, Cap PIC YUV feed to CCE 0-255 should be golden. No RGB/YUV conversions in the middle.

Trev

trevlac is offline   Reply With Quote
Old 26th January 2004, 19:49   #12  |  Link
trevlac
budala
 
Join Date: Oct 2003
Location: U.S.
Posts: 545
Re: Need help understanding

Quote:
Originally posted by FulciLives
BTW this was with a USA NTSC capture and my capture card was set to NTSC_M
BTW:

Although it seems people think there is a difference between PAL,NTSC, and NTSC_J; for digital YCbCr, there is none.

For each, 16=Black and 235=White. When you capture, the card converts from YUV or YIQ to YCbCr taking into account if black starts at 7.5IRE or 0IRE. When you get YCbCr there is no difference.

In addtion, it is my understanding that something like a dvd player converts from the 601 standard back to your TV standard for you. The digital data does not differentiate. I have read that some dvd players (like the sony playstation) do not set the black level to 7.5IRE.
trevlac is offline   Reply With Quote
Old 27th January 2004, 21:49   #13  |  Link
FulciLives
Registered User
 
Join Date: Apr 2002
Posts: 106
Quote:
Originally posted by trevlac
-----------------------
John,

I'd say CCE expects RGB data. If you choose the 0-255 option, CCE will not remap it to 16-235. If you pic 16-235, it will. This means the following would be a working process from capture to encode.

1. Cap PIC YUV 16-235 (Correct for video/Bad for PC viewing)
2. CCE requests RGB from PIC. PIC gives RGB without mapping (Still correct for Video)
3. CCE option 0-255. CCE takes RGB, changes to YUV and does not map (Still correct for video)

So, Cap PIC YUV feed to CCE 0-255 should be golden. No RGB/YUV conversions in the middle.

Trev

Well according to ADAM (a mod at dvdrhelp.com) CCE uses YUV and not RGB

Also ... according to Adam ... you pick 0-255 in CCE if your capture is YUV 16-235 otherwise you pick 16-235 in CCE

How true this all is? I don't know!

But assuming Adam is correct and CCE works in YUV and PICVideo MJPEG works in YUV then I guess you don't have to worry about it ... except this thread is about how some MJPEG codecs (I am unclear if this includes PICVideo MJPEG) need the AviSynth line:

ColorYUV(levels="PC->TV")

To correctly "decode" to the encoder.

So I'm still confused hehehe

- John "FulciLives" Coleman
FulciLives is offline   Reply With Quote
Old 27th January 2004, 22:27   #14  |  Link
trevlac
budala
 
Join Date: Oct 2003
Location: U.S.
Posts: 545
Well,

According to this doc:

http://www.cinemacraft.com/files/doc/ccl_264e.pdf

CCE 1st looks for YUY2. If it finds it, then there is no mapping to do so 0-255 nor 16-235 should not have any effect. If it finds RGB then the 0-255 option means do no mapping. If you pick 16-235 then it says map to 16-235. Seems backwards, but that's what that doc says.

So in your case, if you have PicVideo send YUY2 to CCE, there should be no problem. If you have PicVideo convert the YUY2 to RGB32 then you should pic 0-255. This is because pic does not expand the YUV 16-235 to 0-255 when it converts, so CCE should not contract the range back when it converts to YCbCr 4:1:1.

If you post the link to what adam said, I'll comment on it.


PS: I have very little doubt about how the general process works. As far as what a given piece of software does, hard to say.
trevlac is offline   Reply With Quote
Old 28th January 2004, 03:16   #15  |  Link
FulciLives
Registered User
 
Join Date: Apr 2002
Posts: 106
My latest AviSynth script

Well since Trevlac got me using the BTwincap driver I am now capturing at 368x480 using PICVideo MJPEG at the 19 quality setting.

So here is the latest AviSynth script I've been using:

LoadPlugin("C:\PROGRA~1\GORDIA~1\mpeg2dec3.dll")
LoadPlugin("convolution3d.dll")
SegmentedAviSource("D:\capture\capture.avi")
Trim(801,157603)
SeparateFields()
crop(0,2,0,-6)
AddBorders(2,4,2,4)
even = SelectEven(last).Convolution3D (0, 6, 10, 6, 8, 2.8, 0)
odd = SelectOdd(last).Convolution3D (0, 6, 10, 6, 8, 2.8, 0)
Interleave(even, odd)
LanczosResize(352, 240)
weave()
ColorYUV(levels="PC->TV")


Since my crop command is after SeparateFields() I am actually cutting 12 from the bottom and 4 from the top. I'm thinking maybe I should just change the crop to:

crop(0,4,0-12)

And put it and the AddBorders command BEFORE the SeparateFields() command. This would change AddBorders to: AddBorders(2,8,2,8)

But really the thing I am most worried about is if I need that ColorYUV line or not.

Again I'm using CCE not TMPGEnc which is ASS slow on my computer (hence my switch to CCE as it is MUCH faster).

- John "FulciLives" Coleman

P.S.
My AddBorders command (after my crop command) brings my capture from 368x480 to 372x480 which sounds odd I know but if you capture at 712x480 and padd to 720x480 then resize to 352x480 you get about 2 pixels of black on the side so I am just trying to "mimic" that with my 368x480 capture. I know we have that other thread going on dvdrhelp.com about this but this is how I've decided to handle it ... even though I know you (i.e., trevlac) are saying to do it differently

Last edited by FulciLives; 28th January 2004 at 03:23.
FulciLives is offline   Reply With Quote
Old 28th January 2004, 05:46   #16  |  Link
trevlac
budala
 
Join Date: Oct 2003
Location: U.S.
Posts: 545
John,

Do what makes sense (and works) for you.

On the color space thing. If you cap in YUY2, I don't see any need for PC->TV.

Trev
trevlac is offline   Reply With Quote
Old 28th January 2004, 07:43   #17  |  Link
stickboy
AviSynth Enthusiast
 
Join Date: Jul 2002
Location: California, U.S.
Posts: 1,268
Quote:
Originally posted by trevlac
On the color space thing. If you cap in YUY2, I don't see any need for PC->TV.
Isn't that exactly what kevina is talking about?
stickboy is offline   Reply With Quote
Old 28th January 2004, 21:48   #18  |  Link
trevlac
budala
 
Join Date: Oct 2003
Location: U.S.
Posts: 545
Quote:
Originally posted by stickboy
Isn't that exactly what kevina is talking about?
I'm not clear what you mean. PC-TV and TV-PC are never a good thing.

The point I was trying to make was that the results of kevina's tests really were no mystery. The MJPeg codec does not change the nominal range when it does a color space conversion. Avisynth does.

Personally, I think no change is better than making the change.

The reason is that (contrary to popular belief) if you do not change the range, you do not loose any luma info due to rounding, when converting from YUY2 to RGB. This is not true for chroma, but I think ~ 200 of over a possible 1 million colors are effected.

The general calculation for the conversion (assuming black and white) is:

R = Y
G = Y
B = Y

now go back

Y = .299R + .587G + .114B


Plug any number between 0-255 into Y and there will be no rounding loss in the result when you hit RGB. If you then convert back, you will get the same Y. Not so if you convert and map to a different nominal range. Because to go from a range of 219 steps to a range of 255 steps requires multiplication by 255/219 (better known as 1.164).

The full equations for color are here: http://www.poynton.com/notes/colour_....html#RTFToC31

They are directly derived from Spec 601, which states the numbers I gave above.



---------
What was kevina's point? Don't use RGB because it's confusing ? What do you think?

Cheers,

Trev
trevlac is offline   Reply With Quote
Old 29th January 2004, 02:48   #19  |  Link
stickboy
AviSynth Enthusiast
 
Join Date: Jul 2002
Location: California, U.S.
Posts: 1,268
kevina wasn't using RGB at all except as a workaround. The problem he's reporting is that even though the MJPEG data is stored in YUV, even when YUY2 frames are requested through PicVideo's MJPEG decoder, colors at the end get crushed together.
stickboy is offline   Reply With Quote
Old 29th January 2004, 03:39   #20  |  Link
FulciLives
Registered User
 
Join Date: Apr 2002
Posts: 106
Quote:
Originally posted by stickboy
kevina wasn't using RGB at all except as a workaround. The problem he's reporting is that even though the MJPEG data is stored in YUV, even when YUY2 frames are requested through PicVideo's MJPEG decoder, colors at the end get crushed together.
Here is what I've learned so far from this thread:

1.) Some MJPEG codecs may "crush" the luma range. With MJPEG codecs that do this the workaround is the AviSynth line:

ColorYUV(levels="PC->TV")

2.) PICVideo MJPEG does not "crush" the luma when you encode YUV and decode in YUV

I wasn't so sure about point 2 but after reading waka's post this now seems more clear to me. I'm still not 100% though if PICVideo MJPEG does this "crush" or not but now it seems like it doesn't.

Damn I'm still confused!

- John "FulciLives" Coleman
FulciLives is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 16:14.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.