madVR - high quality video renderer (GPU assisted)

[turbojet]

Originally Posted by turbojet View Post
Tried that in both user mode and admin mode, which should it be? It had no effect.


Did you reboot after using madLevelsTweaker? If that doesn't help then something else is going on. Make sure you disable (and set to neutral values) all options in the GPU control panel like color/gamma adjustments, dynamic contrast, skin tone adjustments, etc etc. Maybe a driver cleaning and reinstall will help? I'm not sure what else to suggest...

Yes, box is checked. nvidia control panel is all defaults which it looks like it's set to all application controlled. I'll try yet another clean install but I just did that yesterday. This has been something I've been noticing for months but it's starting to aggravate me now. It happens on 2 different computers+tv's too, both nvidia gpus.

[6233638]

What is the standard gamma curve of modern LCD TVs?There is no standard. I would use 2.2 gamma (1/0.45) if nothing has been specified in the madVR configuration though, as it is most likely to be used if a display does have a decent out of the box calibration.

[Audionut]

Isn't dithering the final step before rendering? In that case, shouldn't it (luminance) map to whatever the device is calibrated too? Based on the settings in the calibration tab.

Otherwise, wouldn't it be best to map back to the source profile?

[James Freeman]

turbojet,
I think for the last few driver versions Nvidia forced 0-255 with 60Hz, and 16-235 with 59Hz on HDMI output.
So if you set madLevelsTweaker to full range and refresh rate to 60Hz you get double expansion (clipped black and white).
Or changing to YCbCr444/RGB changes the range too in NCP.

It can be my display so don't take my word for it, test yourself.

[6233638]

Isn't dithering the final step before rendering? In that case, shouldn't it (luminance) map to whatever the device is calibrated too? Based on the settings in the calibration tab.I agree, it should follow the calibration tab. (and 3DLUTs will need a preference to set what their display is calibrated to)

Otherwise, wouldn't it be best to map back to the source profile?If I recall correctly, the end-to-end gamma target for BT.709 content is intended to be around 1.2

1.2/0.51 = 2.35

Though newer standards based upon measurements of mastering-grade monitors (BT.1886) have moved this to 2.40 rather than 2.35

Displays sold today are far more likely to be around 2.2 gamma than 2.35 out of the box though, which is why I would suggest using that value instead if nothing is specified.

[turbojet]

Clean driver install had no effect. The 250 is connected via s-video to a 59Hz crt with latest drivers. A 650 (327 drivers) is connected to 24/48/50/60Hz LCD via hdmi. I'll go check to see if there is a difference when switching refresh rate on the LCD.

[iSunrise]

What are you calibrating your screen to? BT.709 content should be viewed using the BT.1886 transfer function (which becomes a flat 2.40 gamma on high contrast displays) and never the BT.709 transfer function, which is intended for capture, not playback.
Depending on the content I view, I have several choices to go with. I know that Rec.709 is only intended for capturing/monitoring, but BT.709 still is the closest here. BT.1886 didn´t work out to well for me last time I tried. Then again, I´m not using DispCal or the ArgylCMS, I´m using the Eizo Colornavigator for this.

[Audionut]

(and 3DLUTs will need a preference to set what their display is calibrated to)

What does madVR currently do with a 3dlut selected? Unless I am missing something, there is no option to set a gamma in that case.

If the 3dlut doesn't contain that information, then I agree.

BT.1886 didn´t work out to well for me last time I tried. Then again, I´m not using DispCal or the ArgylCMS, I´m using the Eizo Colornavigator for this.

I found BT.1886 to be extremely useful on my display. It allowed me to effectively crush the blacks with display controls (making black actually look like black) (nothing retarded like setting the black control to 0, but crushed non the less), and the calibration lifts the shadow details on playback.

In essence, I now see excellent shadow detail, with actual blacks.

Previously, I would either have crushed blacks, or grey shadows. It was impossible (for me), to get the display to show a pure black with shadow detail.

[iSunrise]

PotP won't let me select the image source filter AFAIK, it'll always be "Image source". It would be most amazing if you could nail down the name of the still images source filters used in PotP & MPC and provide a picture-viewer mode in mVR that would kill all black frames(that keep coming and going more or less randomly, making it very hard to use) and allow to setup a custom profile with 256 neurons all the way :devil:
PotP just needs to support a way to select LAV as the source filter for tiff, png, jpeg, tga and bmp images (the PotP author only really needs to add these, because it already has checkboxes for several file formats that LAV supports), since nevcairiel already added that in 2012. In that case, madVR would take care of the rest.

