Colour Correction

[pwnsweet]

Hi,

Hopefully this thread gets seen here in the DVD2AVI / DGIndex section. I would've liked to put it somewhere more visible, but it really does belong here.

I've recently been encoding .m2ts Blu-ray movies with MeGUI and recently had the need to index a few of the ones that have MPEG-2 video streams to maintain audio/video synchronization in the encoded video. So I used MeGUI's File Indexer and selected my source .m2ts and was given two options, DGIndex and FFMSIndex. DGIndex was the default, and when I changed to FFMSIndex I was given a warning message, so I stuck with DGIndex.

Once the indexing was complete, the AVS script creator opened up and I noticed there was an option to use Color Correction. I compared the avs preview against the source with and without color correction and neither setting produces the same color (although with color correction on it looks closer to the source). How do I get my encoded video to look exactly the same as the source, color-wise?

[kypec]

and some samples (few seconds of source MPEG2 should be enough) if possible.
Do you use old DGDecode or newer DGDecNV tools?

[pwnsweet]

Originally Posted by pwnsweet

...I compared the avs preview against the source with and without color correction and neither setting produces the same color (although with color correction on it looks closer to the source).

It seems I've solved this issue. The preview wasn't producing the same colors as the source with color correction on or off, but the actual encoded video had the same colors as the source when color correction was turned off.

To answer your question kypec, my script (with color correction off) is:

# Set DAR in encoder to 65 : 27. The following line is for automatic signalling
global MeGUI_darx = 65
global MeGUI_dary = 27
LoadPlugin("D:\Roberts stuff\megui\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\Temp\MI3\00003.d2v")
#deinterlace
crop( 0, 130, 0, -132)

Spline36Resize(1504,640) # Spline36 (Neutral)
#denoise

[yetanotherid]

The preview should look the same as the final encode (depending on whether color correction is needed and/or used). I recently spent way to much time working on color issues myself and this is basically what I worked out....

There's two main color standards used, Rec.601 and Rec.709. Generally Rec.601 is used for SD video and Rec.709 for HD video.
Windows doesn't use color information when displaying video. It makes it's color choice based on resolution, so the colors used for previewing the video may depend on the size of the preview window, your resizing choices when previewing and whether you'd cropped the video before previewing (which reduces the resolution).

I've not been able to work out the exact cut-off point where Windows changes the colors it uses for playback. SD is always Rec.601 and Full HD is always Rec.709. The grey area is when it comes to cropped HD video (1280x? etc). For video with a standard width of 1280 the cut-off point seems to be around 674 vertical lines, so for HD video which requires the cropping of black bars, some will display using the wrong colors when played on a PC. 1280x720 or 1280x688 for example will display using the correct colors (Rec.709). 1280x544 or 1280x528 will display using the wrong colors (this can easily be corrected on playback with MPC-HC using it's color conversion shader).
There's always a chance too that your original video doesn't follow the rules. If it's HD it's more than likely to be Rec.709, but it could be Rec.601 which means it'll display using the wrong colors on a PC......

My "vague" area is when it comes to video with non-standard widths. i.e. over 1280 but under 1920. Windows seems to pick color based on the total resolution but I've not been able to work out exactly what that is. For instance I have a video of around 1420x612 which I'm pretty sure displays using Rec.709.

MeGUI's automatic color correction works on color information in the mpeg2 video stream... if it's present. The colormatrix.dll is traditionally used when converting DVDs (which apparently can be Rec.709) and I assume it also works when going from HD to SD. I'm not sure whether it works correctly when encoding at HD resolutions though, or whether it assumes you're encoding to SD. I'll have to set up a test encode to see if MeGUI changes the color correction part of the script according to the chosen resizing. If it doesn't then it'd be better to disable color correction when encoding at HD resolutions. Does anyone know how MeGUI handles color correction for HD encodes? I don't have a HD mpeg2 file handy to test it with.

When converting, the general rule seems to be Rec.601 is used for SD and Rec.709 for HD. I consider anything over DVD dimensions (1024x576 etc) to be HD. For mpeg2 video, which may not always follow the rules, the color correction MeGUI uses obtains the color information from DGIndex. The rule I now go by is when encoding from Full HD to Full HD or to HD I never color convert (even if many of the 1280x? encodes display on a PC using the wrong colors) and when encoding from FullHD/HD to SD I always manually color convert.

