madVR - high quality video renderer (GPU assisted)

[dansrfe]

Is it possible to use the GPU on the dedicated graphics card alone or combined with the iGPU for all processing power used by madVR, etc. regardless of whether the monitor is connected to the motherboard's displayport/hdmi/dvi or the graphics card's?

EDIT: Nevermind, found the answer: http://www.lucidlogix.com/product-virtu-mvp.shtml http://www.lucidlogix.com/eshop.shtml#compare

Now the question is, will this virtual GPU work well with madVR? I'm not sure if the "HyperPerformance" and "Virtual Vsync" will work with madVR.

[dansrfe]

If I already have an 16bit ICC profile generated by an i1 DisplayPro is it possible to extract the 3DLUT from it? Or do I need to do some other steps to get the 3DLUT?

[e-t172]

If I already have an 16bit ICC profile generated by an i1 DisplayPro is it possible to extract the 3DLUT from it? Or do I need to do some other steps to get the 3DLUT?

Yes, using the madVR ArgyllCMS procedure (http://www.avsforum.com/t/1471169/madvr-argyllcms). Just skip everything before the collink step since you already have the ICC profile. You only have one command to run. You probably shouldn't disable GPU gamma ramps however, since the profile you're using is probably meant to be used with video gamma ramps.

[dansrfe]

Yes, using the madVR ArgyllCMS procedure (http://www.avsforum.com/t/1471169/madvr-argyllcms). Just skip everything before the collink step since you already have the ICC profile. You only have one command to run. You probably shouldn't disable GPU gamma ramps however, since the profile you're using is probably meant to be used with video gamma ramps.

Super useful link thanks! I think I'll redo the icc profile generation with all the steps in the post to get a more accurate reading as well as use the 3DLUT in madVR with gamma ramps disabled which I've heard results in greater output accuracy from madVR as well?

[jkauff]

Now the question is, will this virtual GPU work well with madVR? I'm not sure if the "HyperPerformance" and "Virtual Vsync" will work with madVR.
I've had no luck getting Virtu MVP and madVR to work together. You can add a player application to the Virtu list in iMode, but when you do madVR refuses to run. I've never tried it with the display connected to the iGPU--that causes my normal apps to use the iGPU unless specifically set to dMode in Virtu. I've come to the conclusion that Virtu MVP is essentially for gamers using the dGPU who still want to use the iGPU for video processing (using QuickSync).

You can use Eric Gur's QuickSync decoder in LAV and ffdshow without Virtu when the iGPU is not connected to the display. You need a motherboard that allows you to enable dual GPUs in the BIOS, and then you create a "fake" display for the iGPU in Windows Display Resolution page. You can follow Eric's instructions in the QuickSync thread in the Video Encoding section of the board.

[ginhead]

has anyone had any issues with madNvLevelsTweaker working with the latest Nvidia drivers (I'm using 320.49). I see no change to any output after running this tool. are there specific registry edits I can check to see if the tweaker is working on my system?

btb/wtw clips when I set madvr to 0-255. I can see btb/wtw when I set madvr to 16-235, but I see a lot of banding in grayramp from madTestPatternSource. from what I've read I'm guessing that the gpu is still sending out 16-235. setting madvr to 16-235 results in a scaling of the full 0-255 output, so I see the full signal but also get banding. and there is also the nagging feeling of this not being setup correctly.

i've tested this using a panasonic plasma (set to full range) connected via HDMI and a pc monitor with a straight dvi-dvi connection. I was expecting the dvi-dvi monitor connection to send btw/wtw with madvr set to full range, but even this is not working correctly.

i've also read about editing the ini file during driver install to get full range. I'll probably try that tomorrow. and/or look into getting an ATI card.

[dansrfe]

madshi, I wonder if it's possible to have madVR to run a quick query for other discrete GPUs and possibly parallelize usage of multiple GPUs for processing? Software SLI essentially.

If the monitor is connected directly to the motherboard, madVR could bypass the iGPU and use any and all discrete graphics cards connected to the motherboard. Assuming of course that SLI isn't enabled already. I know that this would probably be at the the bottom of your list or not on it even if this was possible however, just thought I'd ask.

[ginhead]

Apparently, the last beta update came with a bunch of issues for a lot of people. My monitors quit being recognized right after I installed and rebooted so I had to revert back to the latest stable. Not sure if this also affected what madNvLevelsTweaker does though.

thanks! I am using the last released version (not beta) but this might be part of the problem. Any recommendation on a recent version that is known to work?

I did just test my HD4000 and the dvi-dvi-monitor setup. Same result. It would be nice if I could find some combination that worked as expected.

[dansrfe]

thanks! I am using the last released version (not beta) but this might be part of the problem. Any recommendation on a recent version that is known to work?

I did just test my HD4000 and the dvi-dvi-monitor setup. Same result. It would be nice if I could find some combination that worked as expected.

Yeah I deleted my post after I saw you were using the latest stable haha. :o

The levels tweaker should work with the latest stable. Just checked. Did you reboot after applying the tweak?

[Vyral]

Yes, using the madVR ArgyllCMS procedure (http://www.avsforum.com/t/1471169/madvr-argyllcms). Just skip everything before the collink step since you already have the ICC profile. You only have one command to run. You probably shouldn't disable GPU gamma ramps however, since the profile you're using is probably meant to be used with video gamma ramps.
Should I use the ICC profil provided with my display drivers to create a 3DLUT file or should I create my own ICC profil ? What is the best thing to do ?

[Qotscha]

has anyone had any issues with madNvLevelsTweaker working with the latest Nvidia drivers (I'm using 320.49). I see no change to any output after running this tool. are there specific registry edits I can check to see if the tweaker is working on my system?

btb/wtw clips when I set madvr to 0-255. I can see btb/wtw when I set madvr to 16-235, but I see a lot of banding in grayramp from madTestPatternSource. from what I've read I'm guessing that the gpu is still sending out 16-235. setting madvr to 16-235 results in a scaling of the full 0-255 output, so I see the full signal but also get banding. and there is also the nagging feeling of this not being setup correctly.

i've tested this using a panasonic plasma (set to full range) connected via HDMI and a pc monitor with a straight dvi-dvi connection. I was expecting the dvi-dvi monitor connection to send btw/wtw with madvr set to full range, but even this is not working correctly.

i've also read about editing the ini file during driver install to get full range. I'll probably try that tomorrow. and/or look into getting an ATI card.

If you want to see BTB/WTW correctly, madVR must be set to 16-235, GPU to 0-255, and your display to limited range. This, however, will result in wrong colors everywhere outside madVR.

If madVR is set to 0-255, 16-235 is expanded to 0-255 and BTB/WTW are clipped.

Here (http://forum.doom9.org/showpost.php?p=1635534&postcount=19433) is madshi's configuration recommendation.

[e-t172]

Should I use the ICC profil provided with my display drivers to create a 3DLUT file or should I create my own ICC profil ? What is the best thing to do ?

It's almost always better to generate your own profile since the one provided with the display obviously cannot take manufacturing variations into account. Of course the downside is, you need color measurement hardware (such as an i1 Display Pro (https://www.xrite.com/i1display-pro)) to be able to generate the profile yourself.

[dansrfe]

It doesn't actually mention in the madVR - ArgyllCMS thread whether or not to apply the icm file within windows as well. Is there a different procedure for that or can we just apply the profile generated in step 7?

In combination with disable GPU gamma ramps it should work correctly that way right?

[e-t172]

It doesn't actually mention in the madVR - ArgyllCMS thread whether or not to apply the icm file within windows as well. Is there a different procedure for that or can we just apply the profile generated in step 7?

In combination with disable GPU gamma ramps it should work correctly that way right?

"Apply the ICM file within Windows" is a very vague concept which could mean a number of different things depending on the assumptions you make. While an ICC profile is originally meant to contain only purely profiling information (i.e. a description of the device's color response), it has since been overloaded to also contain calibration information in the form of so-called "Video Card Gamma Tables" (vcgt tag) which is meant to be loaded in the GPU.

It doesn't really matter if you configure your device to use an ICC profile in the Windows Color control panel applet, because that only applies to applications which include a CMM (Color Management Module) and choose to use the Windows configuration to get the current monitor's profile so that they can do their transformations. Web browsers and image editing software typically are in this category. Sadly, madVR is not one of them (and that's unfortunate, hopefully madshi will implement it at some point in the future).

Now - and this is where it gets really confusing - this configuration information is also used by small tools typically called loaders (which are typically bundled with color calibration software, though there is a free one called xcalib (http://xcalib.sourceforge.net/)) that run discreetly on Windows startup and whose sole purpose is to take the vcgt (gamma tables) information from the profile which is currently configured in the Windows configuration and apply it in the GPU. These loaders don't look at the profiling information at all, and in that sense they are the exact opposite of the applications above.

So, should you load GPU gamma tables or not? Well, if your profile contains vcgt information (most of them do), then yes you should, because the rest of the profile, and by that I mean the profiling information, describes the behavior of the device with the vcgt applied. So if you're using the profile without loading its gamma tables, the result will be wrong.

If you are generating a profile purely for use with madVR, then you should generate a profile without any vcgt information (Argyll has options for that), because that removes one processing step which is likely to be better done by madVR since it does proper dithering, which might or might not be the case of the gamma tables implementation of your GPU. However, if you are using other, non-ICC-aware applications (such as games), then you might want to use the calibration provided by the gamma tables.

There is also a way to use Argyll to cleanly remove vcgt information from a profile and end up with a profile that describes the device without the vcgt applied, I believe it is explained in the ArgyLL documentation.

[dansrfe]

Essentially, all I want is the main desktop interface, windows/irfan image viewers, and web browsers to acknowledge the profile as well as madVR.

If I understood correctly, it would be best to create a profile without the videoLUT via Argyll with which I can configure to be used by the device in question in the Windows Color Management panel AND use the 3DLUT generated from this profile in step 8 with madVR. What effect would "disable GPU gamma ramps" have in this scenario? Wouldn't that option be a placebo since the profile that was applied in the color management module doesn't include the videoLUT?

Now, as you've said, without the videoLUT information presnt in the profile, the profile produces the correct result without the use of a loader during Windows startup which is a plus point. However, would this produce a less accurate result than creating a profile that includes the videoLUT?

What is the point of the videoLUT in the first place if it is not accurate enough for madVR and it has to be manually loaded during Windows startup if the profile was created with the videoLUT?

I'm not sure I understand the reason to even create profiles with videoLUTs if the benefits of creating profiles without them via Argyll allow you to load the profile without a loader.

Also, on a side note, I'm currently using the ICM profile that I got from someone else who calibrated the same monitor using an i1 Display Pro. When I launch madVR with "disable GPU gamma ramps" unchecked, madVR definitely adheres to the profiling information loaded within the color management module. It shows the corrected colors from the profile in windowed/overlay/exclusive modes as well. Maybe I've misunderstood the functionality of "disable GPU gamma ramps"?

[e-t172]

Essentially, all I want is the main desktop interface, windows/irfan image viewers, and web browsers to acknowledge the profile as well as madVR.

For applications to "acknowledge the profile", they need to be written with ICC profiles in mind, in other words, they must include a CMM. Most web browsers do. The Windows desktop, probably not. Image viewers, I'm not sure.

If I understood correctly, it would be best to create a profile without the videoLUT via Argyll with which I can configure to be used by the device in question in the Windows Color Management panel AND use the 3DLUT generated from this profile in step 8 with madVR. What effect would "disable GPU gamma ramps" have in this scenario? Wouldn't that option be a placebo since the profile that was applied in the color management module doesn't include the videoLUT?

Yes. If you're not using a profile with vcgt information, "disable GPU gamma ramps" shouldn't do anything. In theory. In practice there are some badly-written applications (e.g. Crysis) that act very rudely and set the GPU gamma ramps to something else without setting them back afterwards, so it's still better to keep this option checked to make sure you're in a known state when you're using madVR.

Now, as you've said, without the videoLUT information presnt in the profile, the profile produces the correct result without the use of a loader during Windows startup which is a plus point.

Yes, although I would be wary of calling it a "plus point". Calibration can actually be useful because it allows applications that don't support ICC (e.g. games) to have more linear color response and a more appropriate white point. As I said, figuring out what the optimal solution is can get confusing very quickly.

However, would this produce a less accurate result than creating a profile that includes the videoLUT?

In applications that support ICC, or if you use a 3DLUT generated from the ICC profile in the case of madVR, the profile accuracy should be pretty much the same. However, as I said above, for applications that don't support ICC or 3DLUTs, videoLUT calibration will give better results than doing nothing.

What is the point of the videoLUT in the first place if it is not accurate enough for madVR and it has to be manually loaded during Windows startup if the profile was created with the videoLUT?

Good question. videoLUTs are useful to improve the output of applications that don't support ICC profiles (e.g. games). In addition, videoLUTs have 16-bit output precision, so they can actually improve the behavior of the device in ways that are not possible with software CMMs if and only if you have a 10 bit or more output. Ironically, that was actually the case in the past when using VGA (which is analog so you can technically output more than 8-bit), which explains why videoLUTs exist in the first place. In addition, AFAIK video LUTs existed before ICC was introduced.

I'm not sure I understand the reason to even create profiles with videoLUTs if the benefits of creating profiles without them via Argyll allow you to load the profile without a loader.

Again, that's because videoLUTs are applied even to applications that don't support ICC. Now don't get me wrong, it won't completely fix the colors for these applications (for several reasons, one of them being that you can't do everything you want with a 3x1D-LUT as opposed to a 3DLUT), but it's still better than nothing.

Also, on a side note, I'm currently using the ICM profile that I got from someone else who calibrated the same monitor using an i1 Display Pro. When I launch madVR with "disable GPU gamma ramps" unchecked, madVR definitely adheres to the profiling information loaded within the color management module. It shows the corrected colors from the profile in windowed/overlay/exclusive modes as well. Maybe I've misunderstood the functionality of "disable GPU gamma ramps"?

By "color management module" I assume you mean the Windows color control panel applet (which is not a CMM, it's just a configuration interface that doesn't do anything itself). If you are not using a 3DLUT within madVR, the "corrected colors" you're seeing is simply the result of the vcgt gamma ramps being loaded into the GPU - which, again, is not enough to get accurate color, but, again, is still better than nothing, hence your impression that the colors are "corrected" - yes they are, but not completely. Specifically, white point, gray scale and gamma is corrected, but not hue nor saturation. To get fully accurate color reproduction you need to use a 3DLUT.

[dansrfe]

By "color management module" I assume you mean the Windows color control panel applet (which is not a CMM). If you are not using a 3DLUT within madVR, the "corrected colors" you're seeing is simply the result of the vcgt gamma ramps being loaded into the GPU - which, again, is not enough to get accurate color, but, again, is still better than nothing, hence your impression that the colors are "corrected" - yes they are, but not completely. Specifically, white point, gray scale and gamma is corrected, but not hue nor saturation. To get fully accurate color reproduction you need to use a 3DLUT.

Yes, I'm referring to the Windows color control panel (colorcpl.exe). So, that's probably why I perceive corrected white point, gray scale, and gamma on everything on the desktop. So, does that mean that the color control panel is actually a loader? If so it seems to apply the profile that contains the videoLUT automatically upon login for me. Sometimes I have to click "Set as Default Profile" again after a driver update though.

So, I think I've closed in on the question that really isn't making sense to me now. What does the ICC profile have without the videoLUT? What does the "profiling" information do? Is the profiling information for color/hue saturation? Is this what an application with a CMM will further correct? How does creation of an ICC profile without a videoLUT affect the color/hue saturation readings in the profile?

Does this mean that a 3DLUT contains measurements of profiling information such as color/hue saturation AND the videoLUT and directly loads them into the lookup tables in the GPU? Is this why it is more accurate then including a CMM in madVR and utilizing profiling and videoLUT information? If so, shouldn't 3DLUT be the standard instead of fragmented ICC profiles which may or may not contain the videoLUT and whose profiling information may or may not be applied by an application unless it has a CMM?

[Delerue]

It seems that smooth playback isn't working anymore with 0.86.10 as video stutters sometimes (23.976 FPS with 24 Hz).

[e-t172]

Yes, I'm referring to the Windows color control panel (colorcpl.exe). So, that's probably why I perceive corrected white point, gray scale, and gamma on everything on the desktop. So, does that mean that the color control panel is actually a loader? If so it seems to apply the profile that contains the videoLUT automatically upon login for me. Sometimes I have to click "Set as Default Profile" again after a driver update though.

The Windows color control panel applet is not a loader. Well, at least not by default - apparently you can make it a loader by enabling an obscure advanced option, I'll have to check.

If you see the video LUTs being changed during login, it probably means you have a loader being started upon Windows startup that you don't know about. For example the loader bundled with i1 profiling software is called "XRGamma.exe".

So, I think I've closed in on the question that really isn't making sense to me now. What does the ICC profile have without the videoLUT? What does the "profiling" information do?

In itself, nothing. The profiling information describes the color space of the device by describing a transformation between RGB triplets as displayed by the screen and real absolute color values (CIEXYZ or CIELAB). In other words, the profiling information answers the question "if I send RGB triplet (r, g, b) to the screen, what color do I get?". Using this information, CMMs are able to accurately translate between the color space of the input source (e.g. an sRGB image, or in the case of madVR, a BT.709 video) and the color space of the output device, thus achieving accurate color reproduction.

Bottom line: profiling information is used by CMMs to determine how to accurately produce a given color using your device.

Is the profiling information for color/hue saturation?

It's for everything: hue, saturation and luminance.

Is this what an application with a CMM will further correct?

Well, it's more complicated than that (or simpler, depending on your perspective). The way a CMM works, you have an input colorspace (typically sRGB, Adobe RGB, BT.709), and an output color space (described by your device profile). The CMM is simply a converter: it uses complicated algorithms (gamut mapping) to make sure colors in the input colorspace are accurately reproduced in the output color space. My point is, the CMM calculations are dependent on the input color space.

Video LUTs, on the other hand, are applied to everything and do not care what the input color space is, which is why they're quite limited in what they can do.

How does creation of an ICC profile without a videoLUT affect the color/hue saturation readings in the profile?

Well, if you generate an ICC profile without a videoLUT, the profile will describe the device's behavior without a videoLUT. If you generate a profile with a videoLUT, the profile will describe the device's behavior with a videoLUT. A videoLUT cannot affect the hue and saturation of the primaries, but it can affect the hue and saturation of non-primary colors, though technically that's just a side effect.

Does this mean that a 3DLUT contains measurements of profiling information such as color/hue saturation AND the videoLUT and directly loads them into the lookup tables in the GPU?

A 3DLUT is not loaded into the GPU lookup tables. GPUs don't support 3DLUTs directly. What madshi did in madVR is he implemented 3DLUT support himself using custom GPU shader code.

Basically, a 3DLUT is just a CMM: it converts from one color space to another. However, in the case of a CMM the transformation (3DLUT) is calculated on-the-fly depending on the input and output color spaces, as opposed to a static 3DLUT where the input and output color spaces are chosen when generating the 3DLUT. The 3DLUT doesn't contains "measurements" or even a profile: it is generated from them.

Is this why it is more accurate then including a CMM in madVR and utilizing profiling and videoLUT information?

Not sure what you mean by that.

If so, shouldn't 3DLUT be the standard instead of fragmented ICC profiles which may or may not contain the videoLUT

Define "fragmented". Why is it a problem that an ICC profile may or may not contain a vcgt? Assuming your system is configured correctly, if it contains a vcgt it will be applied, and then as long as it's applied the profiling information is correct.

and whose profiling information may or may not be applied by an application unless it has a CMM?

Well it's the exact same problem with 3DLUTs: what if an application doesn't support 3DLUTs? Keep in mind that CMMs are superior to 3DLUTs (in fact, they are a generalization of 3DLUTs) because they are able to transform between two arbitrary color spaces on the fly, while a static 3DLUT is limited to a single transformation between two predefined color spaces.

Also, keep in mind that to do color correction you need to know the input color space, and only applications know that information, so you need application support anyway. Though one could make a case about assuming sRGB as a default input color space.

[Thingol]

Webcam does not work in MPC-HC, but works in PotPlayer with madVR. Strange :(

[dansrfe]

According to this: http://www.dpreview.com/forums/post/9352418 the Windows color management panel loads the LUT into the graphics card upon startup and applications with a CMM can convert from the input to output color space using the profile information.

So, with step 8 in the madVR - Argyll guide, only the 3DLUT for Rec.709 to the devices output color space is created? What about all of the other color spaces? Does madVR do that internally? When you load the 3DLUT file into madVR does it assume that the 3DLUT file is for TV levels input/output and Rec.709 to the devices output color space?

The only thing that looks actually configurable in that command is the preferred gamma output in which the default is 2.4 but I thought 2.2 was better if you're in a lighted environment while using madVR. Is the profile's output gamma automatically a non-configurable 2.2 in step 7?

[e-t172]

According to this: http://www.dpreview.com/forums/post/9352418 the Windows color management panel loads the LUT into the graphics card upon startup and applications with a CMM can convert from the input to output color space using the profile information.

Okay, so to settle this matter and get a definitive answer, I tested it myself. Here is what I did:

1. First, I removed any third-party loader that happened to run on Windows startup.

2. Then I generated an ICC profile with bogus (heavily distorted) gamma curves so that I know for sure if the calibration is being applied or not. Specifically, I did the following:

targen -d3 strange
fakeread -k <argyll directory>\ref\strange.cal srgb.icm strange
colprof strange

3. Using xcalib, I verified that the resulting strange.icm profile really did what I wanted, i.e. it applied heavily distorted gamma curves in the GPU.

3. I set strange.icm as the default ICC profile for my device in the Windows color panel applet.

4. I rebooted.

5. Upon reboot, nothing happened. The colors on the screen are fine, which means that the calibration curves in strange.icm have not been loaded.

Hence I can confirm that, by default, the Windows Color control panel applet does not act as a loader. QED.

That being said, it appears there is actually a way to make the Windows Color control panel applet act as a loader if you go to the "Advanced" tab, click on "Change system defaults", then enable the "Use Windows display calibration" checkbox. Windows will then immediately load the gamma curves and re-apply them on login. It will not, however, restore them if an application decides to override them (this caveat applies to third-party loaders as well - to fix this issue I have a scheduled task that calls my loader every minute).

So, in summary:
- If your "Use Windows display calibration" checkbox is checked, Windows will load the gamma tables on login.
- If it is unchecked, Windows will never load the gamma tables.
- If it is unchecked but you see the gamma tables being applied on startup anyway, it's because you have a third-party loader somewhere that runs on startup. I suggest you use Autoruns (http://technet.microsoft.com/en-gb/sysinternals/bb963902.aspx) to find it.

The only thing that looks actually configurable in that command is the preferred gamma output in which the default is 2.4 but I thought 2.2 was better if you're in a lighted environment while using madVR. Is the profile's output gamma automatically a non-configurable 2.2 in step 7?

Step 7 doesn't specify a gamma. A profile does not specify gamma - well, in a way it does, but not the way you meant. The application CMM chooses the gamma (which, by the way, in most cases will simply be the gamma of the input color space - except for video for which we like to fiddle with gamma). In this procedure step 8 is basically the equivalent of a CMM, which is why it lets you specify the gamma.

If you want more details about the right gamma and how to configure gamma in that command, you should read the contents of doc/Scenarios.html in the patched Argyll archive, it explains everything with examples. You can even do amazing things like using CIECAM (http://en.wikipedia.org/wiki/CIECAM) (instead of specifying gamma) to adapt the resulting profile to your viewing environment.

Regarding your other questions about madVR, I believe madshi is more qualified to answer them.

[ginhead]

If you want to see BTB/WTW correctly, madVR must be set to 16-235, GPU to 0-255, and your display to limited range. This, however, will result in wrong colors everywhere outside madVR.

If madVR is set to 0-255, 16-235 is expanded to 0-255 and BTB/WTW are clipped.

Here (http://forum.doom9.org/showpost.php?p=1635534&postcount=19433) is madshi's configuration recommendation.

thank you for the reply. I read the:
My recommendation is always to set configure your display so that it expects PC levels (full range). This has 2 important benefits: (1) Levels will be correct for everything, including games, photos, applications and video playback. (2) There should be no problem with image quality. part of the post you linked to recommed 0-255 for the gpu (and MadVR) if you display supports full range.

I'm working under the assumption that my displays can do 0-255. The above looks to jive with madshi's configuration #1 here (http://www.avsforum.com/t/1471169/madvr-argyllcms/0_100#post_23274961).

(1) Display wants 0-255. GPU and madVR are consequently also both set to 0-255.

This is the most recommended setup because it doesn't (shouldn't) have any banding problems, and still has all video, desktop and games with correct black/white levels. In this case test patterns need to have black at 0,0,0, obviously.

I have my Panasonic plasma set to non-standard and JVC projector is set to enhanced (respective 0-255 modes).

I re-installed Nvidia drivers yesterday and did this (http://www.avsforum.com/t/1444859/setting-nvidia-to-full-range-rgb/0_100#post_22696044) ini edit to force full range. When I open MadNvLeverlTweaker, the Force PC levels check box is checked. so I have a good confidence that the gpu is set to 0-255.

I did fresh installs of MPC-HC, LAV filters and MadVR. I can see btb/wtw using EVR, but I have to make small adjustments to the sliders (+2% brightness, -2% contrast).

I still can only see btb/wtw when MadVR is set to 16-235. My shadow detail looks ok, but i feel like I'm missing something. I should get an ati card tomorrow for some additional testing.

[KoD]

There is nothing that you are doing wrong, and there's nothing that you are seeing that is wrong.
- when madVR is configured for 0-255 output, it performs range expansion from [16, 235] to [0, 255], so btb and wtw is lost;
- when madVR is configured for 16-235 output, it does not perform range expansion, so [16, 235] is still [16, 235] on output, and you see btb and wtw; and, of course, the image looks washed out, because instead of having black at 0 on output, you have it now as 16 (dark gray), and your white is not pure white anymore at 255, but a light gray at 235.

But I notice you have a Panasonic plasma, and from my experience (at other people's experience), Panasonic plasmas don't handle RGB input correctly. YCbCr 4:4:4 is properly handled, so you might want to set your video card output to YCbCr 4:4:4. I have never tried to force RGB levels in the nVidia drivers with my Panasonic plasma however, so I don't know if that might fix RGB input.

[e-t172]

So, considering the confusion around ICC profiles and Argyll and 3DLUTs and whatnot, I generated some test ICC profiles so that people can test their workflow and determine if their system is applying calibration and/or profiling correctly.

The attached archive (currently pending moderator approval) contains the following files:

strangecal.icm: ICC profile containing strange video card gamma tables (vcgt) giving a strong bluish tint, and sRGB (i.e. no-op) profiling information.
strangeprof.icm: ICC profile containing strange profiling information giving insane results, and no video card gamma tables (vcgt).

So, using these profiles, you can determine with 100% certainty if the calibration (vcgt) information is being applied or not, and you can determine if the applications you're using take the profiling information into account as well. My limited testing shows, for example, that on my system the Windows default image viewer correctly uses the currently configured ICC profile, while Firefox does not (which is strange since it's supposed to, it might be a bug).

Here's how these profiles are supposed to look:
original: http://i.imgur.com/CZOpvqCs.jpg (http://imgur.com/CZOpvqC) strangecal: http://i.imgur.com/8UsmYc7s.jpg (http://imgur.com/8UsmYc7) strangeprof: http://i.imgur.com/M2J8Bcvs.jpg (http://imgur.com/M2J8Bcv)

The profiles have been generated using the following series of commands and Argyll 1.5.1:

strangecal:
targen -d3 strangecal
fakeread -i argyll\ref\strange.cal argyll\ref\sRGB.icm strangecal
colprof -q l strangecal

applycal strange.cal strangecal.icm strangecal.applied.icm
collink sRGB.icm strangecal.applied.icm srgb2strangecal.icm
cctiff srgb2strangecal.icm sample.jpg sample.strangecal.jpg

strangeprof:
targen -d3 strangeprof
fakeread -r 30 argyll\ref\sRGB.icm strangeprof
colprof -q l strangeprof

collink srgb.icm strangeprof.icm srgb2strangeprof.icm
cctiff srgb2strangeprof.icm sample.jpg sample.strangeprof.jpg

[cyberbeing]

For anybody wondering, if you want subtitles from XySubFilter to show up in your madVR screenshots with MPC-HC there are a couple ways to do so:

A) Save the screenshot when the video is viewed at Original Video Size prior to resizing (100% Zoom, except on anamorphic video).

B) Save the screenshot at any Zoom level or fullscreen, when the "Render to Original Video Size" option is enabled in XySubFilter (note that this is a lower-quality option similar in appearance to VSFilter.dll RGB output)

This limitation exists because madVR outputs screenshots at original video size, prior to resizing the video frame. Without doing A) or B) the subtitle will only be alpha-blended into the video frame after resizing. Removing this limitation is something on madshi's to-do list, but no timeline that I'm aware of. For the time being you'll need to make do with the above, if you want subtitles in your screenshots with XySubFilter.

I've been hearing claims on the web that the above methods to take screenshots with subtitles were not working for some people.

After a bit of investigation, I realized what the problem was. Subtitle output levels from XySubFilter must be TV range to match madVR. This means you must keep the "Optimize Subtitles for Performance instead of Quality" option in madVR checked (which is the default setting), or else madVR and the MPC-HC screenshot function will never produce screenshots with subtitles. This is yet another madVR limitation, since the PC->TV range shader pass for PC range subtitles ("Optimize Subtitles for Performance instead of Quality" disabled) causes alphablending into the video to occur after screenshots are output.

[DragonQ]

There is nothing that you are doing wrong, and there's nothing that you are seeing that is wrong.
- when madVR is configured for 0-255 output, it performs range expansion from [16, 235] to [0, 255], so btb and wtw is lost;
- when madVR is configured for 16-235 output, it does not perform range expansion, so [16, 235] is still [16, 235] on output, and you see btb and wtw; and, of course, the image looks washed out, because instead of having black at 0 on output, you have it now as 16 (dark gray), and your white is not pure white anymore at 255, but a light gray at 235.

But I notice you have a Panasonic plasma, and from my experience (at other people's experience), Panasonic plasmas don't handle RGB input correctly. YCbCr 4:4:4 is properly handled, so you might want to set your video card output to YCbCr 4:4:4. I have never tried to force RGB levels in the nVidia drivers with my Panasonic plasma however, so I don't know if that might fix RGB input.
Hmm my Panasonic Plasma seems to handle it fine. In fact, I can get a better calibrated image when expanding to 0-255 and then outputting 0-255, rather than leaving the video at 16-235 and outputting 0-255.

Selecting RGB or YCbCr in the nVidia Control Panel doesn't seem to make a difference.

[ginhead]

- when madVR is configured for 0-255 output, it performs range expansion from [16, 235] to [0, 255], so btb and wtw is lost

Wow...I finally get it. Your 'range expansion' explanation did it. This is so obvious now...how can one expect to see anything <16 if 16 is now mapped to zero. I also used to know this...I was using range expansion about it 10 years ago with a business projector that did not support TV levels with a computer signal. Hopefully this gap in understanding does not result in revocation of my av nerd card.

Thanks for the Panasonic plasma heads up. I recently purchased a used i1pro and really excited to setup 3dluts with madvr. Time to start reading and testing.

Thanks (to all) for the helpful posts.

[KoD]

@ginhead: glad to be of help

@DragonQ: my Panasonic is an older model. Maybe things have changed. But I could never have proper colors in RGB mode, and when playing something using EVR as renderer I always had issues. Could be nVidia's automatic range expansion on video content played full-screen with EVR, could be Panasonic's bad EDID info, I don't know. I'm now using a Sony HX850 LED TV, which is a fair enough TV, not as great as the reviews that I've read before purchase made it sound like (you can never trust any review site, not even those that seem very professional), but which, at least, properly advertises its capabilities to the video card, and there is no need for a Full range RGB HDMI hack of the drivers to make it work properly.

@e-t172: I can not see what's in the archive, but Firefox only handles images with embedded ICC v2 profiles. It displays wrongly image files with an ICC v4 profile embedded. I assume it doesn't actually have a CMM integrated, but it just uses the OS's one. The default image viewer in Windows also makes a mess of images when the profile installed in Windows is a v4 one. A test for web browser rendering of images with embedded v4 and v2 ICC profiles is available here: http://www.color.org/version4html.xalter

[e-t172]

@e-t172: I can not see what's in the archive

Yeah, I know. The attachment is still pending moderator approval and I guess they are in a US timezone.

Firefox only handles images with embedded ICC v2 profiles. It displays wrongly image files with an ICC v4 profile embedded. I assume it doesn't actually have a CMM integrated, but it just uses the OS's one. The default image viewer in Windows also makes a mess of images when the profile installed in Windows is a v4 one. A test for web browser rendering of images with embedded v4 and v2 ICC profiles is available here: http://www.color.org/version4html.xalter

I'm aware of that. Argyll doesn't support ICCv4 anyway, so that's irrelevant. Even with ICCv2 profiles, using images with embedded profiles (such as the ones on your page) and even when setting gfx.color_management.mode to 1 (https://developer.mozilla.org/en-US/docs/ICC_color_correction_in_Firefox), Firefox seems to simply ignore the currently configured device profile, i.e. when I test with my "strangeprof" profile set in the Windows color control panel applet I get normal colors, which indicate it's not working properly.

The strange thing is, the CMM seems to be running, as the color.org test page is positive for the ICCv2 test, it just seems to ignore the currently configured device profile.

EDIT: I just tested in IE10, it has the same problem. Maybe there's an issue with my methodology here.

[Guest]

The attachment is still pending moderator approval and I guess they are in a US timezone. Attachment approved.

[dansrfe]

Is Reclock supposed to be at 29.970 or should I manually set it to 23.976 when madVR is IVTC'ing with a 3:2 cadence?

[mindbomb]

Is Reclock supposed to be at 29.970 or should I manually set it to 23.976 when madVR is IVTC'ing with a 3:2 cadence?

it should auto detect the right frame rate with a little time

[italospain]

it should auto detect the right frame rate with a little time

unfortunately it does not work with madVR inernal ivtc. Madshi explained why recently.

So you have to set the framerate in ReClock manually.

[dansrfe]

I know that madVR doesn't support portrait mode however, out of curiosity, why is that madVR has to "support" portrait mode? Isn't it just another monitor resolution that is used? Or does it have something to do with the information sent across the cable which instructs the monitor to "accept" the portrait aspect resolution which requires individual application support?

[cyberbeing]

Isn't it just another monitor resolution that is used?

FWIW, madVR does support "yet another" monitor resolution that happens to be in portrait aspect ratio (e.g. 1080x1920). I can only assume that "portrait mode" is an OS function which rotates a standard resolution, and madVR is currently unaware of how to read and handle such rotations.

[MSL_DK]

Hi ... Regarding madTPG, should I select 'disable VideoLUTs' throughout this workflow?

dispcal -v -X WLEDFamily_07Feb11.ccss -Y p -m -d madvr -qm -w 0.3127,0.3290 -gs -o TVmtx.icm TV >>dispcal.txt
targen -v -d3 -s30 -g100 -f1000 -cTVmtx.icm TV >>tagen.txt
dispread -v -X WLEDFamily_07Feb11.ccss -Y p -d madvr -K TV.cal TV >>dispread.txt
colprof -v -qh -bl TV >>colprof.txt
collink -v -3m -et -Et -Ib -G -ir -a TV.cal Rec709.icm TV.icm HD.icm >>collink.txt

And activate 'disable VideoLUTs' throughout this workflow?

dispcal -v -X WLEDFamily_07Feb11.ccss -Y p -m -d madvr -qm -w 0.3127,0.3290 -gs -o TVmtx.icm TV >>dispcal.txt
targen -v -d3 -s30 -g100 -f1000 -cTVmtx.icm TV >>tagen.txt
dispread -v -X WLEDFamily_07Feb11.ccss -Y p -d madvr -K TV.cal TV >>dispread.txt
colprof -v -qh -bl TV >>colprof.txt
collink -v -3m -et -Et -Ib -G -ir -H TV.cal Rec709.icm TV.icm HD.icm >>collink.txt

the reason for my question is that with "-a TV.cal" achieves a strange result ... white is yellowish

[dioxholster]

this is more of a general question, does anyone use madvr gamma processing? what is recommended value?

[dansrfe]

this is more of a general question, does anyone use madvr gamma processing? what is recommended value?

Personal preference. Movies are mostly @ 2.4 but since desktops use 2.2 and it's easier to see with 2.2 during the day most people just stick to 2.2 or have the monitors/TVs in an environment where they can completely block any light and choose 2.4.

[jmonier]

I'm finding that I cannot permanently disable Smooth Motion. I can disable it while playing, but when I stop playing (NOT pause) and then start playing again it is re-enabled. Is anyone else seeing this (especially if you're using ZoomPlayer)?

[romulous]

@jmonier: Zoom has its own setting to control madVR's Smooth Motion. Check the following and disable it if it is enabled:
http://i.imgur.com/lQTWXyW.png

[dansrfe]

@jmonier: Zoom has its own setting to control madVR's Smooth Motion. Check the following and disable it if it is enabled:
http://i.imgur.com/lQTWXyW.png

That's not a good move by the ZoomPlayer devs IMHO. That's two places for the same setting and AFAIK only madVR knows when to change it's own value on the interface and that's when it changes the value itself. ZoomPlayer changing the value behind madVR's back or the other way around while either of the two is running is a setup for unwanted behavior and on the road for increased debugging headaches.

[jkauff]

That's not a good move by the ZoomPlayer devs IMHO. That's two places for the same setting and AFAIK only madVR knows when to change it's own value on the interface and that's when it changes the value itself. ZoomPlayer changing the value behind madVR's back or the other way around while either of the two is running is a setup for unwanted behavior and on the road for increased debugging headaches.
I think if you uncheck Smooth Motion in Zoom options, it completely ignores the setting in madVR options. The only rationale I can see for this is perhaps a bug in Zoom code that doesn't process the setting in madVR the way it should. It can't be for user convenience, because the setting is disabled by default in madVR.

Since this "feature" is only in the beta version, maybe they'll ditch it for the final release.

[jmonier]

@jmonier: Zoom has its own setting to control madVR's Smooth Motion. Check the following and disable it if it is enabled:
http://i.imgur.com/lQTWXyW.png

Thanks. I was aware of the option but the language is ambiguous and I had interpreted it as simply allowing Smooth Motion to be used. What it does, in fact, is to absolutely turn it on or off at the beginning of playback. Once playback is started, however, it has no effect and madVR has control via the dialog or keyboard shortcut.

It does allow you to control it from ZP via a keyboard shortcut or the Communications API when you cannot do it from madVR, i.e. when nothing is playing. This could be useful. That does make it confusing, however.

[romulous]

What it does, in fact, is to absolutely turn it on or off at the beginning of playback.

Correct.

Once playback is started, however, it has no effect and madVR has control via the dialog or keyboard shortcut.

Correct again. madVR controls it whether it is used or not while a video is playing - Zoom just enables or disables the setting to begin with.

It does allow you to control it from ZP via a keyboard shortcut or the Communications API when you cannot do it from madVR, i.e. when nothing is playing.

Also correct.


language is ambiguous and I had interpreted it as simply allowing Smooth Motion to be used

Do you have any suggestions for alternate wording? If so, I will put it to Blight.

[jmonier]

Do you have any suggestions for alternate wording? If so, I will put it to Blight.

"Turn on/off madVR Smooth Motion (overrides MadVR option)" ?

[romulous]

What about if we add the 'override' bit to the end of the current naming? As in:
"Enable MadVR's smooth motion (over-ride madVR option)"

I don't think we need both the enable/disable bit in the text - just one of those should be fine. The confusion is not so much about whether ticking the option will enable something, or will disable something - but more so that the option affects madVR's option. That bit needs to be made clearer.

[jmonier]

What about if we add the 'override' bit to the end of the current naming? As in:
"Enable MadVR's smooth motion (over-ride madVR option)"

I don't think we need both the enable/disable bit in the text - just one of those should be fine. The confusion is not so much about whether ticking the option will enable something, or will disable something - but more so that the option affects madVR's option. That bit needs to be made clearer.

That would be better, but to my mind it still doesn't make it clear that un-checking the option also controls madVR.

Maybe: "...(always over-rides madVR option)"

[romulous]

Cool, that sounds fine to me. I will put it to Blight that the option be renamed to "Enable MadVR's smooth motion (always over-rides madVR option)".

[madshi]

madVR v0.86.11 released

http://madshi.net/madVR.zip

* added import option for eeColor 3dluts (e.g. from LightSpace CMS)