[leeperry]

The trick is to do a 1D gamma ramp calibration first via ArgyllCMS, but then to "merge" the final 1D gamma ramps into the 3dlut.
And the 3DLUT+ArgyllCMS headaches will begin, otherwise you're stuck with a banding .cal file applied in 8bit by the GPU drivers after mVR's dithering....that's why I specifically wanted a display with proper calibration options(and applied in 10/12bit at that) so this would all be like waking up from a bad dream.

PotP just needs to support a way to select LAV as the source filter for tiff, png, jpeg, tga and bmp images (the PotP author only really needs to add these, because it already has checkboxes for several file formats that LAV supports), since nevcairiel already added that in 2012. In that case, madVR would take care of the rest.
And what would that change? Can mVR already run a picture-viewer mode when using LAV? Anyway, feature requests are closed so I'll keep playing hide & seek with the random black frames if I find the patience.

None of the images you posted thus far are all that close to overall brightness and gamma response of the original when viewed on my display.

Gamma is brighter than the original. BT.709 2.2 is darker than original. The rest are much, much darker.
Exactly what I'm seeing as well.

my display is calibrated to a BT.709 curve scaled to ambient light. Essentially it matches BT.709 near-black, and matches L* across the rest of the luminance range.
Personally, I chose the most acceptable gamma preset in my TV(that goes from -3 to +3, I picked -2 which is pretty dark..around 2.4), then I maxed out the contrast(not clipping in HCFR, everything's smooth there) and I set the brightness setting to my taste. I'm spot-on D65, blacks are slightly crushed but PQ is stunning and my CRT's always came with crushed blacks, I'm not all that interested in what happens in the 3 first levels(out of 256) tbh.

Things might be different if there were proper gamma settings/10 points white balance in my F5000 Sammy TV but only their "6" serie does that and anything higher that their "5" serie can't do BFI without FI duh...and I think I like slightly crushed blacks anyway. Definitely not going back to Argyll, especially after whining to Graeme for the Nth time about BT1886 looking funky and him sending me yet another possible bug fix....20 mins of flashing colors to end up with a crappy gamma curve are beyond my patience.

[Eiffel]

I've been a long time lurker on this thread, and am very pleased with the latest scaling options (most of my testing has been with old DVB movie recordings, which work best with NEEDI3 64 neurons for both chroma upscaling and double Luma resolution, no NEEDI3 chroma doubling, Lanczos 3AR impage upscaling and Bicubic AR downscaling, ordered dithering and no quality trade off using a Sapphire 7770 GPU and 1080p displays).

I've played with Error diffusion, but have to reduce the NEEDI3 doubling scaling to make it work, with is not as good (softCubic lacks some of the sharpness which I like)

While on the display topic, I have spent quite a bit of time getting 3Dluts to work well. This was easy on an IPS display but is proving much harder on my JVC HD750 projector, where -so far- I'm getting better results with manual calibration (11 Gamma points per primaries and CMS) than with a 3Dlut, in terms of gamma by color over the gray scale and fully saturated colours (the only place where 3Dluts consistently with is in terms of dE for less saturated colors).

Interestingly, depending on the projector gamma curves and gamut settings, the 3Dlut generated by Argyll CMS can be a flat 2.4 gamma, or increase to this level (with everything set exactly the same way including BT1886 target, dark room, etc.). I'd expect it to be more consistent (likely flat given the CR). I probably have more to learn!

I haven't played with dithering enough to comment, and am still pursing ideas to improve on the calibration results for the time being.

[Asmodian]

Argyll still seems to have issues with creating 3DLUTs which fail BTB/WTW clipping tests

This is intended to be a feature but I too would like an option to clip wtw/btb. BTB is clipped for me because I do no black point correction but Argyll 3DLUTs allow any primary that can to increase/decrease into wtw/btb as a way to avoid clipping.

Argyll has gotten much better at creating 3DLUTs, you might want to give it a try. It will fail clipping tests, of course, but I get very good results within the normal range (as measured with HCFR). Both Argyll and HCFR use madTPG. :)

[Eiffel]

20 mins of flashing colors to end up with a crappy gamma curve are beyond my patience.

This ain't too bad, a basic 3Dlut creation using the settings from http://www.avsforum.com/t/1471169/madvr-argyllcms, and a fast sensor (i1D3) takes 3 hours with my projector :)

