madVR - high quality video renderer (GPU assisted) [Archive] - Page 463

TheElix

14th February 2014, 13:10

So here comes the explanation of which releases did what:

ED5: floyd-stein, weight sum 1.00, old random generator
ED7: filter lite, weight sum 0.97, old random generator

noisy 1: floyd-stein, weight sum 1.00, new random generator
noisy 2: floyd-stein, weight sum 0.97, new random generator
noisy 3: filter lite, weight sum 0.97, new random generator
noisy 4: filter lite, weight sum 1.00, new random generator

nl1: filter lite, 0.97, old random generator
nl2: floyd-stein, 0.97, new random generator
nl3: floyd-stein, 1.00, old random generator
nl4: filter lite, 1.00, new random generator
nl5: floyd-stein, 0.97, old random generator
nl6: filter lite, 0.97, new random generator
nl7: floyd-stein, 1.00, new random generator
nl8: filter lite, 1.00, old random generator
And the NL builds also contained some algorithm improvements.That is very interesting! So while I preferred old random generator and many others preferred new random generator, everyone chose filter lite & 0.97. Furthermore, previous favorite was ED7 and it corresponds to NL1.

I will do more tests today on my great quality CRT (22" Mitsubishi 2070SB - smooth dither-less picture) and Mitsubishi HC5 LCoS 1080p projector between NL1 and NL6.

Shiandow

14th February 2014, 14:31

How odd that previously there seemed to be a clear preference for noisy 2 (floyd-stein, 0.97), but in the other two 'blind' tests the clear favourite was filter-lite, 0.97. Perhaps the improvements to the algorithm removed some of the weak points of ED7?

It's also interesting that there is a clear preference for one of the random number generators, as far as I can tell this is only possible because the seeds aren't 'random' enough. But it is hard to tell why one is considered better than the other.

cyberbeing

14th February 2014, 14:42

That is very interesting! So while I preferred old random generator and many others preferred new random generator, everyone chose filter lite & 0.97.

Well not everyone. Ever since madshi first introduced it, I've been preferring Floyd-Steinberg 0.97 using the old random number generator.

It also now makes sense why I rated ED7 & ED5 over the other noisy builds except "noisy 2" back then. I inherently disliked the new random number generator, yet "noisy 2" was the first Floyd-Steinberg 0.97 build which madshi offered. It also makes clear that my "increased sharpness and accuracy around fine detail by an order of magnitude" comment about the initial NoisyLimited build wasn't because of the bug-fixes, but rather because madshi had reverted back to the old random number generator and regained that quality I liked about ED7. Unfortunately for me, it wasn't until the last iteration that madshi had placed all my preferred variables in a single build.

That said, I actually preferred the NL6 build over the NL1 (ED7-based + bugfixes) build. This seems to suggest by pure chance that Filter-Lite may actually behave nicer with the new RNG, while Floyd-Steinberg may behave nicer with the old RNG. In both cases, the 0.97 weight sum had a more neutral appearance, while the 1.0 weight sum seemed to have a contrast enhancing property which improved detail but sometimes caused artifacts.

Ultimately, leeperry (NL6) and myself (NL5) continued to strongly prefer what were essentially similar opposites, for entirely different reasons.

NL5: floyd-stein, 0.97, old random generator

NL6: filter lite, 0.97, new random generator

This is the main reason why I decided to take a neutral stance and not vote or influence votes for this set. I had been focused so much on extensive testing to find a build with objectively very low distortion and high accuracy, it became difficult to do a fair subjective assessment. For example, the first thing I did when assessing the NL1-8 builds, was discard all the new RNG builds from consideration for having poor accuracy, lol. In regards to subjective appearance, it seems NL6 won out by quite a large margin by popular opinion, and considering where the other votes lay, use of the new RNG may have had a larger impact on subjective quality than anything else. The main difference I observed between new & old RNG on test patterns, was that the new RNG seemed to produce heavier and denser noise patterns in general.

madshi

14th February 2014, 15:23

cyberbeing

14th February 2014, 15:53

Since you compiled a new "gamma light" build which actually grew slightly in file size, did something else change compared to the actual original NL6 build?

Too tired to test anything right now, so I'll take a look when I wake up.

Ver Greeneyes

14th February 2014, 16:06

Can you NVidia guys double check whether performance is faster or slower for you?On my GeForce GTX 580:No dithering: 16.88ms
Linear Light: 21.07ms
Gamma Light: 21.28msSo yeah, a bit faster somehow. I haven't looked closely at image quality.

bacondither

14th February 2014, 16:15

Shouldn't it be impossible for one more processing step in chain to speed things up? :confused:

And yes, using linear light to dither in is the correct way to do it, and if nothing has gone wrong i with the implementation we should use it.

XMonarchY

14th February 2014, 16:37

Can madVR only support 65x65x65 3DLUT? I wonder if a 256x256x256 3DLUT can be made and then scaled to 65x65x65 to improve quality.

So, let me get this straight - are there going to be 2 versions of ED? Medium noise and little noise?

I am also a bit confused regarding the 8bit and etc. Aren't videocard and monitors/TVs capable of displaying 32bit colors? Movies are only using 8bits, so that is what... 256 colors, LOL? So madVR ED dithering upscales 8bits to 11-12bits, which adds intermediate colors, making a better-looking image. Can it go up to 32bits? Or would that be just an insane amount of processing that no videocard is capable of?

I know its off-topic, but does anyone know if 4K standard will bring a higher bit depth to mastered films? I know it uses a much wider gamut that Rec709.

Ver Greeneyes

14th February 2014, 16:50

Oh jeez, I just realized MPC-HC was using the standalone version of the LAV filters I have installed instead of its internal one for my test patterns - and I specifically have that set to only output RGB24 (to appease an older game that slows to a crawl during cutscenes with anything else). So I was looking at the LAV Video Decoder's random dithering this whole time (at least on my test patterns)! No wonder I couldn't tell much of a difference between each type. Forcing MPC-HC to use its internal filters causes it to crash on my test patterns like someone (The 8472, I think?) reported earlier. I don't know if a bug has been filed on that yet.

However, letting the standalone filters output the original 16-bit gradient to madVR is like light and day!

Can madVR only support 65x65x65 3DLUT? I wonder if a 256x256x256 3DLUT can be made and then scaled to 65x65x65 to improve quality.madVR 3DLUTs are 256x256x256 - collink.exe only uses 65x65x65 internally but the file it produces has the full resolution. You can force it to use the full 256 internally by using -r256, but expect it to use a lot of memory (and take longer).

I am also a bit confused regarding the 8bit and etc. Aren't videocard and monitors/TVs capable of displaying 32bit colors? Movies are only using 8bits, so that is what... 256 colors, LOL? So madVR ED dithering upscales 8bits to 11-12bits, which adds intermediate colors, making a better-looking image. Can it go up to 32bits? Or would that be just an insane amount of processing that no videocard is capable of?madVR outputs 8 bits per color channel, so 24 bits (red + green + blue) in total. I don't know what the 32-bit color thing Windows has offered since forever is about really, but monitors generally use 6-bit with dithering or 8-bit per color channel internally.

leeperry

14th February 2014, 16:53

Yay, new build :cool:

FWIW I find the picture to look clearer, more natural and "deeper" with gamma light. LL is a major step backwards transparency-wise IMHO. I've rolled many movies and for instance in OBLIVION the "open window" feeling isn't there anymore :(

Shiandow

14th February 2014, 16:58

madVR outputs 8 bits per color channel, so 24 bits (red + green + blue) in total. I don't know what the 32-bit color thing Windows has offered since forever is about really, but monitors generally use 6-bit with dithering or 8-bit per color channel internally.

As far as I know 32bit rgb is just 24bit rgb but with an alpha channel.

madshi

14th February 2014, 17:02

Since you compiled a new "gamma light" build which actually grew slightly in file size, did something else change compared to the actual original NL6 build?
Modified the shader code a bit, but image output should be bit by bit identical to NL6.

On my GeForce GTX 580:No dithering: 16.88ms
Linear Light: 21.07ms
Gamma Light: 21.28msSo yeah, a bit faster somehow.
Great!

Shouldn't it be impossible for one more processing step in chain to speed things up? :confused:
That's what I thought, too. Honestly, I was expecting performance of the linear light shader to be about half the performance of the gamma light shader. I first thought my benchmark program had a bug when the linear light shader performed faster. It really makes no sense to me.

So, let me get this straight - are there going to be 2 versions of ED? Medium noise and little noise?
That's the plan.

I am also a bit confused regarding the 8bit and etc. Aren't videocard and monitors/TVs capable of displaying 32bit colors? Movies are only using 8bits, so that is what... 256 colors, LOL?
That's 32bit per pixel and 8bit per component. Dithering does not upscale the bitdepth, it reduces the bitdepth.

I know its off-topic, but does anyone know if 4K standard will bring a higher bit depth to mastered films? I know it uses a much wider gamut that Rec709.
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.

However, letting the standalone filters output the original 16-bit gradient to madVR is like light and day!
:D

madVR outputs 8 bits per color channel, so 24 bits (red + green + blue) in total. I don't know what the 32-bit color thing Windows has offered since forever is about really, but monitors generally use 6-bit with dithering or 8-bit per color channel internally.
32bit has 24bit color information. The remaining 8bit are either blank or used for alpha.

Some LCD-Displays are only 6bit, and use dithering internally to get to 8bit. Some LCD-Displays are 8bit and use dithering to get to 10bit.

FWIW I find the picture to look clearer, more natural and "deeper" with gamma light. LL is a major step backwards transparency-wise IMHO. I've rolled many movies and for instance in OBLIVION the "open window" feeling isn't there anymore :(
That's too bad. From a scientific point of view, linear light should be more correct.

DragonQ

14th February 2014, 17:15

As far as I know 32bit rgb is just 24bit rgb but with an alpha channel.
Correct.

6233638

14th February 2014, 17:27

In both cases, the 0.97 weight sum had a more neutral appearance, while the 1.0 weight sum seemed to have a contrast enhancing property which improved detail but sometimes caused artifacts.Well that explains what I had been seeing when comparing NL4 and NL6. One thing that still shows up in my tests, is that NL6 seems to have larger "gaps" in its dither pattern, whereas NL4 has a tighter dither pattern and is more controlled.
NL4 creates smooth edges, and NL6's have a tendency to be somewhat "ragged" and blend together more.

I had been focused so much on extensive testing to find a build with objectively very low distortion and high accuracy, it became difficult to do a fair subjective assessment. For example, the first thing I did when assessing the NL1-8 builds, was discard all the new RNG builds from consideration for having poor accuracy, lol.These seem like legitimate reasons to prefer NL5, and why I had hoped you would weigh in on things - I would much rather the algorithm be chosen based on objective tests for distortion/accuracy than one person (that also happens to be color blind, which may influence things?) having a subjective preference and pushing everyone else towards it.

leeperry

14th February 2014, 18:03

That's too bad. From a scientific point of view, linear light should be more correct.
IIRC LL is only recommended for downscaling and not for upscaling so LL is not always the warrant of a better PQ as it would appear...it's not the case for NL6 to my eyes and I've rolled both builds quite extensively. We'll see what others think.

I would much rather the algorithm be chosen based on objective tests for distortion/accuracy
I didn't pay a million bucks to everyone who said he liked NL6 for that matter and all of them were honest in their vote AFAICT. Many of those who claimed they liked it didn't receive a PM from me kindly asking them to compare them in order to speed up mVR's development process in case you'd be wondering.

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.

FWIW the US army hires colorblind ppl to detect camouflage ppl with regular vision cannot see and there are many levels of colorblindness. I'm very used to mess with grain and noise on movie, the right settings can give such a stunning "pop effect" improvement(cyberbeing said that many studios add grain on purpose) and NL6 is by far the best I've seen. SmoothLevels was good, but NL6 is much better.

I'll agree that ideally depending on whether your brain is left or right-handed wired, how you perceive colors, how old you are and whether you're willing to accept more noise for more popping(or cannot stand noise whatsoever) you might need a different algorithm but there'll be one low and one mid-noise ED algorithm, enough to make everyone happy in madshi's opinion.

I'm quite sure the low noise ED will look so much better on static screenshots.

Ver Greeneyes

14th February 2014, 18:05

The problem is that with 6bit or 7bit panels I'm not sure where the exact "border" is when a pixel is displayed as different. E.g. for 6bit should I output 8bit values 0, 4, 8? Or should I output 2, 6, 10? And is this identical over the whole gamma range? I'm not really sure about all this, that's why I'm currently simply using random dithering instead of error diffusion if the user selects 6bit or 7bit.
Thinking about this a bit, what I expect happens (i.e. the cheap, dumb solution) is that for an 8-bit color x, monitors do something like this:b = x >> 2; // get the base color
f = x & 0b11; // get the fraction
t[0] = b;
t[1] = b + (f >> 1);
t[2] = b + (f & 1);
t[3] = b + (f >> 1);
...
output = t[counter & 0b11];orb = x >> 2; // get the base color
g = (x & 0b10) >> 1 | (x & 0b01) << 1;
...
output = ((counter & g) ? b + 1 : b);Either way, that implies that they either don't dither 0xfd through 0xff, or there's a 65th state for 'one above white' to complete the range which you can't access directly. So that means madVR should probably output |[6-bit color after dithering] << 2| to reduce flicker from dithering on the display's end (assuming the user explicitly set the display to 6-bit). If the monitor uses a 65th value internally to dither 0xfd through 0xff, white won't be completely white, but that might be worth the tradeoff.

Of course, this is all still just speculation, and I'm by no means an electrical engineer ;)

fairchild

14th February 2014, 18:09

Madshi, any plans to update a keyboard shortcut to toggle on/off NNEDI3 image doubling? It's not a big deal atm, but would be nice for a future build. Thanks as always!

MistahBonzai

14th February 2014, 18:11

This is why I always double check to ensure the image actually changed from my previous screenshot before moving onto the next build. Sometimes PrtScn can behave oddly with madVR, and produce an identical or blurry screenshot.

I hear ya. I haven't figured out the magic combination of steps required to capture the current image using alt+print screen when in full screen (I have "enable automatic fullscreen exclusive mode" enabled). Print screen seems to pull the image from a buffer and I haven't figured out how to force the desired image to be selected. Next step is testing without exclusive mode.

Shiandow

14th February 2014, 18:14

I should probably mention that the (cheap) method I suggested for performing 6bit error diffusion i.e. just dividing everything by 4 performing the dithering and multiplying everything by 4, does not work with linear light, it should be pretty easy to make it work with linear light but it requires some more effort.

James Freeman

14th February 2014, 18:18

Medium Noise = NL6 + Linear Light ...... is it final?

Anyone against?

iSunrise

14th February 2014, 19:05

From some in-depth experiments with the add noise/grain algorithm in ffdshow some years go on a very good CRT, all I can say is that adding very fine grained noise positively influences the perception of the original source material in such a way that certain flaws of the source cannot be easily seen anymore (becomes very obvious when you add a very fine grain random pattern to a heavily compressed movie). And while this technically isn´t very close to what dithering should do (reduce the bitdepth to X while trying to keep most of the original bits intact), it actually is similar to what we´re doing here.

I think this is the same kind of window effect that leeperry is describing and that´s also what I guess he means with pop-effect, because certain details/edges actually become more visible when you add some grain. The result is that you perceive the picture as sharper, more detailed, deeper, with less compression artifacts and of higher bitdepth altogether.

I was reminded of this just now, because most of the results that were reported are based on already 8bit compressed material, where obviously the pop-effect described above will have a lot more influence on the subjectively better picture, instead of the more accurate result (true to the source).

We should avoid altering the image in such a way that it´s not really dithering anymore, but too much tinkering with the source, which I want to avoid at all cost. Therefore I usually go with the more scientific approach, which 6233638 and cyberbeing (he has invested a lot of time in this already) have shown in various of their posts.

But since madshi has stated that we can also choose a low-noise algorithm now, this seems to be a good compromise.

I would have liked to see some people compare with higher bitdepth material than just 8bit compressed movies. I recently stumbled upon the TimeScapes movie (http://timescapes.org/products/default.aspx), which seems to be available in up to a native 4K 12bit Cineform format that was used to capture it. I already thought about buying it, even though it´s extremely expensive.

6233638

14th February 2014, 19:34

kstuart

14th February 2014, 19:39

I don't know. I'm always careful not to add too many things to the settings dialog and tray icon menu. Yes, some people might it useful to toggle the debug OSD there, but for most people the keyboard shortcut works just fine.

FWIW, you can manually edit "HKCU\Software\madshi\madVR\ShowOsd_" to enable/disable the debug OSD while madVR is not running.
Hmm... I suppose one could create .reg file to do that and then create a shortcut and put it in the Start Menu...

I think it would make more sense to figure out why the keyboard shortcuts don't seem to work with J.River MC and fix that, instead of cluttering the tray menu with things like this.

For reference: you, nevcairiel and Matt already gave a try to do that here:

http://yabb.jriver.com/interact/index.php?topic=70202.0

kstuart

14th February 2014, 19:42

@6233638 -

Do you still prefer SoftCubic80 for SD upscaling ? And am I correct that there is no point to engaging Anti-Ringing with SoftCubic80 (even if it would not overload the GPU) ?

The new profiles feature is very helpful in allowing different scaling for different resolutions...

Thanks!

6233638

14th February 2014, 20:00

Do you still prefer SoftCubic80 for SD upscaling ? And am I correct that there is no point to engaging Anti-Ringing with SoftCubic80 (even if it would not overload the GPU) ?Anti-ringing is actually damaging to image quality when used with SoftCubic, so I would not recommend it.
Honestly, there are so many options now, it's difficult to make a single recommendation.

If you have lower-end hardware, I do still like SoftCubic 80 a lot, as it produces a very smooth image, and avoids enhancing compression artifacts in the source.

But NNEDI3 luma doubling does a good job smoothing out rough edges with SD content, while retaining a sharp image and not enhancing compression artifacts too much (debanding can also help) which then lets you get away with a sharper upscaling algorithm as well.

Actually, for particularly bad SD sources, NNEDI3 luma doubling plus SoftCubic 80 scaling seemed to look quite nice. You still have a sharp image, but the edges of everything are just softened a bit which helps with ringing/mosquito noise etc.

EDIT: Very quick comparison shots:

SoftCubic 80 (http://abload.de/img/sc80lnsbw.jpg)
Mitchell-Netravali + Anti-ringing (http://abload.de/img/mnarb0s91.jpg)
Jinc 3 + Anti-ringing (http://abload.de/img/j3arhgseh.jpg)
NNEDI3 (64) + SoftCubic 80 (http://abload.de/img/nsc80lssfn.jpg)
NNEDI3 (64) + Jinc 3AR (http://abload.de/img/nj3arsis3m.jpg)

iSunrise

14th February 2014, 20:01

I'm sorry, but here's one final test build for the medium-noise error diffusion algorithm:

http://madshi.net/madVRedLinear.rar

Basically two builds are contained: The original NL6 build, and a modified build which performs the error calculation and distribution in linear light. I was trying to avoid linear light because I thought that it would slow things down too much. But actually, I'm extremely puzzled, but on my AMD GPU the linear light error diffusion runs *faster* than the simpler gamma light error diffusion algorithm. I've no clue why. Can you NVidia guys double check whether performance is faster or slower for you?

In terms of image quality, I can't see that much of a difference. However, gray bars 17 and 18 seem to be slightly darker than when using gamma light. This could bring a small improvement to shadow detail, I think.
Did a test with the 1440p TimeScapes trailer.

NL6 gamma light build:
- sharper edges (this seems to be the reason why people prefer it, on a CRT this should be even more obvious)
- a bit brighter in the lowest grays (this does make darker details a tiny bit more visible)
- dot pattern is different from LL

NL6 linear light build:
- edges not as well defined as in the GL build, more smearing around the edges, edges bleed into each other
- a bit darker in the lowest grays (I´m not sure what to make of this, yet, as I´m using a hardware calibrated Eizo CG243W, have to test if it´s actually crushing blacks in a way, so we would actually have less visible shadow detail with this build)
- dot pattern is different from GL

And yes, on my GTX580 LL is a tiny bit faster, but that´s pretty much negligible.

So the question really is, does NL6 GL actually sharpen the source a bit (which would mean that we are actually cheating our eyes) or is that what the source actually looks like? Same with the less defined and darker appearance of the LL build. Will have to test some more.

Ver Greeneyes

14th February 2014, 20:19

We should avoid altering the image in such a way that it´s not really dithering anymore, but too much tinkering with the source, which I want to avoid at all cost. Therefore I usually go with the more scientific approach, which 6233638 and cyberbeing (he has invested a lot of time in this already) have shown in various of their posts.Well.. We could compare the dithered 8-bit output to my 16-bit source and see which one is objectively closest. Then if all the variants are very close, perhaps diff the images and subject what remains to a 2D frequency analysis on the luma? Maybe that's all going overboard though - it seems most people are content to go with option 6 since leeperry likes it and others don't see much difference.

I would have liked to see some people compare with higher bitdepth material than just 8bit compressed movies.The test pattern movies linked in my signature use 16 bits per color channel, though they're pretty artificial.

Skwelcha

14th February 2014, 20:27

Same here !

(Last MPC-HC / Last MadVR / HD6450 / Win 8)

good to know I'm not the only one...

Doesn't happen here. It must be something with your MPC-HC config. Try changing the key shortcut for full screen: View->Options select Player->Keys and find full screen, also check if you don't have Alt+Enter set for some other action.
It might also have something to do with keyboard language settings, which would be hard to debug. It might sound stupid, but check if you get the same behavior with both of your Alt keys.

If this doesn't help please ask the MPC-HC's developers/community for help as it's not really related to madVR.

I tried it one day via IRC, no one replied, but I will try it again. I changed the FS shortcut - no change

I
If a newer MPC-HC version introduced this, then it's likely to be an MPC-HC error. Please try some older MPC-HC version. If you can identify which exact MPC-HC version introduced this problem, that could be helpful for the MPC-HC developers to figure out which change in the MPC-HC code causes this problem.

I pinpointed it to the following:

MPC-HC.1.7.1.19.x86.VS2013 works
MPC-HC.1.7.1.46.x86.VS2013 doesnt work

so it has to be somewhere between those builds..

EDIT:

Seems like it is/was a known bug:
https://trac.mpc-hc.org/ticket/3956

bacondither

14th February 2014, 20:30

To add to the linear light dithering discussion look at http://scanline.ca/dithering/ for an example of linear gamma and non corrected gamma. These examples are dithered with ordered dithering but will suffice as a example.

The images are dithered to 1-bit so the differences are much greater then it would be with 8-bit.
If you squint hard you will probably se that the linear light dither looks approximately like the original image and the non gamma corrected looks alot brighter. Yeah you get more details in the dark parts but your image will have the wrong gamma.
This also happens with 8-bit but to a much smaller degree.

James Freeman

14th February 2014, 20:36

Thanks bacondither.

This is great and clear comparison of what gamma corrected (linear light) looks like.

leeperry

14th February 2014, 20:45

NL6 linear light build: [..]
- a bit darker in the lowest grays (I´m not sure what to make of this, yet, as I´m using a hardware calibrated Eizo CG243W, have to test if it´s actually crushing blacks in a way, so we would actually have less visible shadow detail with this build)
Yep exactly, I didn't dare mentioning it as I didn't run test patterns but the picture appears darker with LL and that kills dynamics to my eyes.

For the record, My TV went through a dead-on REC709 calibration and the GL build looks perfectly crisp with gamma set to vanilla 2.2 in mVR.

does NL6 GL actually sharpen the source a bit (which would mean that we are actually cheating our eyes) or is that what the source actually looks like? Same with the less defined and darker appearance of the LL build. Will have to test some more.
As you guys made very clear NL6 GL is all about subjective "guilty" pleasure, madshi has made this choice rather clear by asking other ppl's opinion. If his goal had been to go for the "cleanest" test patterns, he could have worked it out on his own.

Hopefully we could agree that the mid-noise algorithm is all about subjective enjoyment and low-noise about technical accuracy as true to the source as possible, that's up to madshi to decide.

Shiandow

14th February 2014, 20:58

In terms of image quality, I can't see that much of a difference. However, gray bars 17 and 18 seem to be slightly darker than when using gamma light. This could bring a small improvement to shadow detail, I think.

I don't understand why linear light would make near blacks darker, shouldn't linear light effectively have a gamma of 1.0 near black?

As far as I know if you use linear light then a value of 0.5 should cause approximately half of the pixels to have value 0 and the other half 1. In gamma light with a gamma of 2.2 then this would happen at 0.73; a value of 0.5 would cause 22% of the pixels to have value 1 and the other 78% to have value 0. So switching from gamma light to linear light should make things lighter not darker.

Are you sure you haven't mislabelled them? Since they seem to behave exactly the opposite of how you'd expect them to behave.

Edit: For clarity: with a value of "1" I mean 1 out of 255, not the maximal value.

iSunrise

14th February 2014, 21:08

Are you sure you haven't mislabelled them? Since they seem to behave exactly the opposite of how you'd expect them to behave.
What a coincidence, I just wanted to post basically the same thing, just worded differently. Because when I look at bacondither´s examples, it seems that what I am seeing in madVR is exactly the opposite to his examples.

At least the current GL build definitely has the better defined edges, which bacondither´s LL example shot also does have and madshi´s LL build adds smearing around the edges, which bacondither´s GL example has. Apart from the slight brightness difference (which is actually only visible in the darkest grays/colors and not anywhere else, whereas bacondither´s GL example alters the brightness of the whole image quite drastically), this seems like the exact opposite of what I would expect.

So either they aren´t directly comparable or something else is different. Hopefully madshi can say something about that, because now I´m really confused.

Shiandow

14th February 2014, 21:27

What a coincidence, I just wanted to post basically the same thing, just worded differently. Because when I look at bacondither´s examples, it seems that what I am seeing in madVR is exactly the opposite to his examples.

Bacondither's examples are comparing non-gamma corrected to gamma-corrected. Or alternatively gamma 2.2 and gamma 1.0. From what I understand madshi now has version with pure power gamma correction and linear light gamma correction, these are much closer. But when you look at colours near black then linear light should behave like gamma 1.0 (the lower image) and gamma light should still behave like gamma 2.2 (the top image), so linear light should be brighter, which it isn't.

bacondither

14th February 2014, 21:53

trip_let

14th February 2014, 21:55

Sorry to interrupt the current discussion, but does anybody know what order madVR processing is done in relation to pixel shaders?

Specifically, are post-resize pixel shaders before or after madVR dither / ED? I'd make sense for dither to be at the end, but I don't know if that's what's possible with respect to jobs being handed off to different parts of software, interoperability, etc.

iSunrise

14th February 2014, 22:23

Dithering in linear light gives a more accurate image to the source.
Yes, indeed, LL seems more accurate in this example.

6233638

14th February 2014, 22:59

Dithering in linear light gives a more accurate image to the source.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.

Anime Viewer

14th February 2014, 23:06

Can you NVidia guys double check whether performance is faster or slower for you?

In terms of image quality, I can't see that much of a difference. However, gray bars 17 and 18 seem to be slightly darker than when using gamma light. This could bring a small improvement to shadow detail, I think.

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.

Shiandow

14th February 2014, 23:08

I extracted 16-bit pngs from Ver Greeneyes "gradient.mkv" he posted some while back. And then i took some screenshots from madvr ditherd down to 8-bit. It´s frame 89, and it is really dark. All imgs have their histogram capped at 10. So we are looking at the ~7 lowest steps of a 8-bit image(256 steps).

Source 16-bit (http://i.imgur.com/sguyrQ3.png)
No Dither
(http://i.imgur.com/dZr5Wai.png)
ED Gamma light (http://i.imgur.com/60ygzT5.png)
ED Linear light (http://i.imgur.com/5hftdD7.png)

Random dither (http://i.imgur.com/UAnLSMD.png)

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.

You need to be very careful with comparing the accuracy on brightened images. If you brighten it the wrong way then these kind of comparisons can easily become useless.

I think that in this case the correct thing to do would be to convert the images to linear light, then multiply the values by some constant, and then convert back to nonlinear light. Even then I am not 100% certain that this actually gives you a fair comparison since linear light may not necessarily seem linear to humans. For the most objective comparison you should probably blur the images in linear light, in that case a 'perfectly' dithered images should be identical to the original.

I have no way of verifying if this is the way it was done and I don't know if there even exists any software which performs brightening in this way.

nevcairiel

14th February 2014, 23:29

Sorry to interrupt the current discussion, but does anybody know what order madVR processing is done in relation to pixel shaders?

Specifically, are post-resize pixel shaders before or after madVR dither / ED?

Dithering is the very last step, after everything else, including after custom pixel shaders.

nevcairiel

14th February 2014, 23:31

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.

Are you sure you didn't mix them up?
Gamma Light seems to have the banding, and linear also looks closer to the original to me, although the end of the gradient doesn't match perfectly on either.

6233638

15th February 2014, 00:17

Are you sure you didn't mix them up?
Gamma Light seems to have the banding, and linear also looks closer to the original to me, although the end of the gradient doesn't match perfectly on either.

Comparing Bacondither's images, gamma definitely seems closest to the 16-bit source.
Those three images were used as the source for this comparison:

http://abload.de/img/dither68dq4.png

Black point is closest, and the gamma image values track closest to the 16-bit ones throughout the range. (neither are close in the upper range, but below about 50% gamma seems better)

madshi

15th February 2014, 00:32

Interesting. So should I trash the linear light build and stick to the gamma NL6 build? Opinions welcome.

har3inger

15th February 2014, 00:37

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.

GREG1292

15th February 2014, 00:47

Just got done comparing 7,LL,NL6 and from my projector
Linear Light is the clear winner. Still has the pop and
a veil has been lifted. Nice work:)

Shiandow

15th February 2014, 01:18

Interesting. So should I trash the linear light build and stick to the gamma NL6 build? Opinions welcome.

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.

Ver Greeneyes

15th February 2014, 01:24

Comparing Bacondither's images, gamma definitely seems closest to the 16-bit source. [...] (neither are close in the upper range, but below about 50% gamma seems better)
It seems odd that the "16-bit source" image seems brighter than the others. If it was as dark as the others in the upper range, would linear be closer to matching?

Edit: Ah, bacondither mentioned this. The results are so close together that it seems kind of important.
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.