madVR - high quality video renderer (GPU assisted)

[iSunrise]

madshi, I wanted to do some further testing with some TIF images (8bit/16bit per component), but I only get a black screen when loading them into madVR. LAV doesn´t seem to be the problem, because the file is being loaded and LAV also shows the file properties correctly, but the picture just stays black no matter what I do (disabled smooth motion to be sure).

Can I solve this somehow?

Here are two examples (first one 8bit, second one 16bit):
http://www.mediafire.com/download/6n7ji6q9f2hi2jp/BrightnessCal.rar
http://www.mediafire.com/download/9sbb5terv272meo/ColourRamp-1.rar

[sajara]

The "gamma light" image looks a lot closer to the "source 16-bit" image to me.
Linear light dither also has obvious banding, similar in width to each band in the "no dither" image.

I absolutely second this observation. GL is more smooth in 2 screens i tested. i can see quite obvious grey steps in LL which are attenuated and almost imperceptible in GL.

[Asmodian]

The 16-bit source is a tiny bit brighter becouse i had to process it in another program(krita) that had support for >16-bit images and prosessing.
Kritas level controls did behave a bit strange.

Dithering in linear light gives a more accurate image to the source.

I prefer LL over GL dithering and I do not think these test images can be used to decide given the above.

[Shiandow]

I prefer LL over GL dithering and I do not think these test images can be used to decide given the above.

Actually, I tried to reconstruct what bacondither did but with the brightening performed in linear light, as far as I can tell this makes GL perform better (less banding, more accurate). I'll post some images in the near future, I still need to make sure that I haven't made any silly mistakes.

[Ver Greeneyes]