[nevcairiel]

Definitely not going back to Argyll, especially after whining to Graeme for the Nth time about BT1886 looking funky and him sending me yet another possible bug fix....20 mins of flashing colors to end up with a crappy gamma curve are beyond my patience.

So he actually tries to fix the bug and sends you versions to test, and you thank him by whining even more and calling his software names? :p
Remind me to never try to help you! :)

FWIW, my screen resulted in a really good calibrated result after Argyll, but truth be told my Sony screen was pretty close before, Gamma is and was good, only gamut needed a bit of adjustment, as the built-in controls aren't fine-grained enough.

[leeperry]

a basic 3Dlut creation using the settings from http://www.avsforum.com/t/1471169/madvr-argyllcms, and a fast sensor (i1D3) takes 3 hours with my projector
Killing 3 hours of light bulb for Argyll makes little sense to me, I'm sure your time & money might be much better spent. You're on the verge of OCD my good friend ;)

So he actually tries to fix the bug and sends you versions to test, and you thank him by whining even more
I've been whining for bug fixes regarding Argyll not working as I was expecting it to for years, I officially give up. I'm sure he'll easily find more dedicated testers.

[turbojet]

It wasn't actually overlay issues with the 650>hdmi>lcd tv. It' nvidia's drivers forcing pc levels on 25, 30, 50, 60hz and tv levels on 24 and 48 hz over hdmi. I had it setup to enable overlay only when ivtc was enabled so I thought overlay was the culprit like it has been for a long time on svideo. nvidia seems to be forcing pc levels on all dvi out, tv levels on s-video.

The level tweaker doesn't seem to have an effect on hdmi or s-video out with nvidia gpus, haven't tested dvi yet. Also it asks for admin privileges on windows 7 but not on 8.1. Other programs ask for it on 8.1.

Is there another workaround to force nvidia to output one level on hdmi or is there something madvr can do to work around nvidia's mess?

edit: http://blog.metaclassofnil.com/?p=83 this worked to fix hdmi levels. inf driver hack didn;t.

Also is there any reason why overlay is sending pc levels over svideo while window and fse are sending tv levels?

[SamKook]

Not sure which change did it since I didn't notice anything specific to it in the changelogs, but the jump from 0.87.4 to 0.87.6 made madvr work with Nvidia surround enabled so I can now use madvr again on my main pc with my 3 monitors enabled, thanks.
It created a "Generic Non-PnP Monitor" instead of using the "Asus NV Surround" one like before when it was failing(or maybe that's due to me updating to the latest driver).

[jkauff]

Sorry to interrupt the dithering discussion, but I noticed a puzzling occurrence on one particular DVD. The profile I use for standard DVDs using the latest madVR typically pushes my GTX 770 to about 90% load. Playing back this one b&w video, however, causes the load to drop down to 45% about once every minute, then it returns to normal. Playback looks fine--I just can't understand what's causing the drop in GPU load. Image doubling is enabled, BTW, and the fact that the drop is almost exactly 50% makes me wonder if the image doubling is involved.

Again, not a problem, I'm just curious.
Found my own solution. It's caused by LAV, using QuickSync for decoding. Happens in all DVD sources, but not when they're converted to MKV files. When I change to software decoding, GPU stays at 90%. Must be something about the way QS handles VOBs.

[seiyafan]

Another n00b question, will the dithering in LAV affect the dithering in MadVR? Because I saw a dithering option in LAV encoding, not sure what it does in relation to MadVR's dithering.

[Q-the-STORM]

Another n00b question, will the dithering in LAV affect the dithering in MadVR? Because I saw a dithering option in LAV encoding, not sure what it does in relation to MadVR's dithering.

LAV doesn't dither when you use madVR...

[Ver Greeneyes]

Here's the Avatar dithering comparison again, with added images using different transfer functions for linear light dithering:

|- gamma (http://madshi.net/avatar2bitGamma.png) -|- original (http://madshi.net/avatar8bit.png) -|- linear (pure power 1/0.45) (http://madshi.net/avatar2bitLinear.png) -|- linear (sRGB 2.4) (http://madshi.net/avatar2bitSRGB.png) -|- linear (BT.709 1/0.45) (http://madshi.net/avatar2bit709.png) -|Thanks! Out of these, sRGB preserves the most detail but also brightens the source somewhat. 709 is most correct in terms of hue, saturation and brightness, but still looks noticeably darker than the original near black. Unfortunately I don't have an easy way of looking at the images from far away while still switching between them quickly, so I had to make do with flipping back and forth between the original and the bit-reduced images from fairly up close. Both sRGB and 709 are pretty close to the original for me, which matches my somewhat hybrid calibration (Rec.709 adjusted for sRGB viewing conditions).

I should note that I viewed these in my browser (Firefox) with my Rec.709-focused ICC profile active (gfx.color_management.mode = 1) and 1D curves loaded into my videoLUT. Without the videoLUT (i.e. if madVR were applying the 1D curves from the 3DLUT prior to dithering) I would expect something native to my display's response to give the best match. And there's the rub - unless madVR were to take that into account*, I can't say what the best curve would be, but 1.0/0.45 is probably a fair approximation of consumer hardware.

* which would, in its simplest form, probably involve loading another file like a 3DLUT that just gives the 3xN value curves for transforming to linear light RGB. Out of curiosity, if you build the ability to load custom shader files into madVR, would you consider letting us override the gamma-light-to-linear-light-for-dithering function with with a suitably named shader? That way it's very much an advanced-users-only feature. We could generate a lookup table from our .cal file and bake it straight into the shader ;) (though honestly I don't know how bad that would be for performance)

[Shiandow]

* which would, in its simplest form, probably involve loading another file like a 3DLUT that just gives the 3xN value curves for transforming to linear light RGB. Out of curiosity, if you build the ability to load custom shader files into madVR, would you consider letting us override the gamma-light-to-linear-light-for-dithering function with with a suitably named shader? That way it's very much an advanced-users-only feature. We could generate a lookup table from our .cal file and bake it straight into the shader ;) (though honestly I don't know how bad that would be for performance)