If you Google "colormatrix.dll" you'll find info on how to use it manually. When converting from HD to SD I simply add the following to the MeGUI script (for interlaced content the parameters are different):

LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(mode="Rec.709->Rec.601")

When encoding from HD to HD as you apparently did, you should never need to color convert (correct). It should all be Rec.709.

[pwnsweet]

Hi yetanotherid,

It seems you've posted in my thread and I've posted in yours.

Originally Posted by yetanotherid

I don't have a HD mpeg2 file handy to test it with.

I have a Blu-ray .m2ts with MPEG-2 video stream. What exactly would you like me to test for you? Please outline what you want me to do step-by-step.

LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(mode="Rec.709->Rec.601")

When I used ColorMatrix to perform my color correction tests I indexed the file with DGIndex and then ticked the color correction option from within MeGUI. The effect this had on my script was different to what you've shown above. In my script I had:

DGDecode_mpeg2source("D:\Temp\mi2\00003.d2v", info=3)
LoadPlugin("C:\MeGUI\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)

In other words, I directed ColorMatrix to convert color based on the hints in the .d2v file DGIndex made during indexing whereas your method is forcing the conversion regardless of the DGIndex hints. When I toggled color correction on and off and re-previewed each time, the color clearly changed, my question is, would the color change differently if I used the forced method instead of using hints or are they essentially doing the same thing?

When encoding from HD to HD as you apparently did, you should never need to color convert (correct). It should all be Rec.709.

Indeed. The problem is, your testing shows that Windows defines 'HD' as 674 vertical lines and above, whereas my testing shows Windows defining HD as 578 and above...

[Ghitulescu]

The AES/EBU definition of HD is anything above 576 visible scanlines. Has nothing to do with M$ windows.

[pwnsweet]

Originally Posted by Ghitulescu

The AES/EBU definition of HD is anything above 576 visible scanlines. Has nothing to do with M$ windows.

Well, that definitely falls in line with my testing of the way DirectShow chooses what colors to use...almost. I say almost because I've found that DirectShow uses Rec.601 for all vertical resolutions up to and including 577.

If Windows presumably follows the AES/EBU spec, then why doesn't video with 577 vertical lines display using Rec.709?Instead it's displayed in Rec.601 for some reason.

[yetanotherid]

Originally Posted by Ghitulescu

The AES/EBU definition of HD is anything above 576 visible scanlines. Has nothing to do with M$ windows.

Well of course it has something to do with MS Windows if you're using a PC to convert and/or play video. Windows decides which colors to use for playback. How is it nothing to do with Windows when you need to ensure you can accurately predict which colors are being used to display the encoded video (and the original) and therefore know whether color conversion is required or not? Should I ask my BluRay player to look at the preview window before I encode and let me know which choice to make?

Rather than post information which has no reliable bearing on the real world (as is obviously the case with a PC) how about answering the question asked of you in my color conversion thread? Does your beloved standalone player follow the AES/EBU definition of HD and always choose Rec.709 for playback? Does it pay any attention to the colormatrix info in the video stream?
I assume your lack of response so far means you don't really know the answers to those questions. When you do, then I guess you could post info on the AES/EBU definition of HD and at least be able to show if it's relevant.

[yetanotherid]

pwnsweet,
I just finished reading your post in my old thread. I'll respond to your last post here shortly and also respond here to your post in my thread. Might as well continue the discussion in a single thread. Hopefully we won't be interrupted with any more irrelevancies.

[yetanotherid]

Originally Posted by pwnsweet

I have a Blu-ray .m2ts with MPEG-2 video stream. What exactly would you like me to test for you?

The effect this had on my script was different to what you've shown above. In my script I had:
DGDecode_mpeg2source("D:\Temp\mi2\00003.d2v", info=3)
LoadPlugin("C:\MeGUI\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)

That's the bit I'm interested in.
The way I understand it "hints=true" tells colormatrix.dll to obtain the color info from the DGIndex file. Apparently the colors used can change within a single mpeg2 file, so the hints parameter tells the colormatrix dll to convert the colors appropriately (rather than to just color convert or not). In reality though, I think mpeg2 video always uses the same color throughout. Without "hints=true" I think the color info is still obtained from the DGIndex file, but it's an "all or nothing" decision to convert the colors. At least that how I understand it to work.

The whole color conversion thing came about as a result of converting DVDs, some of which can be Rec.709 (although I don't think I've ever seen one) and the purpose is to ensure all SD encodes are converted to Rec.601 if necessary. If it's not Rec.709, there should be no color conversion.

In your case however, you're encoding to HD so you don't want to convert the colors (assuming they're already Rec.709). I'm trying to understand if the color conversion added to the MeGUI script changes according to the resizing when encoding (definition). I don't think it would, therefore using the color correction option would probably cause conversion to Rec.601 regardless of the resizing, which for HD encodes would be wrong.
I don't think there's any way for the colormatrix.dll to automatically convert to Rec.709 so at best MeGUI would probably have to be clever enough to delete the color conversion stuff from the script when encoding to HD, even though you have the color correction option selected. If it doesn't then you'd probably have to disable the color correction manually.
I'm basically wondering if MeGUI changes the color correction part of the script (as you posted above) if you change the resize dimensions to SD, or if it remains the same. If it remains the same then I'd guess the color correction option will give you the wrong colors when encoding to HD.

Originally Posted by pwnsweet

In other words, I directed ColorMatrix to convert color based on the hints in the .d2v file DGIndex made during indexing whereas your method is forcing the conversion regardless of the DGIndex hints. When I toggled color correction on and off and re-previewed each time, the color clearly changed, my question is, would the color change differently if I used the forced method instead of using hints or are they essentially doing the same thing?

The two methods will achieve the same thing. Your method relies on color information in the mpeg2 stream, and converts the colors, probably regardless of the destination resolution.
For SD encodes (DVD encodes etc) I'd use your method (I think DGIndex assumes Rec.601 if no color information is present) but for HD sources it's more likely to be Rec.709. Plus I've not yet been able to determine if there's equivalent color information which DGIndex can use in non-mpeg2 HD video (x264, VC1 etc). I'm thinking there isn't and if memory serves me correctly MeGUI doesn't give you a color correction option for anything other than mpeg2 video. So for other types of BluRay video you either have to manually check the video stream (can be done with MediaInfo) or manually assume Rec.709 and manually color convert if need be.
That's why for all HD to HD encodes I use no color conversion and for HD to SD encodes I add it manually (and manually you can convert in either direction if need be).

Originally Posted by pwnsweet

Indeed. The problem is, your testing shows that Windows defines 'HD' as 674 vertical lines and above, whereas my testing shows Windows defining HD as 578 and above...

That's interesting.... and very &^*ing disappointing. I was sure I had it pretty much worked out. Maybe it's the way we tested which has an effect? You tested by using an AVISynth script to resize and compare the video, I tested by running the video maximised and using ffdshow to resize the video on the fly. Mind you I wonder how many encodes I'd have which fall between 578 and 674 vertical lines? Probably very few if any.
I will have to do some more testing, maybe to see if we can reach an agreement. Unfortunately though it'll probably be a few days before time allows, but I will get back to it.

I'll respond to your post in the other thread here shortly.....

[Ghitulescu]

Originally Posted by yetanotherid

Well of course it has something to do with MS Windows if you're using a PC to convert and/or play video. Windows decides which colors to use for playback. How is it nothing to do with Windows when you need to ensure you can accurately predict which colors are being used to display the encoded video (and the original) and therefore know whether color conversion is required or not? Should I ask my BluRay player to look at the preview window before I encode and let me know which choice to make?

Rather than post information which has no reliable bearing on the real world (as is obviously the case with a PC) how about answering the question asked of you in my color conversion thread? Does your beloved standalone player follow the AES/EBU definition of HD and always choose Rec.709 for playback? Does it pay any attention to the colormatrix info in the video stream?
I assume your lack of response so far means you don't really know the answers to those questions. When you do, then I guess you could post info on the AES/EBU definition of HD and at least be able to show if it's relevant.

There are HD videos using .601 colorimetry, just for your information. As I said in another thread, it is customary to assume that HD videos should have .709 colours while SD videos should have .601. Or for that matter, codecs that are usually used for SD would employ .601 while those usually used or designed for HD would use .709.
And again, windows has nothing to do with colorimetry, otherwise no editing in high end suites (like edius) would be possible. I agree, there must be codecs from MS, or players using the internal routing of MS, but that's it.

PS: there are also PC running linuxes

[yetanotherid]

From the "other" thread: http://forum.doom9.org/showthread.php?t=160984

Originally Posted by pwnsweet

My encode goal is to encode Blu-ray to ~720p using MeGUI and then store and watch the resultant mp4 on my Playstation 3. When I say ~720p, I mean roughly 921,600 pixels after border cropping which means my resulting encode is not always 720 vertical lines. In fact, I'm typically encoding at resolutions of 1504x640, 1536x640, 1280x720 or 1328x720 depending on the source's aspect ratio after copping. I started noticing color issues when I was previewing my avs script in MeGUI. Greens and reds were different in the preview window to the source, and I just couldn't get the same colors as the source regardless of whether the color correction option in MeGUI was enabled or not.

I'm starting to seriously wonder if cropping the black borders when encoding 720p video is a good idea. Even if it makes the files larger, at least every 720p encode would be 720p and should always display using Rec.709.
I'm still not sure why your preview didn't match the source whether you color converted or not.

Originally Posted by pwnsweet

If I understand your results correctly, you claim that anything below 676 vertical lines is displayed in Windows in Rec.601. If this was correct, then my source should've exhibited Rec.709 colors and my two resized scripts should've exhibited Rec.601 colors...but they didn't. Only the 1120x480 had Rec.601, the other two had Rec.709. Next I kept decreasing the vertical resolution of my 1504x640 script until it too exhibited Rec.601 colors and found that to occur when the vertical resolution was 577. At 577 vertical lines the colors switched from Rec.709 to Rec.601 and looked the same as that of the 1120x480 resize. Just for fun, I then increased the horizontal resolution to 1920 (so 1920x577) and opened that up in Daum PotPlayer. Besides the fact that the aspect ratio was completely out (which I corrected within PotPlayer) the colors were still Rec.601. So clearly horizontal resolution makes no difference to Windows' choice.

My initial testing had me thinking the color choice was made according to vertical resolution. Then I found a video which I'm sure displayed using Rec.709 despite only having around 600 vertical lines. It wasn't however a standard width of 1280, it was around 1420 wide. This led me to a theory that Windows chooses colors based on the total resolution (width x height) but like you I haven't been able to reproduce the change accurately. Maybe there's some Microsoft if/then formula for choosing the color method we don't yet understand?
Could you do me a favour? You said you found 577 vertical lines was your cutoff point, but thinking about it you tested while using a video with a width of 1504. I'm pretty sure my testing used a video with a width of 1280. Could you try your method again using a 1280 width to see if your results then change?

Originally Posted by pwnsweet

So this got me thinking. If I need to encode to a vertical res of less than or equal to 577, would color correction fix the colors? So I tested that next. Sure enough, after color correction had been performed with ColorMatrix the colors were the same as the source. Then I remembered about my end game - the Playstation 3. I wasn't going to be watching this stuff on my PC after all, so I wondered how the Playstation 3 decides what colors to use. I believe this might also partially answer your question regarding how standalone players handle which colors are used. So I encoded a short clip at 1120x480 and 1504x640 (both without color correction) and transferred them, along with the source over to my PS3. I had my suspicions that they would all exhibit the same colors and they did.

I'd have guessed (and hoped) a standalone device would display both encodes using the same colors. It'd really just mean that for some of those cropped 720p encodes, it's Windows which gets it wrong. So if you don't ever color convert a cropped 720p encode it should always play correctly on a standalone device (let's hope). As long as we know when Windows gets it wrong (and I'm assuming pretty much every common HD resolution under 688 will be wrong) it's really easy to manually correct the colors on playback (at least when using MPC-HC).
One other thought... I'm using XP. I'm wondering if different flavours of Windows might use slightly different rules for color choice? Which flavour of Windows are you testing with?

Here's a fun one......
While I was experimenting with all this I tried using ffdshow to convert to RGB for playback, as when converting it pretty much uses Rec.709 for anything over DVD resolution, so it should be using the correct colors pretty much all the time. I thought that was the solution but.....
Lets call Rec.601 as looking "duller" and Rec.709 as looking "brighter" (just for want of a description). Using MPC-HC's Rec.601 to Rec.709 shader always makes the colors "brighter" as it should. When using ffdshow to do the RGB conversion Rec.601 looks "duller" than Rec.709 as it should.
However I gave up when I discovered that without RGB conversion MPC-HC displayed Rec.709 video using the same colors as it does when ffdshow is converting to RGB first and using Rec.601....

Or maybe by that stage I'd started to go mad, but I'm sure that's what was happening.....

[yetanotherid]

Originally Posted by Ghitulescu

There are HD videos using .601 colorimetry, just for your information. As I said in another thread, it is customary to assume that HD videos should have .709 colours while SD videos should have .601. Or for that matter, codecs that are usually used for SD would employ .601 while those usually used or designed for HD would use .709.

I'll give you one thing, you're not shy about repeating the obvious. For your information, I mentioned the fact HD video can use Rec.601 in my first post.
When you say codecs used for SD would employ Rec.601 etc, what are you referring to? If you're referring to encoding then it's only relevant when converting from RGB so it has nothing to to do with this topic, and I think x264 encodes RGB using Rec.601 the same as XviD anyway.
If you're referring to decoding then I think it's simply a load of rubbish. Unless you have an example of a playback device which chooses a color method based on the type of video codec... How would that work? Does a BluRay player decode a 1080p mpeg2 stream using Rec.601 because mpeg2 is also used in SD DVD video?

Originally Posted by Ghitulescu

And again, windows has nothing to do with colorimetry, otherwise no editing in high end suites (like edius) would be possible. I agree, there must be codecs from MS, or players using the internal routing of MS, but that's it.

You're not shy about repeating yourself either, even when it's still not relevant to the discussion.
Of course Windows has nothing to do with the colorimetry of the video itself, what makes you think anyone says it does? It does however have everything to do with the colors used when playing video using a PC, and we're trying to understand exactly when Windows decides to use one color method or another, when it's correct and when it isn't. What's so hard about that to understand?

Originally Posted by Ghitulescu

PS: there are also PC running linuxes

And I bet you don't know how Linux decides which colors to use when playing back video either.

[pwnsweet]

Just a quick reply here before I go to bed. I'm using Windows 7 Ultimate x64 in my testing.

[Ghitulescu]

Originally Posted by yetanotherid

I'll give you one thing, you're not shy about repeating the obvious.

you got this "obvious" from 2 members, me included. Now it's obvious. If it were so obvious in the first place, why didn't this occured to you when you asked about it in the other thread?

Originally Posted by yetanotherid

Of course Windows has nothing to do with the colorimetry of the video itself, what makes you think anyone says it does? It does however have everything to do with the colors used when playing video using a PC, and we're trying to understand exactly when Windows decides to use one color method or another, when it's correct and when it isn't.

M$ windows uses internally several color spaces for unprocessed data, but only one for processed data. If needed it transforms that data in sRGB according to IEC 69166-2-1.
I assume now this is again obvious, once you learned it.
If no display is involved, windows uses the colorimetry the stream indicates (it includes DVXA, directshow and even MFC) and passes it by unchanged. If displaying the data is involved, then one applies the desired colorimetry, according to the video data flags, converts it to sRGB and displays it accordingly. The user can change some parameters using a certain control panel extension (CPL) whose name escapes me right now, something with extended colours.
Again obvious, I assume.

PS: Repetitio mater studiorum est.

[yetanotherid]

Originally Posted by Ghitulescu

you got this "obvious" from 2 members, me included. Now it's obvious. If it were so obvious in the first place, why didn't this occured to you when you asked about it in the other thread?

I asked specifically about the colorimetry of BluRay HD video in the previous thread, and you replied with your usual generalisations which were not only irrelevant to my encoding (I'm not converting from RGB) but didn't answer the question.
Here you've offered more silly generalisations about codecs and color spaces.
I mentioned HD streams possibly using Rec.601 in my first post, yet you felt the need to enlighten me as to what I already knew. I guess you missed the obvious while busily stating it.

Originally Posted by Ghitulescu

M$ windows uses internally several color spaces for unprocessed data..... blah, blah, blah

Wow, that's a big help when it comes to working out Windows color choices according to video definition, but at least you finally seem to be grasping which topic is actually being discussed, even if you're still only able to offer the obvious.
Maybe later, when the name of these mysterious Windows control panel extensions no longer elude you, you could post back and explain how to use them to alter the color choices Windows makes when playing video... or are they just something else you're making up as you go?

[Guest]

Let's not get personal, guys. Thank you.

[Ghitulescu]

It's not personal, but I'm getting again pissed off that learns from me then says it's obvious.
As long as no directshow or other windows internal paths are used, the colour space travels unchanged. It is then decoded by the codec according to the flag/s and displayed (overlay). If windows gets involved, then everything is decoded to sRGB colour space, rendered and displayed as usual. You guys know better.
That's this simple (providing the colour space information each video has with is accurate). Going through various codecs and/or containers using various applications may involuntarily change the correct info with an assumed one.
For people that do pure editing (not "backing up their collections") windows does not play any role, everything being taking care of by the editor (edius, premiere etc.). For directshow applications, read the above items. This is the same for audio - pure editing does not pass through kmixer, acquisition and reproduction of sounds may use kmixer but serious applications bypass it (ASIO and similar).

[yetanotherid]

Originally Posted by Ghitulescu

It's not personal, but I'm getting again pissed off that learns from me then says it's obvious.

What have I learned from you? So far the only direct questions I've asked of you have been completely ignored because you have no idea as to the answer, although I've learned you're great at posting just for the sake of it. Once again, the only info you've posted on the colorimetry used when encoding relates to converting from RGB (even if you were blissfully unaware of it) and isn't even relevant to this discussion.

Originally Posted by Ghitulescu

As long as no directshow or other windows internal paths are used, the colour space travels unchanged. It is then decoded by the codec according to the flag/s and displayed (overlay). If windows gets involved, then everything is decoded to sRGB colour space, rendered and displayed as usual. You guys know better.

Rendered and displayed as usual?? What does that mean? Of course it's rendered and displayed as usual. We're trying to work out exactly what "as usual" is so we know our color conversion choices are correct, despite the colors used when previewing the video on a PC. That's the topic.

Originally Posted by Ghitulescu

That's this simple (providing the colour space information each video has with is accurate). Going through various codecs and/or containers using various applications may involuntarily change the correct info with an assumed one.

Windows may involuntarily change the correct color info with an assumed one because it completely ignores the correct color info and displays video using a colorimetry according to the video resolution.... regardless of the codec or container involved. As far as I'm aware it's that simple, and your theory sounds like it comes from the same place as those mysterious Windows control panel extensions which must still be eluding you. Do you have anything to suggest even a standalone player might ignore the colorimetry info because the video is in one type of container but doesn't when it's in another, or that it might ignore the colorimetry in one type of video stream and not another, or is it all just wild speculation?

Originally Posted by Ghitulescu

For people that do pure editing (not "backing up their collections") windows does not play any role, everything being taking care of by the editor (edius, premiere etc.). For directshow applications, read the above items. This is the same for audio - pure editing does not pass through kmixer, acquisition and reproduction of sounds may use kmixer but serious applications bypass it (ASIO and similar).

Nobody has mentioned video editing here (aside from you again) because we're only referring to the colorimetry used by a PC when displaying video and it's effect on color conversion choices when encoding. The effects on colorimetry, or lack thereof, when simply editing video would have to be obvious even to Amazonian tribes who are as yet untouched by western civilisation.

[GodofaGap]

Originally Posted by yetanotherid

Windows may...

What do you mean with "Windows"? The Windows OS doesn't really make any assumptions about digital video. The barebones Windows OS can't even really display video. If with Windows you mean DirectShow then it really depends on what filters you are using. If you are using some standalone application to render video on the screen then it depends on that application.

If you are trying to find some general rule here for everyone with for example Windows 7 64 bit, you are not going to find it. If you are trying to find some general rule for everyone who uses ffdshow or VLC for decoding then you might be getting closer.

But from your posting it is not exactly clear if you have a good grasp on the issue to start with.