More contrast just by loading the file?

[kadajawi]

Ok, so I've noticed that when I use this script:

DirectShowSource("14-02-11 19-26-50 IMGP9403.AVI", fps=25, ConvertFPS=True, audio=False)
ConvertToRGB32

(I have to convert to RGB32, cause otherwise it complains that "the script's return value was not a video clip", but the problem also happens with YUV2 or YV12)

I get a vastly different picture from loading the file itself (see attachment), i.e. dropping the AVS script into MPC as well as the original file. I'm using the LAV Video Decoder for both the version that ran through AVS as well for decoding the original file, so that shouldn't make a difference... So far I've only noticed this on my MJPEG files...

Does anyone have an idea what's wrong? It looks like more contrast, blowing out the highlights etc.

I just tried to directly encode the video to h264 with the Hi10p profile, instead of going through AviSynth, and it looks identical to the original.

[feisty2]

your video is pcrange but treated as tvrange, so do a "yc compression" should fix this
mt_lut(expr = "x 224 * 255 / 16 +",yexpr = "x 219 * 255 / 16 +",chroma = "process")

[osgZach]

Do you have color management turned on in MPC?

That's about the only thing I know of that would make a clip look different just by loading a file.

[feisty2]

Do you have color management turned on in MPC?

That's about the only thing I know of that would make a clip look different just by loading a file.

seems like a range error, I did a yc compression to the latter image and got exactly the same image as the first one

[kadajawi]

Aaaah. Thank you very much! Makes sense, and it worked. :)

[hello_hello]

You know what it seems like to me..... assuming mjpeg normally uses TV levels like most other video and the top pic is how it originally displays.....
Maybe the top image is the incorrect one. The video isn't being expanded to PC levels on playback as it should. When it's converted to RGB via a script, which would normally expand the levels to PC levels, the result is pic2, and the video displaying correctly. Somewhere, the RGB would be converted back to YUV and re-encoded, the levels would probably be converted back to TV levels in the process, which again aren't being expanded to PC levels on playback...... at least that's how it looks to me.

If the original mjpeg video used PC levels and was being expanded correctly on playback then it probably should look too dark in the first place, but RGB conversion in a script would normally expand it too..... regardless of the starting point normally the video should display the same way..... at least when using a monitor which expects video to have PC levels.

kadajawi hasn't really said whether after encoding using the script in the OP the encoded version looks the same as the original or whether he's just assuming it won't.

The need to convert to RGB seems a little odd. I wonder if that could be a mod2 problem?

[hello_hello]

Aaaah. Thank you very much! Makes sense, and it worked. :)

Assuming previewing the script now produces the same result as the original, what about after encoding? Still the same?

[wonkey_monkey]

Have you tried using the pixel_type parameter to force DirectShow to provide you with RGB (or YV12, or YUY2...)?

Edit: Ah, mjpeg - I've seen similar issues with some MJPEG codecs using AviSource. Using pixel_type="YV12" corrected it for me.

[kadajawi]

Ok, so... after encoding it still looks correct with mt_lut.

I would have received a similar result had I converted it to YUV2 for example.

I certainly want as much dynamic range retained as possible.

If I do that mt_lut thing, I will lose the finer steps? i.e. it won't work as good for color grading? (I know using h264 for that is not the best idea, however the MJPEG files are just too big to keep around). I am using Hi10P... if there is anything to preserve as much of the original file as possible that would be great. :)

I have not tried pixel_type...

[raffriff42]

return Interleave(
\ ConvertToRGB32(matrix="Rec709").Subtitle("Rec709", size=56),
\ ConvertToRGB32(matrix="Rec601").Subtitle("Rec601", size=56),
\ ConvertToRGB32(matrix="Rec601").Subtitle("Rec601", size=56),
\ ConvertToRGB32(matrix="PC.709").Subtitle("PC.709", size=56))
view in frame step mode. Choose the one you like best.

[kadajawi]

@raffriff42: Ah, that's great! Thank you! :)

Now... PC.709 and feisty2's script work. PC.709 gives me a significantly warmer output, especially the reds turn to orange. Not sure which one is "correct". And do I understand it correctly, instead of from 0 to 255 I get 16-235 now? So there should be more banding...? Do I lose anything by doing this? I'm sure I understand at most 1% of all of this...

When I use pixel_type="RGB32" in DirectShowSource I get the same result as PC.709, though I still have to run ConverttoRGB32 after import, otherwise there won't be any output.

[osgZach]

PC range is 0 - 255

[foxyshadis]

MJPEG is quasi-standardized as PC range 601, which JPEG uses, but as with all common codecs, it's often bastardized with any ol' RGB<->YUV matrix. Some codecs will mistakenly use 709 for HD, but that doesn't seem to be the case here. Almost every decoder will directly decode MJPEG to RGB with PC levels, but if you feed it to Avisynth first, the downstream has no way of knowing it came from JPEG and needs unusual conversion. (Avisynth lacks that kind of metadata.)

To correctly display it, modify the output chain, not the input. You have to force conversion to RGB via PC.601 at some point: either by using the lut to squeeze it into normal video range, with ConvertToRGB32(matrix="PC.601") in the script, the decoder or renderer options, or via tags after encoding (VUI parameters in h.264 and h.265). The last is the least destructive, but least reliable; if this is for anyone else, scaling to normal is best.

[Yellow_]

If the source is JFIF jpeg encoding chroma difference normalised over full range then I think 'PC' levels based conversion is not right, instead scale levels into limited and then convert to RGB in the player based on limited levels. But at 8bit its destructive.

Using PC levels conversion on JFIF I've always found appears lower contrast and brighter.

Avisynths conversions PC and Rec are based on YCbCr levels assuming non normalised chroma difference in the source aren't they?

No one yet mentioned not to use Directshow, how do we know the source levels aren't already getting messed with that route? Wouldn't FFMS2 or Vampidoms AutoMPEGIndex? Tool be more reliable?

And what was the source? A camera or capture?