I think such a lookup table won't be much good since it require interpolation, and if you simply use linear interpolation then I think the shader won't do that much.

If you want to do it that way then I think the best way to do it is not to store the entire gamma curve in a lookup table but the 'local' gamma i.e. the slope in log-log space. I believe that this will give you the best result with relatively little effort. Here's a shader that uses this 'trick' to approximate an sRGB curve:


#define depth 255
sampler s0 : register(s0);

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float4 c0 = tex2D(s0, tex);
float4 low = floor(depth*c0)/depth;
float4 hi = low+(1/depth);
float4 gamma = max(1,2.4*low/(low+0.055));
float4 c1 = (pow(c0,gamma)-pow(low,gamma))/(pow(hi,gamma)-pow(low,gamma));
return low+(c1/depth);
}


You should get pretty decent results even if the 'gamma' is slightly wrong so you probably don't need a lookup table for all 256 different values. And if you try to edit this code make sure that you use either 'low' or 'hi' to calculate the gamma, changing the gamma midway can lead to very strange results.

[Ver Greeneyes]

I think such a lookup table won't be much good since it require interpolation, and if you simply use linear interpolation then I think the shader won't do that much.I disagree. Even a 3x256 lookup table will be a very good approximation to your display's gamma curve, linear interpolation won't harm that (linear interpolation is just a better approximation than a step function). And there's nothing stopping you in principal from using a 3x1024 lookup table or bigger. Remember, all we're looking for here is the distance between two 8-bit values to approximate the error and how much of it was diffused.

Of course if you're using a videoLUT, then you could skip the lookup table and just use the expression for the curve you calibrated to. But a display's native response isn't likely to be that smooth.

[Shiandow]

I disagree. Even a 3x256 lookup table will be a very good approximation to your display's gamma curve.

I agree, but if a linear interpolation is good enough then you can achieve that by just using gamma light dithering. It makes no sense to try to improve on a linear interpolation of the actual gamma curve of your monitor, by using a linear interpolation of a measurement of the same gamma curve.

[kasper93]

Here's the Avatar dithering comparison again, with added images using different transfer functions for linear light dithering:

|- gamma (http://madshi.net/avatar2bitGamma.png) -|- original (http://madshi.net/avatar8bit.png) -|- linear (pure power 1/0.45) (http://madshi.net/avatar2bitLinear.png) -|- linear (sRGB 2.4) (http://madshi.net/avatar2bitSRGB.png) -|- linear (BT.709 1/0.45) (http://madshi.net/avatar2bit709.png) -|

Again, make sure you watch these at 100%. Having your browser zoom these will totally screw up everything.

The key point to take from this screenshot comparison is that dithering in gamma light is not correct. I hope everybody can agree with that now? Which image looks best to you will directly depend on how your display is calibrated. The image created with the transfer function nearest to your display calibration should look nearest to the original 8bit image to your eyes.

Linear light looks better, a lot. I should say, closer to original :) I think BT.709 is best for this image, but it's really close to sRGB, I mean I couldn't pick obvious winner.

