madVR - high quality video renderer (GPU assisted)

[James Freeman]

Unless something has changed, HCFR stores the XYZ & RGB values with millionths accuracy (6 decimal places).

Thanks,
But I don't think we should go deeper into it.

Its simple really,
The faster the sensor is, the more stable the displayed texture should be to minimize "capturing the wrong moment", to minimize the error possibility.
IMO 8-bit Static does it best.

[GREG1292]

It can but acts like depth adjuster
8bit loses the pop I guess. Tested on several movies. Maybe I'm seeing things but my kids confirmed it. Really any setting looks good just some better than others.


Sent from my iPhone using Tapatalk

[Mangix]

well this sucks...

I've been playing around with the madVR settings and have noticed that on my monitor, I cannot see a difference between 7 and 8 bits with dithering off. Dithering only makes a visual difference at 6-bit and below. Does this mean that my monitor is dithering internally? If so, is there any point in using madVR's dithering algorithms on this monitor? I can't see a difference between any of them at 7-bits(even None).

[mzso]

I'd have to set up Avisynth etc. Got no time for this, sry.
Just flag the file as bt.601. Most likely then the orange tint will go away. Clear sign for a wrong colormatrix conversion.

I just managed to make a snapshot with MPV's opengl-hq renderer: http://screenshotcomparison.com/comparison/64648

The color differences don't happen here. Only encoding artifacts. So... I don't know...

[aufkrawall]

Just gave it a quick try with Avisynth+ & MeGUI.
Original FRAPS RGB:
http://abload.de/thumb/frapsrgb5dj2q.png (http://abload.de/image.php?img=frapsrgb5dj2q.png)

x264 I444:
http://abload.de/thumb/i4447zj2v.png (http://abload.de/image.php?img=i4447zj2v.png)

No problem with MPC, LAV & madVR.

[Shiandow]

Its simple really,
The faster the sensor is, the more stable the displayed texture should be to minimize "capturing the wrong moment", to minimize the error possibility.
IMO 8-bit Static does it best.

I don't exactly see why that probability would be larger with Dynamic rather than Static. It's just that in one case it depends only on the location and in the other also on the time. If your sensor is fast enough then (in theory) the best thing to do would be to take multiple measurements using Dynamic, from this you can calculate both the average value and the variance. If you use static then you've only got a very bad approximation of the average value.

[DarkSpace]

Doesn't seem too likely at this point. Unless avysinth and ffmpeg fail the same way.
Did that. Used PC.709 instead, because wanted to keep full range too. Yet the results remained the same.