I did the same thing bacondither did but with device RGB spacing, and generating an expanded version of the original myself (it's my program, after all). There's no trickyness going on here: every image is expanded from 0-6 to 0-255, except the expanded original which I generated. Let me know if this helps clear up the difference between GL and LL.

no dithering (http://i.imgur.com/lETYKN7.png)
random dithering (http://i.imgur.com/VT87V6N.png)
gamma light error diffusion (http://i.imgur.com/R5U7GDi.png)
linear light error diffusion (http://i.imgur.com/FklCLlu.png)
expanded original (http://i.imgur.com/IKqikuL.png)

(I think it shows that Gamma Light is more true to the source. How is the Linear Light conversion being done?)

[sajara]

madshi, I wanted to do some further testing with some TIF images (8bit/16bit per component), but I only get a black screen when loading them into madVR. LAV doesn´t seem to be the problem, because the file is being loaded and LAV also shows the file properties correctly, but the picture just stays black no matter what I do (disabled smooth motion to be sure).

Can I solve this somehow?

Here are two examples (first one 8bit, second one 16bit):
http://www.mediafire.com/download/6n7ji6q9f2hi2jp/BrightnessCal.rar
http://www.mediafire.com/download/9sbb5terv272meo/ColourRamp-1.rar

opens here without problems



(I think it shows that Gamma Light is more true to the source. How is the Linear Light conversion being done?)

Indeed it is. I also see that. Thanks for the original image.

[iSunrise]

I did the same thing bacondither did but with device RGB spacing, and generating an expanded version of the original myself (it's my program, after all). There's no trickyness going on here: every image is expanded from 0-6 to 0-255, except the expanded original which I generated. Let me know if this helps clear up the difference between GL and LL.

no dithering (http://i.imgur.com/lETYKN7.png)
random dithering (http://i.imgur.com/VT87V6N.png)
gamma light error diffusion (http://i.imgur.com/R5U7GDi.png)
linear light error diffusion (http://i.imgur.com/FklCLlu.png)
expanded original (http://i.imgur.com/IKqikuL.png)

(I think it shows that Gamma Light is more true to the source. How is the Linear Light conversion being done?)
I´m not sure how you come to that conclusion based on these examples.

If you compare your expanded original with the dark grays/blacks at the top left or bottom right edge of the gamma light example, it brightens the dark grays/blacks up quite a lot, while linear light has an extremely smooth transition down to black and finally reference black that closely resembles that of your expanded original.

Why would we suddenly accept something that brightens up all the important blacks by such a considerable amount? Black isn´t like the black in your original anymore, it´s a block of gray. This would seriously hurt dark movies or dark scenes.

Also, when you look closely, with gamma light I can see big repeating blocks of gray levels, while with linear light this is barely visible. The transitions themselves are way smoother with linear light.

This perfectly resembles bacondither´s findings, indeed. Because in his examples I also prefered linear light for both of these reasons.

Other than that though, for some reason the gamma light build gives the impression of a more dynamic and vibrant picture, sharper edges and it seems to be a bit better in terms of detail.

Quite frustrating, really. Because when looking at still pictures like that, linear light wins (IMHO), but when pictures start to move, that´s when our eyes seem to like gamma light more.

opens here without problems
Thanks.

[Ver Greeneyes]

If you compare your expanded original with the dark grays/blacks at the top left or bottom right edge of the gamma light example, it brightens the dark grays/blacks up quite a lot, while linear light has an extremely smooth transition down to black and finally reference black that closely resembles that of your expanded original.

Why would we suddenly accept something that brightens up all the important blacks by such a considerable amount? Black isn´t like the black in your original anymore, it´s a block of gray. This would seriously hurt dark movies or dark scenes.I don't see this at all on my calibrated monitor. Both the expanded original and Gamma Light only go to black right near the end (matching a power law of x^(1/2.2), more or less), whereas Linear Light goes to black much sooner. It would be nicer to have a perceptual sample and perceptually expand everything so the transition isn't so sudden, but this will take a bit more work.

Also, when you look closely, with gamma light I can see big repeating blocks of gray levels, while with linear light this is barely visible. The transitions themselves are way smoother with linear light.I see them pretty clearly for both Gamma Light and Linear Light - but for the latter they stand out more near black, so I think Gamma Light looks smoother.

[iSunrise]

I don't see this at all on my calibrated monitor. Both the expanded original and Gamma Light only go to black right near the end (matching a power law of x^(1/2.2), more or less), whereas Linear Light goes to black much sooner. It would be nicer to have a perceptual sample and perceptually expand everything so the transition isn't so sudden, but this will take a bit more work.

I see them pretty clearly for both Gamma Light and Linear Light - but for the latter they stand out more near black, so I think Gamma Light looks smoother.
Argh, I actually forgot to switch modes on my hardware calibrated monitor to a pure power gamma of 2.20 when I do these picture comparisons. That includes my last answer to bacondither, so everyone please ignore these posts. Sorry about that. You totally reminded me of that when you wrote that you also are on a pure power curve of 2.20.

Yes, you are perfectly right, gamma light is indeed more representative of the expanded original, because only the outer edge is indeed pure black.

At least for me, I think this is settled now, because I also strongly prefered gamma light when watching actual movies, anyway. My confusion suddenly has left the building. Hurray!

@madshi:
Just stumbled over a possible bug by accident. When I enable DCI-P3 calibration in the settings, I get this:
http://abload.de/thumb/dci-p3_green_picture22kt4.png (http://abload.de/image.php?img=dci-p3_green_picture22kt4.png)

Going to bed now, way too late. :)

[cyberbeing]

I would much rather the algorithm be chosen based on objective tests for distortion/accuracy

I would as well, but madshi never set any such guidelines for testing such things. With it being a majority vote, the algorithm with the most preferred subjective appearance was always destined to win.

Nitpicking about grossly magnified and overexposed static screenshots is one thing but at the end of the day what matters is the subjective impression from a distance.
And this is why I decided to just take a step back and just watch from a distance which conclusions people came to through their own subjective testing. Here and there I'd give little tidbits from my objective tests to encourage closer examination in various regards, but that's about it. The irony is that way back in the beginning of testing, leeperry was strongly in favor of ED5 (floyd-stein, weight sum 1.00, old random generator), while at the end my top two favorites of NL5 (floyd-stein, 0.97, old random generator, bugfixes) & NL3 (floyd-stein, weight sum 1.00, old random generator, bugfixes) were probably closest to his initial preference. We both switched algorithms starting with the second build set.


Modified the shader code a bit, but image output should be bit by bit identical to NL6.

Ah, in any case my testing on the linear and gamma builds was rather non-conclusive.

linear light error diffusion (http://i.imgur.com/FklCLlu.png)

That image Ver Greeneyes posted of the linear light build expansion from 0-6 to 0-255 is rather concerning though, since there are 6 very distinct bands with multiple pixel wide noiseless areas on their borders. On the gamma light build there were also some much less distinct bands in the same areas that were slightly visible, but the transition between them was much smoother with smaller level jumps per pixel.


@madshi:
Just stumbled over a possible bug by accident. When I enable DCI-P3 calibration in the settings
I have a similar bug-report regarding DCI-P3 and 3DLUTs here (http://bugs.madshi.net/view.php?id=145).

[6233638]

I would as well, but madshi never set any such guidelines for testing such things. With it being a majority vote, the algorithm with the most preferred subjective appearance was always destined to win.Which I think is a bad thing when you consider that there are factors which could make the image look subjectively better, that could actually be caused by worse dithering performance. (e.g. masking flaws in the source by adding unnecessary noise)

That image Ver Greeneyes posted of the linear light build expansion from 0-6 to 0-255 is rather concerning though, since there are 6 massive bands with multiple pixel wide noiseless areas on their borders.I wonder if it could be caused by this, which may be beneficial with random dither, but harmful with error diffusion?

madVR v0.87
* madVR doesn't dither, anymore, when a pixel doesn't need dithering

Edit: or possibly the limiter which restricts the range of values being used.
I notice that you essentially have a "background" of a middle gray tone, and on either side there is dither using lighter or darker values on top of it - but there is no crossing point that blends all three values.

There are also stray green/magenta pixels too, which seems odd.

[Ver Greeneyes]

That image Ver Greeneyes posted of the linear light build expansion from 0-6 to 0-255 is rather concerning though, since there are 6 massive bands with multiple pixel wide noiseless areas on their borders.These may just be areas where the 16-bit source happens to be an integer multiple of 1/255, so no dithering is needed. Considering the whole image only spans 7/256, it's possible we're reaching the limit of even 16-bit per channel encoding. In fact, because 65535 = 257*255, the set of 16-bit values contains all 256 8-bit values.

Edit: Here's another comparison, using a perceptual pattern and scaling the luma in a perceptually uniform space:
no dithering (http://i.imgur.com/RqryNzX.png) (luma only (http://i.imgur.com/qPP6u4N.png))
random dithering (http://i.imgur.com/A4he35J.png) (luma only (http://i.imgur.com/X9wpiMA.png))
error diffusion - gamma light (http://i.imgur.com/f6olAse.png) (luma only (http://i.imgur.com/6v7Tk7J.png))
error diffusion - linear light (http://i.imgur.com/FbkcKE5.png) (luma only (http://i.imgur.com/rfUvnxj.png))
expanded original (http://i.imgur.com/KAYnUrt.png) (luma only (http://i.imgur.com/uonzj6V.png))

I'm aware that the luma only images are a bit.. beige.. but I'm not sure what the right way is to deal with that is. Anyway, this comparison clearly shows that there's something wrong with linear light.

madshi, is it possible you're adding gamma instead of removing it? It turns out I was doing this with my perceptual test pattern due to a copy-paste mistake (I'll upload new versions soon), so I thought I'd ask :P

[6233638]

These may just be areas where the 16-bit source happens to be an integer multiple of 1/255, so no dithering is needed. Considering the whole image only spans 7/256, it's possible we're reaching the limit of even 16-bit per channel encoding. In fact, because 65535 = 257*255, the set of 16-bit values contains all 256 8-bit values.I think it may be a result of the change made in build 87 to disable dithering when a pixel doesn't need dithering - it happens with random dither too. I'd check with an older version, but every build prior to 87.x seems to be crashing immediately for me.

[Qaq]

Which I think is a bad thing when you consider that there are factors which could make the image look subjectively better, that could actually be caused by worse dithering performance. (e.g. masking flaws in the source by adding unnecessary noise)
More "analog", "tube-like"? I watched old Antarctica 1983 movie yesterday with GL and had these impressions. Pure speculations though, I haven't much time to spend on tests. Some digital sources look too *digital* and may benefit from *analog* filter, but not all of them i suspect.

[6233638]

More "analog", "tube-like"? I watched old Antarctica 1983 movie yesterday with GL and had these impressions. Pure speculations though, I haven't much time to spend on tests. Some digital sources look too *digital* and may benefit from *analog* filter, but not all of them i suspect.That's not the job of a dither algorithm.
But from my continued testing... I don't mind how NL6 looks. At least not when testing gradients - though I'm still not convinced it was the best choice.

[cyberbeing]

These may just be areas where the 16-bit source happens to be an integer multiple of 1/255, so no dithering is needed. Considering the whole image only spans 7/256, it's possible we're reaching the limit of even 16-bit per channel encoding. In fact, because 65535 = 257*255, the set of 16-bit values contains all 256 8-bit values.

Yet the linear light version had a rather huge error near-black in your images compared to the gamma light version.

Gamma Light difference vs Reference (http://i1.someimage.com/J1pyaTk.png) | Linear Light difference vs Reference (http://i1.someimage.com/IuuDJsm.png).

How did you generate these images with madVR? The only thing which could logically explain this, is if there was a mismatch somewhere between gamma light and linear light processing.

Anyway, this comparison clearly shows that there's something wrong with linear light.

I see your other comparison now, and it adds weight to my suspicion. I agree that something seems wrong with how linear light is being applied here. It's like madVR is forgetting to convert the video from gamma light to linear light, apply dithering, and then convert back from linear light to gamma light again. But who knows. If you are using shaders, maybe it's something like the 0-6 -> 0-255 expansion being performed in gamma light instead of linear light. :confused:

[Ver Greeneyes]

How did you generate these images with madVR? The only thing which could logically explain this, is if there was a mismatch somewhere between gamma light and linear light processing.I used a test pattern I made myself (updated version uploading now; I used frame 29), took screenshots, cropped them to just the video, saved them as BMP images, then fed those into another program to boost their brightness in a perceptually uniform way (unfortunately I'm not sure how to deal with the chroma properly). I did this with both the linear light and the gamma light build. I updated my earlier post with some more images by the way if you'd like to see a non-beige but very colorful version ;)

Edit: New test pattern is up if you want to try it yourself, link in my signature (the first one).

If you are using shaders, maybe it's something like the 0-6 -> 0-255 expansion being performed in gamma light instead of linear light. :confused:
I'm not using shaders, no, I'm directly modifying the data using C++ code. The first comparison I made (http://forum.doom9.org/showthread.php?p=1668251#post1668251) did use straight up 0-6 -> 0-255 without any gamma processing, but the difference was fairly obvious even there.

[Qaq]

That's not the job of a dither algorithm.Right. Just like "pop effect", "opened window" or "3D look".
I don't mind how NL6 looks. At least not when testing gradients - though I'm still not convinced it was the best choice.There could be no best choice at all, at least for a very different sources. But it's hard to tell in short time testing, thats why I didn't even try it. Whatever we expect, dither algorithm may act like an image filter - thats my exact point.

[cyberbeing]

@Ver Greeneyes

I see the test pattern now, though I still don't understand exactly what you are doing to produce those results.

When I take a screenshot of frame 29 of gradient-perceptual-v2.mkv, then expand from 0-6->0-255 I end up with the following results:

madVR Gamma Dither (http://i1.someimage.com/Nu17f2F.png) | madVR Linear Dither (http://i1.someimage.com/P97fBF6.png)

[ryrynz]

That's not the job of a dither algorithm.
But from my continued testing... I don't mind how NL6 looks. At least not when testing gradients - though I'm still not convinced it was the best choice.

I'm interested in seeing images showing NL5/4 or what ever doing a better job than NL6. I'm for accuracy and tidyness first and foremost, Leeperry could take that with a touch of grain. XD

[bacondither]

I did the same thing bacondither did but with device RGB spacing, and generating an expanded version of the original myself (it's my program, after all). There's no trickyness going on here: every image is expanded from 0-6 to 0-255, except the expanded original which I generated. Let me know if this helps clear up the difference between GL and LL.

no dithering (http://i.imgur.com/lETYKN7.png)
random dithering (http://i.imgur.com/VT87V6N.png)
gamma light error diffusion (http://i.imgur.com/R5U7GDi.png)
linear light error diffusion (http://i.imgur.com/FklCLlu.png)
expanded original (http://i.imgur.com/IKqikuL.png)

(I think it shows that Gamma Light is more true to the source. How is the Linear Light conversion being done?)

I took you images and did a gaussian blur in linear light(GIMP 2.9 32-bit float linear, radius 3.5) and then converted back to 8-bit gamma light.

Doing gauss blur i gamma light is worng and i am guilty of doing it before.

The results:

SOURCE (http://i.imgur.com/RvYKDhz.png)

GAMMA light (http://i.imgur.com/YDDK1xM.png)

LINEAR light (http://i.imgur.com/DVANpuo.png)

Then a ran tests on the blurred results in matlab:

PSNR, higher is better!
out = psnr(GAMMA,SOURCE)

out =

38.1919

out = psnr(LINEAR,SOURCE)

out =

42.4802

Linear light is closer to the source image. It looks like gamma is being overcompensated a bit to much when converting to linear light.(slightly darker around black)

[James Freeman]

I'll share my unprofessional objective opinion.

Both of them do not look like the source.
One is too dark, the other is too bright.

In all of the tests you guys posted.

[madshi]

What stat do you want us to report? Average stats - rendering and present ms?

during a video opening scene
gamma version
6.28 ms (rendering)
1.53 ms (present)

linear version
6.44 ms (rendering)
1.51 ms (present)

when the show actually started the numbers increased a little:
gamma version
6.86 ms
1.53 ms

linear version
6.98 ms
1.50 ms

With such a small difference I don't care which way you go. Which ever produces better quality would be what I vote for in this case.
Interesting that for you linear is slower than gamma, while it's the other way around for some other users. Anyway, you're right, the drop in your measurements isn't worth worrying about.

Sorry for the tangent, but I have a quick update on my troubleshooting with Directcompute dithering.

Given that my laptop uses two GPUs, I decided to try what would happen if I disabled the intel 4000 HD.

Well, turns out madvr will try to run in software mode or something, as simple playback of 8 bit content without scaling slows down to a <1 fps slideshow. However, direct compute dithering now "works", in that it doesn't result in a black screen. I am still unsure if it's automatically ignoring directcompute settings in absence of GPU acceleration, or if I've somehow bypassed a bug in the drivers. I don't know why mpchc/madvr won't use my discreet gpu in the absence of the integrated one, but I did notice that madvr is displaying through an "unknown generic monitor" with an orange icon rather than the generic monitor that indicates my laptop screen.

This leads me to believe that there is likely something wrong in the 13.12 catalyst drivers or the OEM intel 4000 drivers I'm using. Updating the 4000's drivers is tricky because every installer I have found refuses to install. I doubt the 13.12 drivers are the culprit, since virtually no one else has my problem.
Not sure what I can say. madVR searches for Direct3D devices that are connected to the monitor on which the rendering window is positioned, and then uses those for pixel shader and also for DirectCompute processing. It seems that Direct3D doesn't work properly in your configuration when you disable the HD4000. I'm not sure why. That's outside of my control.

Just stumbled over a possible bug by accident. When I enable DCI-P3 calibration in the settings, I get this
I don't have the time to look into that atm. Can you create a bug report for this in the bug tracker, with a description how to reproduce the problem? Thanks.

I would as well, but madshi never set any such guidelines for testing such things. With it being a majority vote, the algorithm with the most preferred subjective appearance was always destined to win.
I didn't set guidelines because both approaches (doing scientific analyzation and just trusting your eyes) have their merit. I've often found that trusting your eyes can sometimes be the best instrument. But I also find scientific analyzation very important. So I'm not biased either way. Personally, I didn't care too much which algorithm won because I personally thought they were all reasonably close. So I just wanted a decision, and the "easiest" and fairest way to make a decision is a simple vote. Of course a vote comes with certain dangers, but in the end, a decision had to be made, and without a vote I would have had to choose myself which of the two approaches is the right one. And I didn't want to make that decision because I don't know which is the right approach in this case.

I did make several blind tests, though, to make sure that people using either approach were consistent in their choices. And they were. So it seems to me both approaches do have their merit in this case.

I notice that you essentially have a "background" of a middle gray tone, and on either side there is dither using lighter or darker values on top of it - but there is no crossing point that blends all three values.
Are we talking about random dithering or error diffusion? I'm asking because the changelog entry you're quoting only applies to random dithering.

In my opinion it is most likely that something, somewhere has gone wrong. Unless I made a serious mistake in my reasoning somewhere the linear light build should be brighter for values near black.

The only way I can explain that linear light makes the dark regions brighter is if the linear gamma build used a gamma lower than 1, and I'm pretty sure this would have been noticeable.
I'm aware that the luma only images are a bit.. beige.. but I'm not sure what the right way is to deal with that is. Anyway, this comparison clearly shows that there's something wrong with linear light.

madshi, is it possible you're adding gamma instead of removing it? It turns out I was doing this with my perceptual test pattern due to a copy-paste mistake (I'll upload new versions soon), so I thought I'd ask :P
Well, I think my code is alright, but have a look yourself:

gamma light:
float3 calcPixelGamma(float3 gammaPixel, float3 collectedError, float randomValue, out float3 newError)
{
float3 tempPixel = gammaPixel * 255.0f;
float3 floorG = floor(tempPixel) / 255.0f;
float3 ceilG = ceil (tempPixel) / 255.0f;
float3 result = (gammaPixel + randomValue + collectedError < 0.5 * (floorG + ceilG)) ? floorG : ceilG;
newError = gammaPixel + collectedError - result;
return result;
}

linear light:
float3 convertToLinear(float3 gammaValue)
{
return pow(saturate(gammaValue), 1.0 / 0.45);
}

float3 calcPixelLinear(float3 gammaPixel, float3 collectedError, float randomValue, out float3 newError)
{
float3 tempPixel = gammaPixel * 255.0f;
float3 floorG = floor(tempPixel) / 255.0f;
float3 ceilG = ceil (tempPixel) / 255.0f;
float3 floorL = convertToLinear(floorG);
float3 ceilL = convertToLinear( ceilG);
bool3 useFloor = convertToLinear(gammaPixel + randomValue) + collectedError < 0.5 * (floorL + ceilL);
newError = clamp(convertToLinear(gammaPixel) + collectedError, floorL, ceilL) - ((useFloor) ? floorL : ceilL);
return (useFloor) ? floorG : ceilG;
}
One thing I'm not happy about is the clamp() call. I think it could potentially introduce a small error into the math. However, it was necessary to make the limiter work. Without the clamp() call the limiter produced artifacts in linear light. Of course I could remove both the limiter and the clamp() call, but then we would reintroduce some rare stray dots.

[bacondither]

@madshi
Could you try a gamma compensation value of 1/2.0=0.5
return pow(saturate(gammaValue), 1.0 / 0.5);
It should compensate for the lowered brightness around black.(or mabe i´m thinking backwards?)

OECF standards
ITU-R Rec. BT.709, Parameter values
for the HDTV standard for the studio
and for international programme
exchange (Geneva: ITU).
BT.709 standardizes a reference camera transfer function (OECF),
graphed in Figure 3. BT.709’s encoding equation incorporates a power
function exponent of 0.45 – what I call the “advertised” gamma.
However, BT.709’s equation incorporates a linear segment near black;
the power function portion is scaled and offset to achieve function
and slope continuity at the breakpoint (which lies at about 2% rela-tive luminance). The scaling and offseting cause the effective expo-
nent to be higher than the exponent “advertised” in the equation. If
BT.709’s curve is approximated as a single pure power function, the
best exponent is about 0.5: BT.709’s encoding is effectively a square
root.

[cyberbeing]

Well, I think my code is alright, but have a look yourself

How does this differ from the gamma->linear->gamma conversion you do for linear light scaling which has a large performance impact?

[Aikibana]

Can't figure out why my system can't handle NNEDI3.

System:
AMD HD 7770 (1GB GDDR5)
Intel i5-750 - 16GB RAM
Win 7 64
Madvr (0.87.4) + MP-HC (latest nightly build) including LAV
Catalyst 14.1
I play mostly high quality videos (720p/1080p) via extended desktop on a 55 inch plasma.

Only NNEDI3 up to 32 neurons for Chroma upscaling works, anything higher then that eats up all GPU power and results in dropped frames.

Image doubling is just impossible, even just for Luma at 16 neurons. I get massive dropped frames and the video stutters heavily.

I've tried some trade-offs (using random dithering, Lanczos or Bicubic 50 for up- and downscaling), but it doesn't resolve anything.

GPU-Z says OpenCL is fully operational and anything but NNEDI3 works just fine (Jinc3/4, new debanding feature, no trade-offs).

I've read Madshi can pull of NNEDI3 and many of you seem to have no problems testing all different builds, so I'm just wondering if it's a software setting or something really obvious I've missed...

Any help would be greatly appreciated!

[noee]

Can't figure out why my system can't handle NNEDI3.

Go back to latest stable, 13.12. I've had some problems with the 14.1 beta as well, not worth struggling with right now. 14.2 is coming soon anyway, you could try again with that later.

[cyberbeing]

float3 convertToLinear(float3 gammaValue)
{
return pow(saturate(gammaValue), 1.0 / 0.45);
}

Also isn't that reversed?

If you are converting from 2.2 Gamma to 1.0 Linear shouldn't it be something like the following:

float3 convertToLinear(float3 gammaValue)
{
return pow(saturate(gammaValue), 1.0 / 2.2);
}


I know if I make an MPC-HC shader like the following, madVR will convert the gamma from 2.2 -> 1.0 gamma:
sampler s0;

float4 main(float2 tex : TEXCOORD0) : COLOR
{
return pow(tex2D(s0, tex), 1.0 / 2.2);
}


Yet if I make an MPC-HC shader like the following, madVR will convert the gamma from 2.2 -> 4.88 gamma (or 1.0 -> 2.2):
sampler s0;

float4 main(float2 tex : TEXCOORD0) : COLOR
{
return pow(tex2D(s0, tex), 1.0 / 0.45);
}

[Aikibana]

Go back to latest stable, 13.12. I've had some problems with the 14.1 beta as well, not worth struggling with right now. 14.2 is coming soon anyway, you could try again with that later.

Actually, I just updated to 14.1 beta because 13.12 didn't work either enabling smooth NNEDI3-playback. For me 14.1 works 'as good/bad' as version 13.12.

Also tried overclocking my 7770 Gh edition, but doesn't change much and makes my system unstable.

From what I understood, a recent AMD GPU shouldn't have too much troubles with OpenCL and NNEDI3, right?

[mithra66]

Sorry if I misinterprate the code but shouldn't LL value be calculated from Gamma settings (i.e. fields "The display is calibrated to the following transfer function / gamma" and/or "desired display gamma/transfer function".

Unless this does not make much difference with 2.2 gamma?

[leeperry]

leeperry was strongly in favor of ED5 (floyd-stein, weight sum 1.00, old random generator), while at the end my top two favorites of NL5 (floyd-stein, 0.97, old random generator, bugfixes) & NL3 (floyd-stein, weight sum 1.00, old random generator, bugfixes) were probably closest to his initial preference. We both switched algorithms starting with the second build set.
There's no irony whatsoever tbh, I prefered ED5 to ED7 because the latter looked fuzzy. I was well aware that it looked more "popping" and subjectively more impressive but it's only after madshi made the changes in N3 that things changed. I rest my case that N3 looks much clearer than ED7 and that NL6 looks even better.

I think Gamma Light looks smoother.
With Pioneer LX6090 display , gamma at 2.45, I vote for Gamma Light. Though I expected the opposite.

I don't know for sure if it's the most accurate, but I prefer its 3D effect, without the inconvenience of sharpening.

If LL wins the vote, I'd like GL to remain as some kind of "3D cool setting".

Anyway many thanks to Madshi -and all testers- to achieve this great work.

PS: DVD have never looked so nice thank to NNEDI3
Major +1 here, I would really hate being stuck with the current LL build.

And your DVD comment is interesting because I read a long time ago that Reclock could process inverse pal-speed up in realtime with DVB-T tuners and this would be a killer combo with NNEDI 64x, OMG :D

The only last problem is that I would need CUVID deinterlacing as its PQ would appear to be quite a bit better than YADIF on 576i/1080i :o

And yesterday I ran more tests with NNEDI on 720p@1080p, it seems rather clear that 64x for luma looks amazingly good....hard to believe it's not genuine 1080p.

I ran a quick search and couldn't find what NNEDI really does, even tritical doesn't explain....I wonder why and how this thing looks so good.

[bacondither]

Sorry if I misinterprate the code but shouldn't LL value be calculated from Gamma settings (i.e. fields "The display is calibrated to the following transfer function / gamma" and/or "desired display gamma/transfer function".

Unless this does not make much difference with 2.2 gamma?

Well no, to linearise image you should take the inverse of the gamma function that the image was recorded/made with.

//added

A better explanation then i would do i found here:
http://www.cambridgeincolour.com/tutorials/gamma-correction.htm

[cyberbeing]

There's no irony whatsoever tbh
Well that's a matter of perspective. If madshi had never introduced the new RNG, we could have ended up preferring the same build. :)

[leeperry]

Well that's a matter of perspective. If madshi had never introduced the new RNG, we could have ended up preferring the same build. :)
Hah, good point! But it was really too bad that ED7 suffered from that fuzzy look because everything else looked very impressive.

madshi's got more tricks than a clown's pocket so it's only a matter of time before we might very well agree again :D

See you when he gets there ;)

[The 8472]

BT.2020 supports 10bit+, but not 8bit, anymore, so yes, it appears we're going to get higher bitdepth. Hope the same will be true for 4K Blu-Ray, but at this point we can only guess, cause there's no information available yet about that.

UHD standards still seem to be in flux, i've even seen some slides talking about 300Hz 4:4:4 12bit video as potential future goals.

This image comes from some european broadcasting union/DVB meeting (may 2013):
http://i.imgur.com/L6ZaSO9.jpg

[mithra66]

Well no, to linearise image you should take the inverse of the gamma function that the image was recorded/made with.

A better explanation then i would do i found here:
http://www.cambridgeincolour.com/tutorials/gamma-correction.htm

I was confused because I thought LL was some kind of display gamma reverse where it it is about file gamma. So thanks you to correct my mistake.
Very interesting link by the way :helpful:


And your DVD comment is interesting because I read a long time ago that Reclock could process inverse pal-speed up in realtime with DVB-T tuners and this would be a killer combo with NNEDI 64x, OMG :D


Having a 650ti, I already have to put first NNEDI3 upscale in Avisynth filter for 30fps files. I think I'll wait for 20nm Maxwell GPU (supposedly gtx870 for my budget) for 64 neurons and 50/60 fps deinterlaced.

Actually, I just updated to 14.1 beta because 13.12 didn't work either enabling smooth NNEDI3-playback. For me 14.1 works 'as good/bad' as version 13.12.

Also tried overclocking my 7770 Gh edition, but doesn't change much and makes my system unstable.

From what I understood, a recent AMD GPU shouldn't have too much troubles with OpenCL and NNEDI3, right?

@Aikibana: nnedi3 is very GPU consuming. You may prior GPU power for luminance upscale and stick to jinc upscale or lower for chroma upscale. Using profiles, you can still do nnedi3 chroma upscale when no luma upscale is needed .

[DragonQ]

Hmm, why all the phases? It just means loads of equipment will be made that supports 2160p/50 and then no broadcaster will be able to move to 2160p/100 or higher because none of the equipment around will support it. They made the same mistake when not including 1080p/50 (and 1080p/60) in the HD standards.

[tschi]

Actually, I just updated to 14.1 beta because 13.12 didn't work either enabling smooth NNEDI3-playback. For me 14.1 works 'as good/bad' as version 13.12.

Also tried overclocking my 7770 Gh edition, but doesn't change much and makes my system unstable.

From what I understood, a recent AMD GPU shouldn't have too much troubles with OpenCL and NNEDI3, right?
I had same problem with gigabyte p55ud4 (i7 860- and R9 280x GFX
I tried clean win7 install and it was still KO with 13.12.
I tried nvidia gtx560ti gfx and no problem
I tried R9 280x on other motherboard (asus Z77 i7 3770k) and no problem :angry:
I guess there is some issues with AMD - p55 - openGL - 7xxx series.

[leeperry]

I've never had a single problem with OpenCL performance and a 1Ghz 7850 on W7SP1 using the latest WHQL drivers, maybe you guys could troubleshoot using that OpenCL benchmark (http://www.luxrender.net/wiki/LuxMark)?

You can see what kind of figures to expect at http://www.extremetech.com/computing/153467-amd-destroys-nvidia-bitcoin-mining/2

You did update DX9.0c, right? Not sure if it's needed on W8 but W7SP1 definitely needs it, it's available at http://www.microsoft.com/en-us/download/details.aspx?id=8109

Having a 650ti, I already have to put first NNEDI3 upscale in Avisynth filter for 30fps files. I think I'll wait for 20nm Maxwell GPU (supposedly gtx870 for my budget) for 64 neurons and 50/60 fps deinterlaced.
Yeah, hopefully someday nvidia with catch up with AMD for raw GPGPU performance as I'd very much fancy the ability to use CUVID deinterlacing again.

[Shiandow]

Well, I think my code is alright, but have a look yourself:

gamma light:
float3 calcPixelGamma(float3 gammaPixel, float3 collectedError, float randomValue, out float3 newError)
{
float3 tempPixel = gammaPixel * 255.0f;
float3 floorG = floor(tempPixel) / 255.0f;
float3 ceilG = ceil (tempPixel) / 255.0f;
float3 result = (gammaPixel + randomValue + collectedError < 0.5 * (floorG + ceilG)) ? floorG : ceilG;
newError = gammaPixel + collectedError - result;
return result;
}

linear light:
float3 convertToLinear(float3 gammaValue)
{
return pow(saturate(gammaValue), 1.0 / 0.45);
}

float3 calcPixelLinear(float3 gammaPixel, float3 collectedError, float randomValue, out float3 newError)
{
float3 tempPixel = gammaPixel * 255.0f;
float3 floorG = floor(tempPixel) / 255.0f;
float3 ceilG = ceil (tempPixel) / 255.0f;
float3 floorL = convertToLinear(floorG);
float3 ceilL = convertToLinear( ceilG);
bool3 useFloor = convertToLinear(gammaPixel + randomValue) + collectedError < 0.5 * (floorL + ceilL);
newError = clamp(convertToLinear(gammaPixel) + collectedError, floorL, ceilL) - ((useFloor) ? floorL : ceilL);
return (useFloor) ? floorG : ceilG;
}
One thing I'm not happy about is the clamp() call. I think it could potentially introduce a small error into the math. However, it was necessary to make the limiter work. Without the clamp() call the limiter produced artifacts in linear light. Of course I could remove both the limiter and the clamp() call, but then we would reintroduce some rare stray dots.

FWIW you are using a very different version of linear light then I was thinking about. It also thought that gammaLight used gamma correction, but that doesn't seem to be the case. I'm also not sure why the call to clamp is necessary, ideally it shouldn't be there; you mention that it is necessary to make the limiter work, but as far as I can tell the code you used doesn't need a limiter since it will always output either floor(gammaValue) or ceil(gammaValue).

Anyway, the version of linear light I expected was the following:


float3 convertToLinear(float3 gammaValue)
{
return (x<=0.04045) ? gammaValue/12.92 : pow((gammaValue+0.055)/1.055, 2.4)
}


as opposed to simple gamma correction, which would be:


float3 convertToLinear(float3 gammaValue)
{
return pow(saturate(gammaValue), 2.2);
}


If the gammaLight version does not use any gamma correction then that would explain why it performs better on darker colours, because actual linear light has a gamma of 1.0 near black not a gamma of 1/0.45 that was used in the code. This also explains why they seemed to behave exactly the opposite way of how I expected them to behave because I assumed gammaLight used gamma correction with a gamma of 2.2, but instead it didn't use gamma correction at all which is 'correct' for values near black.

[xabregas]

Hi

why all say that downscaling with linear light checked is better? what does this option do?

I tried to downscale lanczo 4 ar and ll with chroma NNEDI3 16 taps and dropped frames and after uncheck linear light i get no dropped frames, all settings equal...

TIA

[madshi]

Only NNEDI3 up to 32 neurons for Chroma upscaling works, anything higher then that eats up all GPU power and results in dropped frames.

Image doubling is just impossible, even just for Luma at 16 neurons. I get massive dropped frames and the video stutters heavily.
Try switching all algorithms (chroma upscaling, image upscaling, image downscaling) to Bilinear, and then enable NNEDI3 image doubling with 16 neurons. That should work just fine. At least it does on my PC with my HD7770. Once you get that working smoothly, you can set the other algorithms to better algorithms one-by-one.

Could you try a gamma compensation value of 1/2.0=0.5
Yes, can try that.

How does this differ from the gamma->linear->gamma conversion you do for linear light scaling which has a large performance impact?
Not sure what you mean? Error diffusion and scaling are completely different algorithms.

Also isn't that reversed?

If you are converting from 2.2 Gamma to 1.0 Linear shouldn't it be something like the following:

float3 convertToLinear(float3 gammaValue)
{
return pow(saturate(gammaValue), 1.0 / 2.2);
}
No. That would be "convertLinearToGamma()". See also here:

http://www.avsforum.com/t/912720/color-correction-with-a-htpc-simpler-solution-and-now-it-really-works/360

The pixel shader there shows you the right order of the pow() factors.

FWIW you are using a very different version of linear light then I was thinking about. It also thought that gammaLight used gamma correction, but that doesn't seem to be the case. [...]

Anyway, the version of linear light I expected was the following:


float3 convertToLinear(float3 gammaValue)
{
return (x<=0.04045) ? gammaValue/12.92 : pow((gammaValue+0.055)/1.055, 2.4)
}


as opposed to simple gamma correction, which would be:


float3 convertToLinear(float3 gammaValue)
{
return pow(saturate(gammaValue), 2.2);
}


If the gammaLight version does not use any gamma correction then that would explain why it performs better on darker colours, because actual linear light has a gamma of 1.0 near black not a gamma of 1/0.45 that was used in the code. This also explains why they seemed to behave exactly the opposite way of how I expected them to behave because I assumed gammaLight used gamma correction with a gamma of 2.2, but instead it didn't use gamma correction at all which is 'correct' for values near black.
The formula you're suggesting is the BT.601/709 transfer function. That is the function the original content was encoded with. But it's not the function the content is supposed to be viewed with. BT.601/709 were made at a time when CRTs still ruled the world, and CRTs have a pure power curve transfer function. Even BT.1886, the latest spec on how to calibrate your display, suggests a pure power curve calibration of the display - if the display has perfect black levels. Ok, the BT.1886 calibration differs from a pure power curve if the display black levels are not perfectly zero, so in most cases. But the BT.601/709 transfer function is usually only used for encoding, and then never used again.

It's a valid question which gamma curve to use for converting data between gamma <-> linear, for the purpose of processing the data in linear light. Personally, I think using a pure power curve for that is the way to go, because that's the way the content should ideally be displayed, but that's just my personal opinion.

I'm also not sure why the call to clamp is necessary, ideally it shouldn't be there; you mention that it is necessary to make the limiter work, but as far as I can tell the code you used doesn't need a limiter since it will always output either floor(gammaValue) or ceil(gammaValue).
The "limiter" functionality is the code which uses either floor() or ceil() of the gammaValue. When using this code, there are artifacts if you don't do the clamp(). If I want to get rid of clamp() I'd have to drop the floor/ceil solution and instead round the pixel to the nearest gamma value, which can sometimes be lower than floor(gammaValue) or higher than ceil(gammaValue).

why all say that downscaling with linear light checked is better? what does this option do?

I tried to downscale lanczo 4 ar
The usual recommendation is to not use Lanczos4 for downscaling, but instead simple Catmull-Rom AR with linear light. Linear light improves certain things, but also increases the danger of getting ringing artifacts. Because of that a 2-tap scaling algorithm (like Catmull-Rom) is probably the better choice, when using linear light downscaling.

[Aikibana]

I had same problem with gigabyte p55ud4 (i7 860- and R9 280x GFX
I tried clean win7 install and it was still KO with 13.12.
I tried nvidia gtx560ti gfx and no problem
I tried R9 280x on other motherboard (asus Z77 i7 3770k) and no problem :angry:
I guess there is some issues with AMD - p55 - openGL - 7xxx series.

I have a Gigabyte P55UD(3) mobo aswell!

Maybe others with this config could confirm or dispute these findings?

[Shiandow]

The formula you're suggesting is the BT.601/709 transfer function. That is the function the original content was encoded with. But it's not the function the content is supposed to be viewed with. BT.601/709 were made at a time when CRTs still ruled the world, and CRTs have a pure power curve transfer function. Even BT.1886, the latest spec on how to calibrate your display, suggests a pure power curve calibration of the display - if the display has perfect black levels. Ok, the BT.1886 calibration differs from a pure power curve if the display black levels are not perfectly zero, so in most cases. But the BT.601/709 transfer function is usually only used for encoding, and then never used again.

It's a valid question which gamma curve to use for converting data between gamma <-> linear. Personally, I think using a pure power curve for that is the way to go, because that's the way the content should ideally be displayed, but that's just my personal opinion.


As far as I know that transfer function is the on that is used for sRGB, in theory this should correspond to the brightness that is used by the monitor. Unless the monitor is using a pure gamma curve but I thought that most would use the sRGB standard. Unfortunately it seems unlikely that you can do this in a way that looks right for all screens, and the brightened examples don't really help since the brightening step itself needs to make assumptions about the way the screen displays the values.

I fear that you'd need more than 1 version too make it look right for all screens, ideally this should depend on the calibration settings for your screen in madVR.


The "limiter" functionality is the code which uses either floor() or ceil() of the gammaValue. When using this code, there are artifacts if you don't do the clamp(). If I want to get rid of clamp() I'd have to drop the floor/ceil solution and instead round the pixel to the nearest gamma value, which can sometimes be lower than floor(gammaValue) or higher than ceil(gammaValue).

I'm still not entirely sure why this 'clamp' is needed to avoid artifacts, it should only very rarely have an effect. The best explanation I've got is that randomValue is biased for some reason. The reason that I think so is that without randomValue the clamp shouldn't even have any effect.

[bacondither]

This might be relevant to the linear light discussion.

http://forum.doom9.org/showthread.php?t=162323

[iSunrise]

As far as I know that transfer function is the on that is used for sRGB, in theory this should correspond to the brightness that is used by the monitor. Unless the monitor is using a pure gamma curve but I thought that most would use the sRGB standard. Unfortunately it seems unlikely that you can do this in a way that looks right for all screens, and the brightened examples don't really help since the brightening step itself needs to make assumptions about the way the screen displays the values.
Not entirely relevant, but since you mentioned sRGB.

Just FYI, we had talks about including a sRGB calibration setting in madVR some time go, but ultimately madshi decided it wasn´t worth it, because the argument was that it´s not explicitly video-related, which means that if you want madVR to behave perfectly, you´d need to calibrate to the offered video targets.

The problem with all screenshot-comparisons out of madVR is that (same problem I had my last 2 posts) there are lots of people with different calibration targets and madVR calibration settings already, which are specifically optimized for madVR. They are not meant for desktop usage at all.

Some of us use BT.1886, some use BT.1886 with adjusted black values, some use BT.709 (even though sRGB would be a lot more optimal to the actual display characteristics, including a gamma of 2.2), some use SMPTE-C (e.x. some CRT users) and so on. Additionally, not everyone even uses madVR's 3DLUTs.

But from outside of madVR, at least on PC monitors, we usually have a pure power gamma again, so I´m not even sure if everyone is looking at the comparisons correctly. Additionally, not all monitors can even show all 0-255 levels, even if calibrated correctly.

@madshi:
Adding the DCI-P3 bug report right now.

[leeperry]

not everyone even uses madVRs 3DLUTs
A very small minority does actually, personally I've calibrated my TV to D65 using HCFR, an i1d2 and the 10/12bit TV built-in settings and then used that PS script (http://www.avsforum.com/t/912720/) to automatically roll gamuts in my media player based on resolution/fps. I know it's supposedly not as good as 3DLUT's but it's up and running in 2 mins and screenshots comparisons against tritical's ddcc() didn't show any difference, it also opens instantly even though 3DLUT's on a ramdisk would load equally as fast I guess.

The vast majority of mVR users prolly didn't bother calibrating their display with a sensor.

[cyberbeing]

No. That would be "convertLinearToGamma()".

Then I guess my understanding of linear gamma is reversed? The point isn't to change the display gamma of the source from 2.2 gamma to 1.0 linear gamma, but rather to remove the inverse transfer function so the source values will be linear on a 1.0 linear gamma device?

Not sure what you mean? Error diffusion and scaling are completely different algorithms.

My question is if your R'G'B' to RGB to R'G'B' operation was the same for both. In both cases you apply the conversion to linear light on textures(?), perform processing, then convert back to gamma corrected light? Or is something different? Essentially, could this problem with near-black tones we are seeing with the linear light error-diffusion, also be detrimental to the linear light scaling performed in madVR?

Linear light improves certain things, but also increases the danger of getting ringing artifacts.
Linear light scaling increases the danger of aliasing as well.

[iSunrise]

The vast majority of mVR users prolly didn't bother calibrating their display with a sensor.
Indeed. And even if you do that, the thing with calibration is that, even with very high-end LCD screens, you would need to re-calibrate at least every couple of months, since the CCFL backlights lose their light intensity over time.

But this would be a strict requirement of we´re doing such comparisons, therefore I´m not sure if - when we are comparing a lot of the lower level bars - we ever come to the same conclusion.

But it definitely is like Ver Greeneyes posted here, GL is closer to optimal than LL is (at least for me), for whatever reason there may be.

Maybe madshi has another idea about that, because I trust his algorithms, otherwise someone would have noticed something really wrong.

[Shiandow]

Not entirely relevant, but since you mentioned sRGB.

Just FYI, we had talks about including a sRGB calibration setting in madVR some time go, but ultimately madshi decided it wasn´t worth it, because the argument was that it´s not explicitly video-related, which means that if you want madVR to behave perfectly, you´d need to calibrate to the offered video targets

Indeed it seems that madVR does not actually have a setting to use a sRGB gamma curve, although you can specify that it should use a BT. 709 gamma curve with gamma 2.2, which (I think) should be identical. Although I'm not exactly sure since as far as I can tell a BT. 709 gamma curve should correspond to a gamma of 2.4 by definition.

But it wasn't my intention to suggest that madshi should use the algorithms I posted. I mainly posted them to try and explain the difference between what I expected and what actually happened. My main point was that you'd expect gamma light to behave better when viewed on a monitor calibrated with an sRGB gamma curve. This explained both why people preferred gamma-light (since good behaviour around black is preferable to good behaviour around white) and it explained why linear light was darker than I expected (since I misunderstood and thought gamma-light used a pure power gamma correction). I do think that in an ideal world madVR would contain an option to specify that your display is callibrated to an sRGB gamma curve and error dithering would use this setting to convert values to linear light. But given that most people haven't callibrated their displays or even know which gamma curve is closest to their display's, this may be overly complicated and not particularly useful.

FWIW as I mentioned I had attempted to reconstruct bacondithers images and if I use sRGB linear light then gamma-light is preferrable but if I use madshi's gamma correction then linear-light is better. What this means for actual viewing depends heavily on which calibration is most used by displays.