I may have missed something, but "use colored noise" doesn't seem to have effect on ED. But works for others...

[Ver Greeneyes]

I agree, but if a linear interpolation is good enough then you can achieve that by just using gamma light dithering. It makes no sense to try to improve on a linear interpolation of the actual gamma curve of your monitor, by using a linear interpolation of a measurement of the same gamma curve.The 'linear interpolation' that gamma light uses is just a straight line, it isn't an interpolation at all. Dithering uses it to weight the fractional error, determining how many pixels end up as brighter than the original and how many end up as darker. With linear weights, the effect that a bright pixel has on a dark pixel is weighted the same as the effect of a dark pixel on a bright pixel. By transforming into linear light first, they are weighted differently. In addition, patches of the same color will compute the remaining error differently depending on the weighting curve.

Now I agree that for very small differences between adjacent pixels (1/255 or less), you'd need a lookup table bigger than 3x256 for it to have an effect. Which also means that using gamma light versus linear light doesn't make a very big difference in 8-bit mode. But if we're striving for perfection, a > 8-bit lookup table would be best. A 12-bit table (3x4096) would cover the smallest differences that humans can discern, but that might have a bigger impact on performance (I don't know). 11-bit seems to be the limit of what madVR's dithering can do as far as calibration is concerned.

[Shiandow]

Now I agree that for very small differences between adjacent pixels (1/255 or less), you'd need a lookup table bigger than 3x256 for it to have an effect. Which also means that using gamma light versus linear light doesn't make a very big difference in 8-bit mode. But if we're striving for perfection, a > 8-bit lookup table would be best.

Those very small differences are precisely the part that the linear light shader changes, if you use that shader with a gamma curve which is linear in-between adjacent values then there will be no difference between the input and the output.

[Ver Greeneyes]

Those very small differences are precisely the part that the linear light shader changes, if you use that shader with a gamma curve which is linear in-between adjacent values then there will be no difference between the input and the output.Right, so for a 6-bit+FRC monitor an 8-bit table would make a difference in 6-bit mode, and for an 8-bit monitor you'd need something bigger. As a proof of concept you could test with an 8-bit table in 3-bit mode, just so long as you scale up for actual viewing.

I'll admit I didn't think through the implications completely before, but I still think the principle is sound. One sticking point is that ArgyllCMS only generates 256-value tables, but there's no reason it couldn't use some higher order interpolation to output a 4096-value one. I think it uses some B-spline-based interpolation internally to smooth the calibration a little before using it - perhaps a cubic spline interpolation with a monotonicity constraint* would be best for the final output.

* while minimizing the 2nd order discontinuity

[Shiandow]

Right, so for a 6-bit+FRC monitor an 8-bit table would make a difference in 6-bit mode, and for an 8-bit monitor you'd need something bigger. As a proof of concept you could test with an 8-bit table in 3-bit mode, just so long as you scale up for actual viewing.

How exactly are you going to create a larger than 8-bit LUT if your display is only capable of displaying 8-bits? Which values will you measure to identify the points inbetween? The same for a 6-bit monitor, how do you define what the gamma curve should look like at values where you can't measure it? The best method I can think of is to calculate the local gamma and use that to create an interpolation.

[Ver Greeneyes]

How exactly are you going to create a larger than 8-bit LUT if your display is only capable of displaying 8-bits? Which values will you measure to identify the points inbetween? The same for a 6-bit monitor, how do you define what the gamma curve should look like at values where you can't measure it? The best method I can think of is to calculate the local gamma and use that to create an interpolation.Just use the table given by dispcal and interpolate between the values (this would be easiest in dispcal itself, since it also knows what the target gamma curve was, including any viewing conditions transformation). As long as the values given by dispcal are monotonic it shouldn't be hard.

[e-t172]

So I got frame drop/presentation glitches issues when using madVR with a 780 Ti. To be fair it's almost perfect but I still get at least one frame drop or other discontinuity every 10 minutes or so (it seems to happen at random times). I tried every combination of flushing settings/queue depths/use separate device for presentation/disable composition imaginable (well, almost) without any success. I'm out of ideas and asking for help.

Try to check if your card operates within the normal range with tools like MSI-Afterburner.

