madVR - high quality video renderer (GPU assisted)

[mzso]

Originally Posted by aufkrawall

Just gave it a quick try with Avisynth+ & MeGUI.
Original FRAPS RGB:


x264 I444:


No problem with MPC, LAV & madVR.

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

Originally Posted by DarkSpace

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 | your encode (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]

Originally Posted by 6233638

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 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-...ut_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]

Originally Posted by James Freeman

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]

Originally Posted by 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-...ut_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]

Originally Posted by 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).

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]

Originally Posted by iSunrise

I already posted my concerns about this 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
Error Diffusion

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]

Originally Posted by 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 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]

Originally Posted by aufkrawall

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]

Originally Posted by Mangix

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]

Originally Posted by Shiandow

...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]

Originally Posted by iSunrise

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]

Originally Posted by James Freeman

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

Environmentally friendly madVR, conserves bits.

[Shiandow]

Apparently it is green as well...

[MistahBonzai]

Originally Posted by The 8472

Environmentally friendly madVR, conserves bits.

Originally Posted by Shiandow

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

Originally Posted by cyberbeing

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.