Colour Correction [Archive]

yetanotherid

17th May 2011, 14:38

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

18th May 2011, 06:40

Hi yetanotherid,

It seems you've posted in my thread and I've posted in yours. (http://forum.doom9.org/showthread.php?p=1501845#post1501845)

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

18th May 2011, 07:45

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

pwnsweet

18th May 2011, 08:30

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

18th May 2011, 08:32

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

18th May 2011, 08:35

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

18th May 2011, 09:09

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.

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).

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

18th May 2011, 09:30

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

18th May 2011, 09:58

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

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 (http://forum.doom9.org/showthread.php?t=161281). 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.

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?

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

18th May 2011, 10:17

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?

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?

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

18th May 2011, 15:43

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

Ghitulescu

18th May 2011, 16:35

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?
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

19th May 2011, 00:31

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.

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?

neuron2

19th May 2011, 02:07

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

Ghitulescu

19th May 2011, 07:44

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

19th May 2011, 09:12

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.

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.

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?

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

20th May 2011, 07:41

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.

yetanotherid

20th May 2011, 20:47

I'm just trying to use the info here as a starting point, which from my testing seems not to be exactly correct.

http://avisynth.org/mediawiki/Colorimetry#How_can_I_use_the_correct_standard_upon_playback.3F
# Windowed/renderless VMR7 and VMR9 use BT.601 for video < 720p (720 vertical lines)
# Windowed/renderless VMR7 and VMR9 use BT.709 for video >= 720p (720 vertical lines)

I'm using MPC-HC with the WMR9 renderer.
So are you saying the color choice might changing depending on whether I let MPC-HC use it's internal filters rather than if I use ffdshow?
You say it depends on the filters used. Which filters can effect the color choice made by the WMR9 renderer?

One thing I don't know, which may be a reason for pwnsweet's experience when previewing video. How does MeGUI's preview function render the video and would it's color choices be different to MPC-HC and the WMR9 renderer?

GodofaGap

20th May 2011, 20:59

So are you saying the color choice might changing depending on whether I let MPC-HC use it's internal filters rather than if I use ffdshow?
I'm sure you are aware of the "RGB conversion" submenu in ffdshows configuration.

Which filters can effect the color choice made by the WMR9 renderer?
The problem here is that colorspace conversion is something that is not only done by renderer. Any filter that is in the video chain can change the colorspace and therefor make a correct or incorrect conversion.

yetanotherid

21st May 2011, 05:09

I'm sure you are aware of the "RGB conversion" submenu in ffdshows configuration.

I even mentioned it in an earlier post, explained how I thought it'd be the solution to the problem, but discovered it appears Rec.601 with ffdshow converting to RGB looks exactly the same as Rec.709 with the renderer doing the conversion, and I preferred the colors when the renderer was converting. Unless I was going mad by then...
I'm also aware you have to deliberately enable ffdshow's RGB conversion so it doesn't really effect the discussion as to which colors the WMR9 renderer might choose. As I'm aware MPC-HC has a color conversion shader, which I use for those cropped 720p encodes when the WMR9 renderer is using the wrong colors.

The problem here is that colorspace conversion is something that is not only done by renderer. Any filter that is in the video chain can change the colorspace and therefor make a correct or incorrect conversion.

So when I open a video with MPC-HC and use it's internal filters, aside from deliberately enabling the color conversion shader, which filters are the going to be in the chain effecting the colors used for displaying the video? Do you have an example?

One thing I haven't yet done is compare the different renderers properly, but as for the moment I'm using the WMR9 renderer on XP, it doesn't really matter too much if they make different color choices because I won't be using them. Do you know whether the different renderers make the same color choices?

I still haven't even compared the colors when using MPC-HC vs VLC properly yet, although it appears there probably won't be any difference, but it'd be nice to be given some practical examples of where the colors used might be different when using one player vs another etc, or when filters are really likely to effect color choices when simply playing video. Although for the moment I'd simply settle for knowing exactly what causes the WMR9 renderer to make it's color choices (and we seem to be getting fairly close), and whether the colors used when previewing video with MeGUI would always be the same (I assume they are when previewing with AutoGK as it uses MPC for previewing).

Ghitulescu

21st May 2011, 07:01

Because RGB is standardized on Windows (as sRGB, see my posts for the exact IEC name), and if the colorspace is correctly indicated in the flags, it should be correctly decoded.
Now that I said it, it's of course obvious that windows uses sRGB in DirectShow chains if the stream is modified. Ffdshow uses DirectShow AFAIK.

GodofaGap

21st May 2011, 07:10

I even mentioned it in an earlier post, explained how I thought it'd be the solution to the problem, but discovered it appears Rec.601 with ffdshow converting to RGB looks exactly the same as Rec.709 with the renderer doing the conversion, and I preferred the colors when the renderer was converting. Unless I was going mad by then...
Are you sure you disabled all of the YUV output formats then?

So when I open a video with MPC-HC and use it's internal filters, aside from deliberately enabling the color conversion shader, which filters are the going to be in the chain effecting the colors used for displaying the video? Do you have an example?
I don't use MPC-HC.

One thing I haven't yet done is compare the different renderers properly, but as for the moment I'm using the WMR9 renderer on XP, it doesn't really matter too much if they make different color choices because I won't be using them. Do you know whether the different renderers make the same color choices?
I don't recall the name, but I believe there was one notorious renderer that assumed everything to be PC-range and there or all blacks became grey and colors washed out.

I don't have an answer here to all your question. I'm just saying that if you are going to look from the perspective that the Windows OS is making all the decisions here (while it doesn't really make any) you are only going to draw the right conclusion by accident. I think that was more or less the point Ghitulescu was trying to make. Or not, I don't know, I don't care, but it's a point that needs to be made anyway.

Ghitulescu

21st May 2011, 10:43

I think that was more or less the point Ghitulescu was trying to make. Or not, I don't know, I don't care, but it's a point that needs to be made anyway.

Indeed, this is more or less my point. Windows is doing this silently, and each service pack or new version may change the things. It's not the user the one who decides on this issue, unfortunately*. This is why the pro applications (and HW drivers of pro devices) try hard to circumvent the internal routing paths of M$.

* I still consider that Vista (like Me) was a test version to see how well (or bad) the consumer will take the DRM issues.

yetanotherid

21st May 2011, 17:34

Because RGB is standardized on Windows (as sRGB, see my posts for the exact IEC name), and if the colorspace is correctly indicated in the flags, it should be correctly decoded.

So what, that's you're belief despite all the pesky evidence to the contrary?? Did you see the AVISynth page I linked to which explains how the WMR9 renderer makes is color choice according to definition?
I don't know where you get your ideas as to what should happen, because if what should happen was what actually happens I'd not have started my other thread in the first place. I've tested it and I can tell you fairly certainly the colorspaces are completely ignored when using most PC media players to play h264 video (i.e. MPC-HC, VLC etc) and the colorspace used is chosen according to the resolution.
I don't know why you keep filling threads with information which is obviously incorrect.

Now that I said it, it's of course obvious that windows uses sRGB in DirectShow chains if the stream is modified. Ffdshow uses DirectShow AFAIK.

Aside from it being obvious, what's your point?

yetanotherid

21st May 2011, 17:50

Are you sure you disabled all of the YUV output formats then?

Yes. If I didn't I don't think changing colorspaces while decoding would have had any effect, which it did, because it only applies to ffdshow's conversion to RGB.

I don't use MPC-HC.

Can you at least explain when a particular colorspace is used while playing video with the media player you do use?

I don't have an answer here to all your question. I'm just saying that if you are going to look from the perspective that the Windows OS is making all the decisions here (while it doesn't really make any) you are only going to draw the right conclusion by accident. I think that was more or less the point Ghitulescu was trying to make. Or not, I don't know, I don't care, but it's a point that needs to be made anyway.

Well if one of you could provide a specific example instead of generalisations.... but so far you're making a point without being able to provide an example to show it's true.

Indeed, this is more or less my point. Windows is doing this silently, and each service pack or new version may change the things. It's not the user the one who decides on this issue, unfortunately*. This is why the pro applications (and HW drivers of pro devices) try hard to circumvent the internal routing paths of M$.

So apparently if the colorspace is correctly indicated in the flags, it should be correctly decoded, but maybe not if you apply a service pack or upgrade Windows. Let me know when you've made up your mind as to which it is.
Sorry, but I think without an example I'll put all that in the "making it up as you go" category.
I'm not using a pro application to play video so it's obviously not relevant even if you did have an example, and what "may" happen is just speculation. I'm using MPC-HC, XP and the WMR9 renderer. If you can find a single post or piece of information which says the colorspaces used have changed with a service pack or new version of Windows, I'd be interested to see it. Although it's not terribly relevant to what my PC is doing now, and it's this PC I use for my encoding so that's all that matters to me. I'm trying to make sure I can confidently predict what it does, not what Windows 9 SP2 might do. Mind you, I've not come across any info which supports your speculation in all the reading I've done on this topic lately, so unless I find some I think I'll take your argument with a grain of salt.

GodofaGap

21st May 2011, 19:39

Well if one of you could provide a specific example instead of generalisations.... but so far you're making a point without being able to provide an example to show it's true.
Is it really so difficult when you pretty much already provided one yourself? Say you set ffdshow (or just any decoder which can control the output colorspace) to only output RGB32 and always use rec.601 coefficients for this conversion (which can be correct or incorrect). How is the renderer then ever going to use rec.709 co-efficients afterwards?

And what if I set it up to always use rec.709 instead, then how does what you find have to do with me and how does this depend on the Windows OS?

yetanotherid

22nd May 2011, 05:10

Is it really so difficult when you pretty much already provided one yourself? Say you set ffdshow (or just any decoder which can control the output colorspace) to only output RGB32 and always use rec.601 coefficients for this conversion (which can be correct or incorrect). How is the renderer then ever going to use rec.709 co-efficients afterwards?

Yeah but lets be realistic about it. I gave one example when I changed the colors deliberately and probably took the renderer out of the color equation in the process. That's not how I normally play video. There's several different ways to alter the colors manually but I don't see how it's relevant.
The subject is how a video might display on a PC using a standard video player without any user interference in color choice. You're referring to some mysterious filters which might effect the colors used on playback without my knowledge, but so far you're unable to give me any examples of which filters they might be and when it might actually happen. It sounds nice in theory, but without a practical example of when it might effect video playback in the real world....

And what if I set it up to always use rec.709 instead, then how does what you find have to do with me and how does this depend on the Windows OS?

It doesn't, but what does that have to do with the discussion and which colors are being used to display a video when I open it with MPC-HC, VLC or even with your as yet unnamed video player?
If I'm not deliberately changing something which is altering the colors then I'd like to be able to reliably determine which colorimetry the renderer is using and therefore whether it's likely to be correct. You're telling me it's not possible, but so far not able to give me a practical example of any of the so far unnamed variables you're referring to (manual user intervention aside).

I was considering one thing while typing this post. I know there's a thread here regarding the conversion of DVDs and the use of colormatrix when converting, and if memory serves me correctly there were screen shots posted of "before and after" colors to show they'd changed when encoding Rec.709 DVDs. Thinking about it, that would likely mean the player being used was respecting the R.709 colorimetry when playing the original DVD, allowing the color difference to be seen when comparing the source to the encode on a PC. I'll have to look for that thread again shortly because it might mean colorimetry info in mpeg2 streams is sometimes respected. Even so, I've not seen any evidence to suggest it's ever respected when playing other types of video and XviD doesn't write any colorimetry info anyway so the choice would then be left to the renderer.

A while back I encoded some DVDs using the wrong MeGUI preset and accidental wrote R.709 colorimetry to the video stream. I also encoded those DVDs as XviD AVIs and I'm 100% sure the two encodes display using the same colors. Therefore the incorrect usability info is being ignored when playing the x264 encodes using a PC and manual intervention aside, I've yet to find a way to get them to display using the wrong colors on playback. If either yourself or Ghitulescu can give me an example of where those x264 encodes will display incorrectly on a PC because the player is respecting the usability info then I'd be more than keen to try it. Or even be able to tell me whether they'd play incorrectly on most standalone players. That's pretty much what we're discussing here... h264 playback and the color choice of the renderer according to resolution.

I can't test what "might" happen if I install a service pack, I can't test playback using unnamed filters. I can't test conjecture.
I can test whether the color flags are being respected by my media player/renderer and I can test it's color choice according to resolution. If you have any real world examples of other factors which may influence the colors used when playing x264 video for me to test, I'm up for it.

GodofaGap

22nd May 2011, 09:18

Yeah but lets be realistic about it. I gave one example when I changed the colors deliberately and probably took the renderer out of the color equation in the process. That's not how I normally play video. There's several different ways to alter the colors manually but I don't see how it's relevant.
Because you fail to see the point. You are talking about the Windows OS as if it is some all deciding factor in how video it is displayed. It isn't, the Windows OS can't display video on its own.

If I'm not deliberately changing something which is altering the colors then I'd like to be able to reliably determine which colorimetry the renderer is using and therefore whether it's likely to be correct. You're telling me it's not possible,
I'm not telling you it is not possible to find this out with a very specific setup. I'm telling you it is not possible to make any relevant generalisation about how Windows may or may not display video, because again Windows doesn't display video.

Even so, I've not seen any evidence to suggest it's ever espected when playing other types of video and XviD doesn't write any colorimetry info anyway so the choice would then be left to the renderer.
The renderer? Why not to the decoder? Why not to a subtitle filter that makes its overlays in RGB only?

yetanotherid

22nd May 2011, 10:24

pwnsweet,
If you're still around I found a 1080p mpeg file to play with using MeGUI while looking at what the automatic color correction is doing.
The color correction part of the script doesn't change according to any resizing you might do.

LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, interlaced=true, threads=0)

As I understand it, the above will convert R.709 to R.601, or it'll do nothing if the source is already R.601 or if there's no color info in the video stream.
To confirm, I left the automatic color correction enabled and converted a section of the video without any resizing. Now I have the original 1080p video and the 1080p encode. Both will probably display using R.709 on my PC, yet the encode was fairly obviously displaying using the wrong colors, so obviously it's not a good idea to use the automatic color correction unless you're converting to SD.

In this case, after converting and resizing down to SD resolution, the encode played using the same colors as the source, so the automatic color correction got it right, but I'm sure it relies on the color info being present in the video stream. If it wasn't present I think it'd assume R.601, no color conversion would take place and the SD encode would display using the wrong colors.

Personally, unless I'm converting from SD to SD I think I'll stick to doing it manually and doing R.709 to R.601 conversion when converting from HD to SD, and not converting anything when converting from HD to HD (unless I know for sure the HD source is R.601 for some reason). It's seems a pity MeGUI by default enables automatic color correction when converting mpeg video but doesn't disable it when converting from HD to HD.

One other thing I noticed while playing around... my 1080p source used square pixels. If however I enabled anamorphic encoding MeGUI defaults to ITU resizing rather than using a 16:9 aspect ratio. I'm not sure why, but as the source isn't anamorphic I'm fairly sure ITU resizing shouldn't be used.

yetanotherid

22nd May 2011, 11:13

Because you fail to see the point. You are talking about the Windows OS as if it is some all deciding factor in how video it is displayed. It isn't, the Windows OS can't display video on its own.

No I can't see your point as without a specific example it seems to be total conjecture to me. I could post over and over that depending on the filters used or the flavour of Windows I'm running, a video might display overlaid on a picture of a pink elephant on my PC while on someone else's it won't, but unless I can provide an example of it actually happening I might as well be telling you the video might display using different colors on each PC too.
How can you tell me "this might effect color choice" or "that might effect color choice" without being able to offer a single real world example of what you're referring to? And I'm not referring to manual user intervention.

Are DirectShow or the WMR9 renderer part of Windows or aren't they? When playing x264 video using MPC-HC does the WMR9 renderer make the color decisions or doesn't it? You keep telling me Windows isn't some all deciding factor in how video is displayed on my PC, but despite my repeatedly asking for one you haven't given me one example of when it isn't.
Personally I think the whole "Windows can't display video on it's own" argument is one of semantics. Windows comes with a media player (two in fact) which can display video straight "out of the box", so effectively yes Windows can display video all on it's lonesome.

I'm not telling you it is not possible to find this out with a very specific setup. I'm telling you it is not possible to make any relevant generalisation about how Windows may or may not display video, because again Windows doesn't display video.

And I'm telling you that while you may be correct, you've offered nothing to show me you might also be completely wrong. If it turns out you're right, it looks like the only way I'll ever be able to confirm it is by proving it myself.
For all I know the next version of MPC-HC might respect every colorimetry flag in every video stream in every container format, and if it does..... great. But if it's actually the WMR9 renderer making the color decisions when converting to RGB I'd like it explained to me how that'd work. Is it actually possible for the decoder to decode the video while telling the renderer, "use these colors, dummy"?

The renderer? Why not to the decoder?

Well the way I understand it the decoder decodes the video. It's YUV, it's decoded and passed to the renderer as YUV and then the renderer picks the color method to use when converting to RGB. If that's incorrect, let me know. Aside from manually forcing a particular colorimetry (either by converting to RGB when decoding or using a MPC-HC shader etc) tell me where else in the chain color decisions can be made and the resulting display colors can then effected. If there is colorimetry info in the video stream and it's respected, then by all means explain to me how that happens. If the renderer is converting to RGB as is usually the case, does it read the colorimetry info itself, is that information passed along to it by the decoder? Please tell me how it works.

Why not to a subtitle filter that makes its overlays in RGB only?

If I use a subtitle filter external to MPC-HC it'll be VobSub. It has an option to force RGB which I've never tried, so I assume we're still in YUV land until the video reaches the renderer. Maybe I'll force RGB later to see what effect it has on colorimetry, but your example there still has no bearing on which colors are used by the WMR9 renderer when displaying YUV h264 video using MPC-HC. Obviously using a subtitle filter outputting RGB could effect colors in exactly the same way using ffdshow to convert to RGB might, or it might effect the colors in a totally different manner, but neither are really the subject of this discussion.

GodofaGap

23rd May 2011, 08:09

No I can't see your point as without a specific example it seems to be total conjecture to me. I could post over and over that depending on the filters used or the flavour of Windows I'm running, a video might display overlaid on a picture of a pink elephant on my PC while on someone else's it won't, but unless I can provide an example of it actually happening I might as well be telling you the video might display using different colors on each PC too.
How can you tell me "this might effect color choice" or "that might effect color choice" without being able to offer a single real world example of what you're referring to? And I'm not referring to manual user intervention.
I already gave you a few, but then you said they don't really count because they are not what you mean. If I say that ffdshow and other decoders and other filters can be set to only output RGB it doesn't count, because somehow it is not a real situation.

What kind of examples ARE you looking for? If only you want to know what the WMR9 renderer is doing if you feed it YUV from ffdshow or an internal decoder from MPC-HC surely you don't need a 30 post thread? Come on.

Ghitulescu

23rd May 2011, 09:03

I already gave you a few, but then you said they don't really count because they are not what you mean. If I say that ffdshow and other decoders and other filters can be set to only output RGB it doesn't count, because somehow it is not a real situation.

What kind of examples ARE you looking for? If only you want to know what the WMR9 renderer is doing if you feed it YUV from ffdshow or an internal decoder from MPC-HC surely you don't need a 30 post thread? Come on.

As you can (by now) understand, this is another thread yetanotherid hijacked, and deviated the original question to fit his demands (an almost identical question in his thread -> http://forum.doom9.org/showthread.php?t=160984).

yetanotherid

23rd May 2011, 09:11

I already gave you a few, but then you said they don't really count because they are not what you mean. If I say that ffdshow and other decoders and other filters can be set to only output RGB it doesn't count, because somehow it is not a real situation.

Of course it's a real situation, but as I tried explaining to both yourself and Ghitulescu, it's not what we're discussing. We're simply discussing which colors are used when the renderer makes the color choices for displaying YUV video. Of course if something ealier in the chain is converting to RGB all bets are off. I'd have assumed that goes without saying, if I hadn't needed to keep repeating it.

What kind of examples ARE you looking for? If only you want to know what the WMR9 renderer is doing if you feed it YUV from ffdshow or an internal decoder from MPC-HC surely you don't need a 30 post thread? Come on.

Apparently I do need a 30 post thread when I've got to explain over and over again what we're discussing. Seems it took 30 posts... but now you get it.
Mind you I kind of wonder if it'll take another 30 to have a few simple direct questions answered. Did you miss the part of my last post where I asked if DirectShow and the WMR9 renderer are part of the Windows OS, and how is it the media players which come with Windows can display video if Windows can't in fact display video on it's own?
I asked as to how the renderer receives the color information in the video stream if it respects the colorimetry flags as it has been claimed it does, but that's another question which has been conveniently ignored.

yetanotherid

23rd May 2011, 09:30

As you can (by now) understand, this is another thread yetanotherid hijacked, and deviated the original question to fit his demands (an almost identical question in his thread -> http://forum.doom9.org/showthread.php?t=160984).

No, what this is, is yet another thread where one other person and myself were discussing a topic and you popped in to post just for the sake of it and fill it with irrelevancies. While, as usual, continuing to avoid answering direct questions in case it proves you've no idea what you/we are talking about.

My thread and this one are on exactly the same topic. The OP here replied in my thread, I replied in this one, and if you look back earlier in either thread you might manage to work out that as we were both discussing the same topic in different threads, we decided to continue it as a single discussion here.
I hope you're not implying I hijacked the other thread either, given I started it, they were my questions and therefore I couldn't have hijacked anything.

You really need to get a firmer grip on reality Ghitulescu, then maybe you won't post making such stupid accusations, or continue to be oblivious to the fact it's not someone else hijacking the thread, but it's you once again being irrelevant to it.
No wonder I keep getting strikes when I've got to keep defending myself against your blatant lies.