Tried that, nothing seems out of the ordinary. I tried putting the GPU in high performance mode (in the NVidia per-program power management settings) and setting the Windows power options to performance mode as well, no luck.

Personally, I would try the 327.23 drivers first

AFAIK 327.23 doesn't support the 780 Ti, it's too old.

madshi: are you interested in a log for this issue? I'm all out of ideas here. Even the old rendering path has the exact same issue on my system.

[Shiandow]

Just use the table given by dispcal and interpolate between the values (this would be easiest in dispcal itself, since it also knows what the target gamma curve was, including any viewing conditions transformation). As long as the values given by dispcal are monotonic it shouldn't be hard.

I agree with that method, but a linear interpolation won't be enough. I saw you suggested some other methods in your previous comment, those should probably be better. Basically what I was trying to say is that it might be a good idea to do this interpolation in log-log space, the main reason I think so is that the Rec. 709 and sRGB gamma curve are largely linear in log-log space, this should make interpolation easier.

[XMonarchY]

|- gamma (http://madshi.net/avatar2bitGamma.png) -|- original (http://madshi.net/avatar8bit.png) -|- linear (pure power 1/0.45) (http://madshi.net/avatar2bitLinear.png) -|- linear (sRGB 2.4) (http://madshi.net/avatar2bitSRGB.png) -|- linear (BT.709 1/0.45) (http://madshi.net/avatar2bit709.png) -|

Again, make sure you watch these at 100%. Having your browser zoom these will totally screw up everything.

The key point to take from this screenshot comparison is that dithering in gamma light is not correct. I hope everybody can agree with that now? Which image looks best to you will directly depend on how your display is calibrated. The image created with the transfer function nearest to your display calibration should look nearest to the original 8bit image to your eyes.

My TV is calibrated to Rec709/sRGB with BT.1886 gamma curve using ArgyllCMS LUT. The best image that mimics the original is the Linear BT.709 and the next best one is Gamma. Others are too dark. I know Graeme firmly considers BT.1886 gamma to be THE gamma to use, but I am not sure how it relates to dithering gamma...

[James Freeman]

As we can see, people voted for every single one of the screenshots as looking closest to their monitor gamma.
The question remains, how will madshi solve these differences in preferred transfer function and make everybody happy (again)?

Time shows madshi does not disappoint satisfying our videophile needs (or the differences between them).

[XMonarchY]

As we can see, people voted for every single one of the screenshots as looking closest to their monitor gamma.
The question remains, how will madshi solve these differences in preferred transfer function and make everybody happy (again)?

Time shows madshi does not disappoint satisfying our videophile needs.

Why can't dithering use same exact transfer function as the video? Is it because we do not know the exact gamma tone that was used for whatever content mastering? Isn't there a linear gamma default of some kind?

[nevcairiel]

The question remains, how will madshi solve these differences in preferred transfer function and make everybody happy (again)?

IMHO people need to stop judging too much at low bitdepth.
At 8-bit, any of the linear ones will probably solve the issue that Gamma presents, since the effect is miniscule there.

[James Freeman]

Why can't dithering use same exact transfer function as the video? Is it because we do not know the exact gamma tone that was used for whatever content mastering? Isn't there a linear gamma default of some kind?

As strange as it sounds, its because of your display device unique gamma curve and not the video content gamma curve, one user selects one picture and the other user selects another.

IMHO people need to stop judging too much at low bitdepth.
At 8-bit, any of the linear ones will probably solve the issue that Gamma presents, since the effect is miniscule there.
True, but...
We could have said the same when we tested dithering, but then we would not get to where we are now.
Probable we would have been satisfied by one of the first Direct Compute builds.

Let me post a small phrase from the Audiophile/Videophile book (which I just made up):
"Hearing or Seeing means nothing, Its KNOWING* that really counts..."
*Can easily be transferred from person to person by (a relatively weak) subconscious suggestion.
:D

Actually, it does not matter.
IMO madVR goal is to make the best picture quality whether less observant (or could not care less) user sees it or not.
Its not about "good enough", its about "The best of the best" which madVR currently holds the medal for.

[MistahBonzai]

Thanks! Out of these, sRGB preserves the most detail but also brightens the source somewhat. 709 is most correct in terms of hue, saturation and brightness, but still looks noticeably darker than the original near black. Unfortunately I don't have an easy way of looking at the images from far away while still switching between them quickly, so I had to make do with flipping back and forth between the original and the bit-reduced images from fairly up close. Both sRGB and 709 are pretty close to the original for me, which matches my somewhat hybrid calibration (Rec.709 adjusted for sRGB viewing conditions).

I should note that I viewed these in my browser (Firefox) with my Rec.709-focused ICC profile active (gfx.color_management.mode = 1) and 1D curves loaded into my videoLUT.

Belated input here... Having an apparently similar 'monitor calibration' I viewed the images much as you did if I expanded them in the Chrome browser by pressing the little "+". Otherwise they appeared much like the others who said that "avatar2bitgamma" was closest - if fact it was almost an exact match between it and the original 8 bit image (excluding dither of course).

So.. Having never considered browser color management in the many years ago I discovered it was a crap shoot - I always DL to perform image evaluations - I figured the time had come to take another look. Like you I selected gfx.color_management.mode = 1 in the latest Firefox (Aurora 29.0.a2) along with defining my CalibratedMonitorProfile.icc profile as default.

While cross checking between Chrome and Aurora using the test files I could see no determinable difference. Nor between them and a local copy displayed via Picasa Image Viewer. If I'm wrong I'm consistently wrong :)