You could check. I shared the source file and an encode.
Flag the bitstream. Your encoded sample may or may not be PC.709 YUV, but madVR doesn't know that. Therefore, it has to guess the range (for me, it guessed PC range), and it will also guess the color matrix (for me, it guessed BT.709). Apparently, for you, it didn't do that, so you should flag the bitstream (you should always do that, actually). In x264, the options are --input-range, --range and --colormatrix (I don't know about ffmpeg, but it's probably something similar). Also, of course, make sure that you don't convert the color matrix and flag the original matrix!
original (http://i.imgur.com/DuRBlNv.png) | your encode (http://i.imgur.com/xLXUIqe.png) (the frames don't match precisely, but that's because I'm too lazy to deal with your strange encode at whatever fps when the original file had 30 fps)

[James Freeman]

well this sucks...
I can't see a difference between any of them at 7-bits(even None).

If you are watching a movie (which is already dithered by the studios), then everything is fine.
Relax, I can't either, Most people can't.

Undithered smooth test patterns are a whole different story.

I don't exactly see why that probability would be larger with Dynamic rather than Static. It's just that in one case it depends only on the location and in the other also on the time. If your sensor is fast enough then (in theory) the best thing to do would be to take multiple measurements using Dynamic, from this you can calculate both the average value and the variance. If you use static then you've only got a very bad approximation of the average value.

Sounds logical.
Maybe you're right.

You are very welcome to try to test and come to a conclusion.
If what you posted is indeed the case, I'll be using Dynamic.

We still don't know if ArgyllCMS takes several reads from the same patch and averages them.

But,
I wan't to see real results, because I'm really beginning to get tired of assumptions and placebo (my own included).

[Ver Greeneyes]

I've been playing around with the madVR settings and have noticed that on my monitor, I cannot see a difference between 7 and 8 bits with dithering off. Dithering only makes a visual difference at 6-bit and below.If you can only see a difference starting from 6-bits, then I would say your monitor is not only 6-bit but isn't doing any (temporal) dithering of its own. In that case, you should actually get more benefit out of madVR's dithering, so long as you set it to 6-bit mode so it actually affects the image you see. Of course, you might want to make sure there there's actually no difference at all - get up close to the screen on a still image and see if you can see a pattern in the pixels (it's easiest in dark areas). If you can, then dithering is working as expected, even if you don't notice it normally. If you can't see any effect at all then yes, you'll need to use a lower base bitdepth.

[James Freeman]

Ver Greeneyes,
I think its important to know if Mangix is using a test pattern or a movie before assuming his monitor is 6-bit.

I too can hardly see the difference between 7 & 8 bit (None) with bluray content which is already properly dithered.
6-bit with Dithering, looks so good that I can use it without noticing the difference if its 8-bit or not.

[mzso]

Just gave it a quick try with Avisynth+ & MeGUI.
Original FRAPS RGB:
http://abload.de/thumb/frapsrgb5dj2q.png (http://abload.de/image.php?img=frapsrgb5dj2q.png)

x264 I444:
http://abload.de/thumb/i4447zj2v.png (http://abload.de/image.php?img=i4447zj2v.png)

No problem with MPC, LAV & madVR.

Fullrange too? (That's when the troubles start)

Flag the bitstream. Your encoded sample may or may not be PC.709 YUV, but madVR doesn't know that. Therefore, it has to guess the range (for me, it guessed PC range), and it will also guess the color matrix (for me, it guessed BT.709). Apparently, for you, it didn't do that, so you should flag the bitstream (you should always do that, actually). In x264, the options are --input-range, --range and --colormatrix (I don't know about ffmpeg, but it's probably something similar). Also, of course, make sure that you don't convert the color matrix and flag the original matrix!
original (http://i.imgur.com/DuRBlNv.png) | your encode (http://i.imgur.com/xLXUIqe.png) (the frames don't match precisely, but that's because I'm too lazy to deal with your strange encode at whatever fps when the original file had 30 fps)


It guesses bt.709 here too but I don't get a proper image. I previously tried using those flags, but it didn't do anyhting it already guessed the same thing (bt.709) for both.

I noticed that the madvr allows me to cycle between colormatrices. If I choose bt.709 manually the colors were wrong in a different way. The image became more purplish. So that's weird...
http://screenshotcomparison.com/comparison/64650
It didn't let me change the color primries though (gamut conversion disabled). Why is that? Is it important?

Could you (or someone else) upload my transcoded sample somewhere? If it would be good there and bad here, at least I would know that I'm not doing anything wrong...

[iSunrise]

I'm not sure if it's a bug, or just something that's being magnified by viewing in 3-bit, but I've been doing some comparisons and images seem to have a slight green tint to them when using Ordered Dither and colored noise.
This does not seem to be a problem with the error diffusion builds.
I already posted my concerns about this (http://forum.doom9.org/showthread.php?p=1670052#post1670052) when we still only had the 4bit mode available, even if it were only ED. That´s probably just how it is, if you add colors into the mix (was ordered dithering even meant to use colors?), even though it was quickly dismissed by "should cancel out".

[sneaker_ger]

@mzso @aufkrawall (@madshi)
It's not an issue with wrong flags, the file is correctly detected as full range BT.709. I made a lossless encode and the YUV 4:4:4 part looks different through madVR:
http://abload.de/img/ll_dither_madvr_ccujp.png (MPC-HC snapshot function of avs script opened with madVR)
http://abload.de/img/ll_dither_imagewriter5iu8w.png (screen from avs script through ImageWriter())
http://abload.de/img/ll_112_madvr2hu21.png (MPC-HC snapshot function of sample opened with madVR)

http://www.file-upload.net/download-8664452/output_ll.mkv.html

Script for the screenshots:
lwlibavvideosource("output_ll.mkv")
Dither_convert_yuv_to_rgb(matrix="709", tv_range=false, output="rgb24")

Not sure if it's an error so I'll leave it up for discussion.

[cyberbeing]

We still don't know if ArgyllCMS takes several reads from the same patch and averages them.
It doesn't. Whether values are averaged over time when a single measurement is taken depends on the instrument alone, and possibly influenced by driver integration time.

For calibration, Argyll takes single measurements until it hits a target threshold with dE repeatability.

For profiling, it takes single measurements of all test patches as well. If you have duplicate patches, it will average them when creating a LUT or matrix though. That said, targen only adds duplicates for 100% white by default.

In the past, I actually suggested adding an averaging function to make measurements more reliable, but Graeme rejected it. Instead he implemented an option for adaptive integration time, which was overall faster solution for my i1pro low-light measurement woes. He has generally been very adverse to making changes which increase (already comparatively very slow) calibration and profiling times even more. Reading every patch multiple times, would just make Argyll CMS orders of magnitude slower. Nothing would prevent you from creating custom patch sets with lots of duplicates, but I don't see him as making this the default. With massive patch sets, instrument drift starts to become a concern as well.

[aufkrawall]

@mzso @aufkrawall (@madshi)
It's not an issue with wrong flags, the file is correctly detected as full range BT.709. I made a lossless encode and the YUV 4:4:4 part looks different through madVR:
http://abload.de/img/ll_dither_madvr_ccujp.png (MPC-HC snapshot function of avs script opened with madVR)
http://abload.de/img/ll_dither_imagewriter5iu8w.png (screen from avs script through ImageWriter())
http://abload.de/img/ll_112_madvr2hu21.png (MPC-HC snapshot function of sample opened with madVR)

http://www.file-upload.net/download-8664452/output_ll.mkv.html

Script for the screenshots:
lwlibavvideosource("output_ll.mkv")
Dither_convert_yuv_to_rgb(matrix="709", tv_range=false, output="rgb24")

Not sure if it's an error so I'll leave it up for discussion.
Indeed, I can confirm this. I used LAV DSS for both screenshots.

[iSunrise]

well this sucks...

I've been playing around with the madVR settings and have noticed that on my monitor, I cannot see a difference between 7 and 8 bits with dithering off. Dithering only makes a visual difference at 6-bit and below. Does this mean that my monitor is dithering internally? If so, is there any point in using madVR's dithering algorithms on this monitor? I can't see a difference between any of them at 7-bits(even None).
You need to use the right test patterns for that to be really sure. It is by no means easy to see that with real world content if the bitdepth is still sufficient. madshi already posted something about that some pages back.

[Shiandow]

I already posted my concerns about this (http://forum.doom9.org/showthread.php?p=1670052#post1670052) when we still only had the 4bit mode available, even if it were only ED. That´s probably just how it is, if you add colors into the mix (was ordered dithering even meant to use colors?), even though it was quickly dismissed by "should cancel out".

That's a somewhat different problem, in that case you could show that an equal amount of pixels were green tinted and magenta tinted and the question was whether those two cancel out.

In this case the vast majority of pixels are green, which isn't supposed to happen. To illustrate this I created the following images by lowering the bitdepth to 3 bits, blurring the image, and then increasing the saturation by 100:

Ordered dithering (http://i.imgur.com/5ZAsKAZ.jpg)
Error Diffusion (http://i.imgur.com/8ILfgcK.jpg)

Clearly something is off with the ordered dithering, nearly all pixels are green.

Edit: This also seems to occur in 8bit but this is somewhat harder to show.

[Mangix]

Ver Greeneyes,
I think its important to know if Mangix is using a test pattern or a movie before assuming his monitor is 6-bit.

I used anime content to test this(720p blu-ray). I figure that it should show the effects of dithering more clearly than say a Hollywood movie because of its plastic-y look.

Right now I have madVR set to 7-bit with NO dithering. Turning dithering on seems to be counter-productive as it costs performance and I see absolutely no difference in the video, even when I look at the video very closely.

My initial thought about dithering was that it helps mainly with madVR's processing of the video(upscaling, debanding, etc...) but now it looks like it doesn't.

[mzso]

Indeed, I can confirm this. I used LAV DSS for both screenshots.

I know LAV but what's DSS? And how do you make screenshots with it?

[aufkrawall]

DirectShowSource. Made the screenshots with MPC HC.

[Ver Greeneyes]

My initial thought about dithering was that it helps mainly with madVR's processing of the video(upscaling, debanding, etc...) but now it looks like it doesn't.Converting from YUV420 to RGB, chroma doubling, image upscaling and downscaling will all generate values with a fractional part, so dithering will almost always be needed. Does 6-bit + dithering look good to you, or does it just look noisier than 7 or 8 bit without dithering?

[iSunrise]

...Clearly something is off with the ordered dithering, nearly all pixels are green.

Edit: This also seems to occur in 8bit but this is somewhat harder to show.
Indeed, this actually doesn´t look right at all.

[cyberbeing]

Clearly something is off with the ordered dithering, nearly all pixels are green.

Edit: This also seems to occur in 8bit but this is somewhat harder to show.
Indeed, this actually doesn´t look right at all.

I think that may just be how it is, at least with the Ordered Dither method madshi has chosen. This is part of the reason why I mentioned earlier that people should reassess the use of monoColor dynamic instead of oppositeColor dynamic for Ordered Dither. If the luma noise level of monoColor (like the OD32 test build) is found to be within an acceptable range, it may make a better default for madVR. Otherwise, maybe madshi should toss multiColor at it and see if it behaves any better.

[Shiandow]

Well, I don't know what the exact reason is behind the 'green tint' but it is definitely something which can (and should) be fixed. Whether chroma noise is preferrable to luma noise is a different debate and this issue is almost completely irrelevant. In fact depending on what the reason behind this bug is the monoColored build might be 'wrong' as well except it isn't noticeable since all channels behave the same way.

[cyberbeing]

Well the other part of the reason I mentioned it, was that some of the dense heavy patterns ordered dither produces at times seemed more noticeable with colored vs mono, though I guess it's possible both could be related.

monoColor ordered dither also seemed to have a tendency towards combining luma with single color dots, but rarely two different colors dots + luma like monoColored error-diffusion does. I had assumed this was intentional, but if not, the bug probably does affect monoColor as well. From what I remember, the oppositeColor color noise distribution seemed logical based on monoColor luma noise, as both shared identical patterns.

[The 8472]

Although with the new dithering methods, 5-bit is quite enough to enjoy the movie completely. :D

Environmentally friendly madVR, conserves bits.

[Shiandow]

Apparently it is green as well...

[MistahBonzai]

Environmentally friendly madVR, conserves bits.
Apparently it is green as well...
Bwa ha ha ha!

[James Freeman]

I can't reproduce the green tint effect with OD32 & 3-bit.
I have equal balance between Green and Magenta.
Did you disable 3DLUT?

Here is a screenshot from my setup:
3bit OD32 Color (http://www.mediafire.com/convkey/4bc3/75mvbphag0d88jvfg.jpg)


We still don't know if ArgyllCMS takes several reads from the same patch and averages them.
If it does, Dynamic will do better.
It doesn't.
For calibration, Argyll takes single measurements until it hits a target threshold with dE repeatability.

Thanks for clearing that out.
With a single measurement, Static will be more reliable.

[Asmodian]

The new dithering options are great! I like Error Diffusion - option 2, no colored noise, and change dither for every frame. Never looked better.

I finally figured out how to make madVR handle GPU gamma ramps and 3DLUTs in the way I want. The only problem is that I needed to use a hex editor to remove the linear gamma ramps from the 3DLUT created by argyllcms.

I want madVR to ignore the GPU's gamma ramps (use only the 3DLUT for calibration) while not resetting the gamma ramps for everything else.

I discovered "disable GPU gamma ramps" only has an effect if the 3DLUT does not have an attached set of ramps. "disable GPU gamma ramps" does exactly what I want when used with a 3DLUT without attached ramps. The issue is that to get a good white point with argyllcms I need to include the calibrated gamma ramps in the 3DLUT creation, if I do that linear gamma ramps are appended to the 3DLUT which get applied by madVR (changing the white point for Windows). I think these ramps should not be applied if "disable GPU gamma ramps" is checked, that setting should over-write argyll instead of the other way around. :)

It isn't really a major issue, the linear ramp that needs deleting is at the end of the file and its start is obvious when looking at the file in a hex editor. I do like the ramp being included in the file, I just want madVR to ignore it sometimes. ;)

[James Freeman]

@Asmodian

I don't understand your post, but I really want to because its in my interest also.
Do you meant you want to leave the VideoLUT that's loaded in the video card untouched, and have the 3DLUT do color correction?

I want madVR to ignore the GPU's gamma ramps (use only the 3DLUT for calibration) while not resetting the gamma ramps for everything else.
Isn't that what "disable GPU gamma ramps" does when NOT selected?
Leaving VideoLUT untouched, while applying the 3DLUT.
I discovered "disable GPU gamma ramps" only has an effect if the 3DLUT does not have an attached set of ramps.
Does NOT have, or DO have?
Effect on what? VideoLUT loaded in the GPU?
"disable GPU gamma ramps" does exactly what I want when used with a 3DLUT without attached ramps.
The issue is that to get a good white point with argyllcms I need to include the calibrated gamma ramps in the 3DLUT creation,
if I do that linear gamma ramps are appended to the 3DLUT which get applied by madVR (changing the white point for Windows).
Please explain your post clearer.
Its not very beneficial to anyone if you're the only one who can understand it...


As I understand it:
The 3DLUT should have an embedded Gamma/Calibration ramp (Linear, if you do NOT select "Apply Calibration" in the 3DLUT creator).
"disable GPU gamma ramps" should disable the VideoLUT ramp.
If Not selecting "disable GPU gamma ramps" and activating 3DLUT, you'll get two calibration ramps one on top of the other.

You can always just Profile in ArgyllCMS without Calibrating.
This will embed a totally flat linear calibration file into the resulting profile/3DLUT.

[Mangix]

Converting from YUV420 to RGB, chroma doubling, image upscaling and downscaling will all generate values with a fractional part, so dithering will almost always be needed. Does 6-bit + dithering look good to you, or does it just look noisier than 7 or 8 bit without dithering?

6-bit + dithering looks slightly worse than 7-bit with no dithering. But honestly this feels like I'm picking at straws here. The difference is barely visible.

w/e. My eyes hurt from staring at the monitor too close to compare these images.

[QBhd]

I have a quick question... and staring at the screen for numerous settings has my eyes all fuzzy now... so I thought I would throw it out there for the experts to chime in. I push my R9 270x to max if possible and I have come to a fine hair's edge and can't decide the best of two scenarios:

ED (option 2) + Dynamic and use NNEDI3 x16 for Chroma upscaling

OR

Ordered Dithering and use NNEDI3 x32 for Chroma upscaling

the difference between the two is so small, but it's the difference between a few dropped frames to none.

Is the added level of NNEDI3 for Chroma upscaling worth the down-grade in dithering?

QB

[ryrynz]

ED (option 2) + Dynamic and use NNEDI3 x16 for Chroma upscaling

OR

Ordered Dithering and use NNEDI3 x32 for Chroma upscaling

the difference between the two is so small, but it's the difference between a few dropped frames to none.

Is the added level of NNEDI3 for Chroma upscaling worth the down-grade in dithering?

QB

If it came down to lowering the neurons for the chroma upscaling to enable higher quality dithering I'd rather do that than have higher neurons for chroma doubling, or you could just overclock a touch and have both :)

[Asmodian]

@Asmodian
Isn't that what "disable GPU gamma ramps" does when NOT selected?
Leaving VideoLUT untouched, while applying the 3DLUT.

No, with "disable GPU gamma ramps" selected madVR bypasses the gamma ramps. It doesn't matter what they are set to (inverted even), the color is the same in madVR. This setting does not change weather or not they are loaded. If they are included in the 3DLUT they are always loaded no matter what and this setting does not bypass them.

Does NOT have, or DO have?
Effect on what? VideoLUT loaded in the GPU?

Does NOT have, if you have a set of gamma ramps attached to the 3DLUT the option "disable GPU gamma ramps" does nothing. madVR looks the same with or without it checked, the LUT is always applied but it is linear if it should be so everything looks ok in madVR.

As I understand it:
The 3DLUT should have an embedded Gamma/Calibration ramp (Linear, if you do NOT select "Apply Calibration" in the 3DLUT creator).
"disable GPU gamma ramps" should disable the VideoLUT ramp.
If Not selecting "disable GPU gamma ramps" and activating 3DLUT, you'll get two calibration ramps one on top of the other.

I do not know about a 3DLUT creator, I use command line. I am talking about the collink options:
-a file.cal Apply calibration curves to link output and append linear
-H file.cal Append calibration curves to 3dlut

Both of these situations are correct but if you want to use madVR's 3DLUT instead of the video cards LUT you have to have Windows also use linear gamma ramps when madVR is running. I want to be able to use "-a" but still have Windows calibrated all the time. edit: I can do this if I un-append the linear curves (hexedit) and use madVR's "disable GPU gamma ramps".

You can always just Profile in ArgyllCMS without Calibrating.
This will embed a totally flat linear calibration file into the resulting profile/3DLUT.

If you profile with ArgyllCMS without calibrating your white point will be off. Also, it will not embed a totally flat linear calibration file into the 3DLUT, it will not embed any gamma ramps at all (no -a or -H).

I hope I made more sense this time. :o

[Shiandow]

I can't reproduce the green tint effect with OD32 & 3-bit.
I have equal balance between Green and Magenta.
Did you disable 3DLUT?

Here is a screenshot from my setup:
3bit OD32 Color (http://www.mediafire.com/convkey/4bc3/75mvbphag0d88jvfg.jpg)

In that screenshot the majority of the pixels seems to be green, this is somewhat hard to see without processing the image but it's definitely there. The clearest method to show this would be to increase the saturation such that the green/magenta pixels stand out, blur this such that any area with more green pixels than magenta pixels becomes green, and then optionally increase the saturation again to make it even easier to see which regions are green and which are magenta.

[madshi]

I guess random dither might drop off then?
Not right now. Let's keep all the options for a while and then after a couple of weeks or so we can revisit who likes which algorithm the most and which algorithm might not be used at all, anymore, and then maybe drop some options based on that...

just a quick heads up - after updating from Catalyst 13.12 to 14.2 Beta 1.3 NNEDI scaling is working now. It really was "falling back" to Jinc chroma upsampling before - for whatever reason.

All is good now :)
Good to know!

Just ran a few more tests:
-colorful noise still looks uneasy to watch
-dynamic is still very obvious
-A4's EE is annoying to look at on sharp & clear 1080p but it works wonderfully on blurry/noisy/low-bitrate videos, sharpening up without white halos, very cool stuff :)
-ED11 is unforgiving, making it dynamic makes pristine 30fps 1080p look veiled as the noise is dancing around on top of the video but when going 64x NNEDI 24p 720p@1080p the dynamic noise dance still adds a noise veil but the latter is also injecting some much required "fake" grain and it wouldn't appear to be much of an issue from a distance...anyway don't shoot the messenger.
-my Sammy TV's anti-glare layers are quite thick(even my cat's claws couldn't rip it :D) but it comes with a semi-glossy finish so it's also veiling the picture anyway. OTOH glossy panels are unmanageable IME(the DELL S2440L that I briefly owned comes to mind) so it's all about compromises.
So which algorithm do you like most now? You're talking about "annoying" with A4 and about "look veiled" with dynamic ED11. So static ED11 it is for you?

I settled on 5bit with my projector ED11 OCD
can see a difference on a large screen. Nice work
madshi. And leepery Oblivion was great last night.
Had to watch that movie one more time and never
looked better.
Ouch. Your projector looks better with madVR set to 5bit compared to setting madVR to 6bit? That's quite interesting. I'd say it probably means that your projector isn't doing a very good job. Or maybe you just like the "grain" added by 5bit dithering?

Using ED2 with both options ticked and I'm completely sold :) I didn't like previous opposite colour dynamic - testbuild, but I just can't see the extra "energy" anymore, even if I kinda wanted to like OD more.
Great!

madshi, I'd be interested in hearing your subjective impression on mono dynamic vs color dynamic with ordered dithering?
After the green tint fix (see below) it's the same as with mono dynamic vs color dynamic for error diffusion: Using "color" lowers the luma noise level, which I personally find more pleasing. Using "dynamic" is IMHO a must have with ordered dithering. Static ordered dithering simply doesn't work too well for video, IMHO. This is with testing at 5bit, though, since I can't see a difference at 8bit, when looking at my computer monitor at least.

ED11 mono dynamic is rather interesting. Unlike A4, I so far do not seem to be instantly taking notice of the dynamic movement. If I notice it at all, would still require more testing.

Which leaves me with needing to do a comparison of A4 mono static against ED11 mono dynamic which I've yet to do.
Please let me know about your final preferences, thanks.

Yes, this avoids dropped frames (but I think I still had presentation glitches with my GTX 670, will test this as soon as the Radeon is sent back).
But somehow also setting default debanding strength from low to high (same level like strength during fade in/outs) solves frame drops.
Isn't this very odd? The drops occur btw. during fade in/outs.
It's not *that* odd. Without that trade option, madVR rerenders the past 5 frames every time a fade is detected. The fade detection only detects a fade as a fade after 5 frames were faded in a row. So in the moment when the fade is detected, madVR has to go back, throw away the past 5 frames rendering and rerender them. That will immediately cut the render queue down from 7-8/8 to 2-3/8. This *can* maybe produce dropped frames once in a while if your GPU has a lot to do and circumstances are bad. Generally it might be a good idea to increase the GPU queue size if you want to use debanding with full fade functionality. E.g. with 12 GPU frames, the fade rerendering will only lower the GPU queue from 11-12/12 to 6-7/12, which should not be a problem.

Yes, I'm having sporadic presentation glitches with the Geforce. Happens both with either "don't rerender frames when fade in/out is detected" enabled and default debanding strength at high.
And you don't have any such glitches without debanding enabled at all? In the moment when those glitches occur (with the trade quality option activated) which state to the queues have? Are they all full? In any case, I'd suggest increasing the GPU queue size to 12, if your GPU has enough RAM for that. There isn't really any downside to using a higher GPU queue size, as far as I'm aware, except that "delay playback start until all queues are full" will delay a bit longer. In order to avoid presentation glitches you could also try increasing the number of "frames that shall be presented in advance".

I'm not sure if it's a bug, or just something that's being magnified by viewing in 3-bit, but I've been doing some comparisons and images seem to have a slight green tint to them when using Ordered Dither and colored noise.
This does not seem to be a problem with the error diffusion builds.
Yes, thanks for reporting this, it's a bug. Basically the random value I added had the range 0..1 instead of -0.5..+0.5, so when inverting the whole weight set for "oppositeColor", the green channel got a higher weight compared to red/blue. This problem only occured with ordered dithering. Should be fixed in this build:

http://madshi.net/madVRfinalDither4.rar

well this sucks...

I've been playing around with the madVR settings and have noticed that on my monitor, I cannot see a difference between 7 and 8 bits with dithering off. Dithering only makes a visual difference at 6-bit and below. Does this mean that my monitor is dithering internally? If so, is there any point in using madVR's dithering algorithms on this monitor? I can't see a difference between any of them at 7-bits(even None).
Soukyuu had exactly the same problem/question 2 pages ago. Please see this post (and the following) for my reply:

http://forum.doom9.org/showpost.php?p=1670818&postcount=23921

Right now I have madVR set to 7-bit with NO dithering. Turning dithering on seems to be counter-productive as it costs performance and I see absolutely no difference in the video, even when I look at the video very closely.

My initial thought about dithering was that it helps mainly with madVR's processing of the video(upscaling, debanding, etc...) but now it looks like it doesn't.
I strongly recommend to *always* enable dithering. You may not see the difference in many situations, but I guarantee in some movies in some scenes there will be a visible difference. And dithering enabled is simply more correct, in any case. Look at my reply to Soukyuu for more information on how to properly test this.

Scientifically, your eyes should be able to differentiate about 11-12 bits of brightness information in a smooth gray ramp. So if you set madVR to 7 bit without dithering, you're throwing away TONS of potential brightness steps for no good reason. Maybe current content is often not good enough to show a clear benefit, but as I said, that depends on the exact movie/scene. And we'll hopefully soon get 4K content with higher native bitdepths.

If you are watching a movie (which is already dithered by the studios), then everything is fine.
Please don't *ever* recommend or support disabling dithering. It's a bad bad bad idea. The hair on my neck is standing up. Seriously.

Environmentally friendly madVR, conserves bits.
Apparently it is green as well...
Haha! :D

I finally figured out how to make madVR handle GPU gamma ramps and 3DLUTs in the way I want. The only problem is that I needed to use a hex editor to remove the linear gamma ramps from the 3DLUT created by argyllcms.

I want madVR to ignore the GPU's gamma ramps (use only the 3DLUT for calibration) while not resetting the gamma ramps for everything else.

I discovered "disable GPU gamma ramps" only has an effect if the 3DLUT does not have an attached set of ramps. "disable GPU gamma ramps" does exactly what I want when used with a 3DLUT without attached ramps. The issue is that to get a good white point with argyllcms I need to include the calibrated gamma ramps in the 3DLUT creation, if I do that linear gamma ramps are appended to the 3DLUT which get applied by madVR (changing the white point for Windows). I think these ramps should not be applied if "disable GPU gamma ramps" is checked, that setting should over-write argyll instead of the other way around. :)
I'm a bit confused here. You should be doing the ArgyllCMS calibration with linear ramps loaded into the GPU. If you don't do that, you'll lose quality because the GPU ramps only work in 8bit (when using digital output), so that would screw up the whole calibration accuracy.

And if you perform the ArgyllCMS calibration with linear ramps loaded into the GPU, then the GPU ramps also have to be linear when playing the video, otherwise you'll get incorrect colors.

Am I missing something?

I have a quick question... and staring at the screen for numerous settings has my eyes all fuzzy now... so I thought I would throw it out there for the experts to chime in. I push my R9 270x to max if possible and I have come to a fine hair's edge and can't decide the best of two scenarios:

ED (option 2) + Dynamic and use NNEDI3 x16 for Chroma upscaling

OR

Ordered Dithering and use NNEDI3 x32 for Chroma upscaling

the difference between the two is so small, but it's the difference between a few dropped frames to none.

Is the added level of NNEDI3 for Chroma upscaling worth the down-grade in dithering?
I don't know. If I've learned anything in this thread then it is that every user's eyes/brain works a bit differently. It was unfortunately necessary to add so many new dithering options simply because we couldn't come to a clear agreement which algorithm was best.

So to answer your question, I fear you will need to try both configurations you suggested yourself and check which one your eyes/brain prefer. Which dithering algorithm looks best might also be dependent on your display. And whether more neurons help will also depend on the movie/scene. So I really wouldn't know what to recommend to you...

-------

So here's another "final" build which fixes the green tint when using "colored" ordered dithering. The fix may also modify/improve mono colored ordered dithering ever so slightly compared to the previous "final" builds:

http://madshi.net/madVRfinalDither4.rar

[Owyn]

madshi,

Hello, I think I have an audio noise lag related to MadVR - https://trac.mpc-hc.org/ticket/4076
MadVR somehow forces audio to be in perfect sync with the video and so makes it create a noise when it can't be perfectly synced due to CPU overuse (it starts at player using 50-60% CPU), I tried old madVR versions - 09 and 020 and those don't seem to have this (because as I lowered priority of the MPC HC player and made video lag forcefully (cuz it didn't want to - used way less resources than madvr does now) - audio desynced but didn't make any noise, (from version madVR040.zip and above the noise is there as I tested)

so could you please (please please please) make an option to turn off perfect audio syncing to video so it could stop making that noise?

[Asmodian]

And if you perform the ArgyllCMS calibration with linear ramps loaded into the GPU, then the GPU ramps also have to be linear when playing the video, otherwise you'll get incorrect colors.

Am I missing something?

Well can't I get the effect of linear ramps by using "disable GPU gamma ramps" without actually having to load linear ramps?

[madshi]

Hello, I think I have an audio noise lag related to MadVR - https://trac.mpc-hc.org/ticket/4076
MadVR somehow forces audio to be in perfect sync with the video and so makes it create a noise when it can't be perfectly synced due to CPU overuse (it starts at player using 50-60% CPU), I tried old madVR versions - 09 and 020 and those don't seem to have this (because as I lowered priority of the MPC HC player and made video lag forcefully (cuz it didn't want to - used way less resources than madvr does now) - audio desynced but didn't make any noise, (from version madVR040.zip and above the noise is there as I tested)

so could you please (please please please) make an option to turn off perfect audio syncing to video so it could stop making that noise?
madVR has zero feedback into the video player or audio system. Basically the upstream filters (splitter, decoder etc) send stuff to madVR and madVR then renders it. I don't see how any of this would effect audio playback. The audio playback components don't even know whether madVR renders anything or nothing at all. So I think it's unlikely that this is madVR's fault. Except maybe because madVR is consuming some CPU resources.

Well can't I get the effect of linear ramps by using "disable GPU gamma ramps" without actually having to load linear ramps?
From a technical point of view there is no way to "disable the GPU gamma ramps". Basically they are always used. So disabling them practically means filling them with linear values. So disable=linear.

[Asmodian]

From a technical point of view there is no way to "disable the GPU gamma ramps". Basically they are always used. So disabling them practically means filling them with linear values. So disable=linear.

If I check/uncheck "disable the GPU gamma ramps" the white point in Windows does not change while the white point in madVR does.

If I use a linear ramp attached to the 3DLUT the white point in Windows changes too.

The video in MadVR looks the same either way (global linear or just "disable the GPU gamma ramps" checked).

Is this not what you are expecting with that option? It doesn't load linear ramps into Windows for me (Win 8.1).

[madshi]

I was tinkering around (http://forum.doom9.org/showthread.php?p=1670478#post1670478) with encoding full range rgb UT Video to yuv444 h.264. And I kept getting results that looked a bit different. Tried using only ffmpeg, then using avisynth with x264. As it turns out it might be a renderer issue. Here's my source (https://drive.google.com/file/d/0ByfdfPvnoDuzcFpvNWtOWlptQ0E/edit?usp=sharing) and one of my encoded files (https://drive.google.com/file/d/0ByfdfPvnoDuzXzFZWUJyOGZyX1k/edit?usp=sharing). People claimed it looks something that might be related to bt.601/bt.709 conversion.
Here's what I got:
http://screenshotcomparison.com/comparison/64616 the color always got more orangish.
Someone claimed that my encoded file looks properly so I made screenshots with Potplayer's EVR-CP where I got opposite results:
http://screenshotcomparison.com/comparison/64643
(plain EVR rendered most obviously wrong, too dark colors)

So is this a renderer bug? Or something else?
@mzso @aufkrawall (@madshi)
It's not an issue with wrong flags, the file is correctly detected as full range BT.709. I made a lossless encode and the YUV 4:4:4 part looks different through madVR:
http://abload.de/img/ll_dither_madvr_ccujp.png (MPC-HC snapshot function of avs script opened with madVR)
http://abload.de/img/ll_dither_imagewriter5iu8w.png (screen from avs script through ImageWriter())
http://abload.de/img/ll_112_madvr2hu21.png (MPC-HC snapshot function of sample opened with madVR)

http://www.file-upload.net/download-8664452/output_ll.mkv.html

Script for the screenshots:
lwlibavvideosource("output_ll.mkv")
Dither_convert_yuv_to_rgb(matrix="709", tv_range=false, output="rgb24")

Not sure if it's an error so I'll leave it up for discussion.
I can see the color mismatch problem on my PC, too. However, try forcing LAV to NV12 output - and the colors still stay the same. So this has nothing to do with madVR getting 4:4:4 content. Must be something else.

My best guess is that x264 uses buggy math to convert the video from RGB to (fullrange) YCbCr. But of course this is only a wild guess, nothing else. I did see (and report) bugs in x264's color conversion code in the past already, though. So this being x264's fault would not come as a surprise to me.

The only way this could possibly be madVR's fault would be if madVR generally would handle all YCbCr fullrange input incorrectly. I think somebody would have noticed that already, if that were the case? Anyway, anybody willing to put this to a test? I've no experience with encoding stuff, so I'm probably not the right person to do the testing/experimentation...

It didn't let me change the color primries though (gamut conversion disabled). Why is that? Is it important?
We're just trying to play the encode with the same colors as the original file. Since the encoding process is very unlikely to change the primaries, I don't think we have to play with different primaries in madVR. The color encoding/decoding matrix and the levels (limited range vs full range) is probably where it's at.

[madshi]

If I check/uncheck "disable the GPU gamma ramps" the white point in Windows does not change while the white point in madVR does.
Not enough information. Is this with a 3dlut loaded or not? Does the 3dlut have GPU ramps attached or not? Are we talking about overlay mode or windowed mode or FSE mode? All of these will influence the results.

This is an extremely complex topic because so many variables are involved. Right now I'm pretty confused about what you were/are doing, and why you manually modifed the 3dlut file etc etc. Makes all no sense to me right now. Have you read and understood what I wrote about the ramps having to be linear=disabled while doing ArgyllCMS calibration? Is that the way you were doing the measurements/calibration?

[sneaker_ger]

My best guess is that x264 uses buggy math to convert the video from RGB to (fullrange) YCbCr.
This has nothing to do with x264 as my screenshots are all from the same lossless sample, not from mzso's original files.

[Owyn]

madVR has zero feedback into the video player or audio system. Basically the upstream filters (splitter, decoder etc) send stuff to madVR and madVR then renders it. I don't see how any of this would effect audio playback. The audio playback components don't even know whether madVR renders anything or nothing at all. So I think it's unlikely that this is madVR's fault. Except maybe because madVR is consuming some CPU resources.
Weird cuz old versions of MadVR just desync with audio without making noise and new ones make audio noise and won't let the audio desync, both tested under artificial lag and without needed CPU resources,

so it's the LAV video decoder \ splitter which does this?

LAV has some if\else conditions for MadVR version then to know when to make the noise and when not to? :o

[Asmodian]

Not enough information. Is this with a 3dlut loaded or not? Does the 3dlut have GPU ramps attached or not? Are we talking about overlay mode or windowed mode or FSE mode? All of these will influence the results.

This is an extremely complex topic because so many variables are involved. Right now I'm pretty confused about what you were/are doing, and why you manually modifed the 3dlut file etc etc. Makes all no sense to me right now. Have you read and understood what I wrote about the ramps having to be linear=disabled while doing ArgyllCMS calibration? Is that the way you were doing the measurements/calibration?

I am using a 3DLUT either with a set of linear ramps attached or not (manually removed). Windows 8.1 Overlay Mode only.

I do start calibration with linear ramps, dispwin -c. I then profile with linear ramps loaded but using dispread -K:

-K file.cal Apply calibration file to test values while reading

I then create the 3DLUT with collink -a:

-a file.cal Apply calibration curves to link output and append linear

I then have a calibration which looks great with linear ramps loaded and very odd with my "normal" ramps from dispcal loaded. I want linear ramps for madVR and my calibrated ramps in Windows. I had thought this was impossible too... but it seems to work. :o

From a technical point of view there is no way to "disable the GPU gamma ramps". Basically they are always used. So disabling them practically means filling them with linear values. So disable=linear.

In this mode (Win 8.1 overlay) I can see the white point obviously change toggling "disable the GPU gamma ramps" while Windows doesn't change at all. I will have to test in other modes, I will report back soon.

If it only works in this exact situation I will be happy with my hack and you can ignore me. :)

[Asmodian]

Weird cuz old versions of MadVR just desyncs with audio without making noise and new ones make audio noise and won't let the audio desync, both tested under artificial lag and without needed CPU resources,

so it's the LAV video decoder \ splitter which does this?

LAV has some if\else conditions for MadVR version then to know when to make the noise and when not to? :o

I always noticed this with Reclock, are you using something similar?

[QBhd]

If it came down to lowering the neurons for the chroma upscaling to enable higher quality dithering I'd rather do that than have higher neurons for chroma doubling, or you could just overclock a touch and have both :)

LOL... it's already a factory OC'd R9 270x (1120 MHz)... and I'm not sure I want to push it even further... madVR is even more demanding than the Latest Thief game :P

I don't know. If I've learned anything in this thread then it is that every user's eyes/brain works a bit differently. It was unfortunately necessary to add so many new dithering options simply because we couldn't come to a clear agreement which algorithm was best.

So to answer your question, I fear you will need to try both configurations you suggested yourself and check which one your eyes/brain prefer. Which dithering algorithm looks best might also be dependent on your display. And whether more neurons help will also depend on the movie/scene. So I really wouldn't know what to recommend to you...

Double LOL... I had a feeling you might say that! I'm pretty sure that the ED (option 2) gave me slightly better results than the extra neurons for Chroma upscaling... just hoped for an educated guess, since I was blurry eyed by the time I was done tweaking and posted this :P

BTW... ED option 2 + Mono Dynamic is awesome!

QB

[Owyn]

I always noticed this with Reclock, are you using something similar?

just the standart MPC HC player official build with everything internal, If I had something specific which was making this - I'd be happy to get rid of it :scared:

[madshi]

This has nothing to do with x264 as my screenshots are all from the same lossless sample, not from mzso's original files.
Just found this old thread related to similar chroma problems:

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

I hope that after reading that thread you'll have more trust in madVR than in swscale... :D

Weird cuz old versions of MadVR just desyncs with audio without making noise and new ones make audio noise and won't let the audio desync, both tested under artificial lag and without needed CPU resources,

so it's the LAV video decoder \ splitter which does this?

LAV has some if\else conditions for MadVR version then to know when to make the noise and when not to? :o
I've no idea where the noise comes from, but madVR got pretty much nothing to do with the audio side of things. So whether there's noise or not is outside of my control, from what I can see.

I am using a 3DLUT either with a set of linear ramps attached or not (manually removed). Windows 8.1 Overlay Mode only.

I do start calibration with linear ramps, dispwin -c. I then profile with linear ramps loaded but using dispread -K:

-K file.cal Apply calibration file to test values while reading

I then create the 3DLUT with collink -a:

-a file.cal Apply calibration curves to link output and append linear

I then have a calibration which looks great with linear ramps loaded and very odd with my "normal" ramps from dispcal loaded. I want linear ramps for madVR and my calibrated ramps in Windows. I had thought this was impossible too... but it seems to work. :o
Overlay mode makes a BIG difference because Overlay mode totally ignores the GPU gamma ramps. madVR has to do extra work to manually apply GPU gamma ramps in Overlay mode. Yeah, ok, I guess madVR could make use of this Overlay specialty by letting the GPU gamma ramps alone, when using Overlay mode. I'm not sure if madVR currently does that or not.

Double LOL... I had a feeling you might say that! I'm pretty sure that the ED (option 2) gave me slightly better results than the extra neurons for Chroma upscaling... just hoped for an educated guess, since I was blurry eyed by the time I was done tweaking :P
One thing in favor of ED is that *IF* your eyes can see a difference at all with ED, then you should see that in most movies and most scenes. While improved chroma upscaling will only be visible in specific scenes. If your eyes do generally prefer ED over ordered dithering, then I'd recommend going that way.