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. |
17th June 2003, 18:40 | #1 | Link |
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() 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. |
17th June 2003, 20:40 | #2 | Link |
Retired AviSynth Dev ;)
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. |
17th June 2003, 21:19 | #3 | Link | |
Registered User
Join Date: Jun 2003
Posts: 71
|
Quote:
Anyway a mention of this in the AVISynth manual would be very helpful. |
|
17th June 2003, 21:21 | #4 | Link |
Retired AviSynth Dev ;)
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 |
17th June 2003, 22:35 | #5 | Link |
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. |
18th June 2003, 04:27 | #6 | Link |
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. |
18th June 2003, 17:39 | #7 | Link |
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 |
18th June 2003, 20:39 | #8 | Link |
Retired AviSynth Dev ;)
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 |
25th January 2004, 09:54 | #10 | Link |
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 |
26th January 2004, 19:42 | #11 | Link | |
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:
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 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 |
|
26th January 2004, 19:49 | #12 | Link | |
budala
Join Date: Oct 2003
Location: U.S.
Posts: 545
|
Re: Need help understanding
Quote:
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. |
|
27th January 2004, 21:49 | #13 | Link | |
Registered User
Join Date: Apr 2002
Posts: 106
|
Quote:
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 |
|
27th January 2004, 22:27 | #14 | Link |
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. |
28th January 2004, 03:16 | #15 | Link |
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. |
28th January 2004, 21:48 | #18 | Link | |
budala
Join Date: Oct 2003
Location: U.S.
Posts: 545
|
Quote:
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 |
|
29th January 2004, 02:48 | #19 | Link |
AviSynth Enthusiast
Join Date: Jul 2002
Location: California, U.S.
Posts: 1,267
|
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.
|
29th January 2004, 03:39 | #20 | Link | |
Registered User
Join Date: Apr 2002
Posts: 106
|
Quote:
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 |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|