[cyberbeing]

AFAIK 327.23 doesn't support the 780 Ti, it's too old.

If you want to use OpenCL try the following driver with the modded inf I created. Q-the-STORM who also has a GTX 780 Ti had success installing it with the modified inf on Win7 x64:

Quadro 321.10 (December 17, 2013) (http://www.nvidia.co.uk/download/driverResults.aspx/71564/en-uk) + Modifed Inf for GTX 780 Ti (https://www.mediafire.com/?vrbwgb4wo4m9rao)
I can confirm it works with madVR OpenCL.

[markanini]

Am I the only one that thinks perceived the tone response is downright atrocious with gamma in the avatar comparison?

[Asmodian]

A 12-bit table (3x4096) would cover the smallest differences that humans can discern, but that might have a bigger impact on performance (I don't know). 11-bit seems to be the limit of what madVR's dithering can do as far as calibration is concerned.

I bet a 12-bit table (3x4096) would have a rather negative effect on performance seeing as it would be 8 GB. :p


Does anyone see shadows that are too dark with linear light dithering in 8 bit? I assume no one noticed too light of shadows in 8 bit with gamma dithering? I know I didn't.

If we cannot notice the difference between the two extremes in 8 bit wouldn't any of the linear light dither options, being mathematically more correct, be fine for normal use? :o

Best of the best can be taken too far...

linear (pure power 1/0.45) looks the best to me, or maybe sRGB.

[Anime Viewer]

Just want to double check, in MPC under LAV video decoder, what's a good hardware decoder to use? Is it none?


Here is a strong argument for the None choice.

https://forums.geforce.com/default/topic/527075/geforce-drivers/hardware-acceleration-decoding-issue/1/

Run it with each of the different settings you can choose for LAV hardware acceleration. Changes are you'll experience pixelation (but not dropped frames) when you run the video clip there (http://www.sendspace.com/file/vl06bq) with any of the hardware acceleration options selected, but not have the issue if you choose none.

Granted just because DVX2 may cause pixelation in LAV doesn't mean you couldn't use it as an upscaling or downscaling in madVR. As you'll see if you use it in any of the madVR settings, and play the same video clip it shouldn't pixelate.

[Ver Greeneyes]

I bet a 12-bit table (3x4096) would have a rather negative effect on performance seeing as it would be 8 GB. :pI'm just talking about 3 1D curves, not a 4096^3 3DLUT :P Inverting the whole 3DLUT and increasing its resolution would be pretty insane ;)

[leeperry]

IMHO people need to stop judging too much at low bitdepth.
At 8-bit, any of the linear ones will probably solve the issue that Gamma presents, since the effect is miniscule there.
I like to nitpick as much as the next guy but I just watched "Out of the Furnace" on BD and PQ was outstanding with mono-static A4...and God forbid, that was in GL :p

[Asmodian]

I strongly encourage you to consider an option for loading a GPU gamma ramp with madVR via shaders for Windowed & FSE mode as well:

[X]Disable GPU Gamma Ramp Globally
....[X]Reload GPU Gamma Ramp via Shaders

I do get slightly better results even within 16-235 using collink "-H" and running madVR in overlay mode compared to using "-a" in FSE or overlay. I do use -r256 in collink as well. I notice better white and black points, especially when using "-a", with -r256 but it takes a long time. :p

I'm just talking about 3 1D curves, not a 4096^3 3DLUT :P Inverting the whole 3DLUT and increasing its resolution would be pretty insane ;)

madVR already uses 16 bit 1D LUTs, only need to invert them. :)

That might be overkill for 8-bit but then everyone with a good calibration could watch in 4-bit without noticing if they were not close to the screen. ;)

[Ver Greeneyes]

madVR already uses 16 bit 1D LUTs, only need to invert them. :)That's pretty much what I'm suggesting. The problem is that as discussed, you'd need more than 256 entries for it to have an effect (so you need to apply some sort of interpolation to generate more points), and you'd have to apply the calibration's target curve on top of them to get linear RGB. And then madVR still needs to actually use it during dithering. Since madshi doesn't want to implement something complicated like that for very little gain (and I don't blame him), and since he mentioned the possibility of loading shaders directly into madVR before, I was suggesting that he could allow a custom shader to override the transfer function used during dithering.

[iSunrise]

I like to nitpick as much as the next guy but I just watched "Out of the Furnace" on BD and PQ was outstanding with mono-static A4...and God forbid, that was in GL :p
Just asking, but how is that post even helpful when all you did was watch the movie at 8bit gamma light, when you didn't compare it with linear light? At least provide us with something we can work with.

Which one is gamma and which one is linear (both at 8bit):

http://abload.de/thumb/a5rqe4.png (http://abload.de/image.php?img=a5rqe4.png)http://abload.de/thumb/bofr1f.png (http://abload.de/image.php?img=bofr1f.png)

Which one looks closer to the previous ones:

http://abload.de/thumb/abd2pa7.png (http://abload.de/image.php?img=abd2pa7.png)http://abload.de/thumb/ba85orw.png (http://abload.de/image.php?img=ba85orw.png)

It doesn´t matter if you inspect the pixels themselves or look at it from a distance, there are very obvious differences.

My TV is calibrated to Rec709/sRGB with BT.1886 gamma curve using ArgyllCMS LUT. The best image that mimics the original is the Linear BT.709 and the next best one is Gamma. Others are too dark. I know Graeme firmly considers BT.1886 gamma to be THE gamma to use, but I am not sure how it relates to dithering gamma...
Yes, same thing I´m seeing here (when I´m on Rec709). So it seems for BT.1886/709 the "linear BT.709" is the only really useful option, whereas for sRGB displays, it´s the sRGB curve (it would be interesting to see 2.2 gamma on sRGB, too, though).

The "gamma" example is way too bright, whereas the "linear" example is a bit too dark. If I switch to sRGB, though, the linear is more accurate, while the gamma one still retains the elevated (brighter) look.

[Asmodian]

The problem is that as discussed, you'd need more than 256 entries for it to have an effect (so you need to apply sort of interpolation to generate more points)

Ah sorry, I understand. I think I missed a page. :o

[James Freeman]

....whereas for sRGB displays, it´s the sRGB curve (it would be interesting to see 2.2 gamma on sRGB, too, though).

The "gamma" example is way too bright, whereas the "linear" example is a bit too dark. If I switch to sRGB, though, the linear is more accurate, while the gamma one still retains the elevated (brighter) look.

I'm doing the tests in 3/4 bit to see the difference clearer.

On my display:
Linear Power 2.2 is too dark.
Linear sRGB 2.4 is almost there, but very little too dark.
Linear BT.709 is a little too bright.
Gamma is nothing like the original image, very bright.

So my display falls somewhere between sRGB 2.4 & BT.709.
I think sRGB 2.2 might be it for my display.

I experimented with the Gamma slider in Nvidia Control Panel and managed to make my display match (+/-) the Linear Power 2.2 and sRGB 2.4 images madshi posted.
I use a 3DLUT in madVR calibrated to power 2.2, so the gamma curve will be perfect 2.2 there.
I do not load VideoLUT curves (or include them in the 3DLUT) because they create banding, even in madVR when GPU gamma ramp is disabled.
I just "Profile" the monitor (w/ 128 Neutral patches) without "Calibrating" and create a 3DLUT (2.2 Relative), this gives me a 2.2 curve with no banding what so ever.

[leeperry]

all you did was watch the movie at 8bit gamma light, when you didn't compare it with linear light
LL looks terribly dull on my rig, maybe the internal post-processing of my TV isn't compatible for some reason. My point is that as nev said, you guys seem to focus a tad too much on low bit-depths and LL isn't quite a magic bullet to everyone.