madVR - high quality video renderer (GPU assisted)

[cyberbeing]

I think, OD32 will be an excellent choice for madTPG.
Whether Mono/Color/Static/Dynamic, (probably Mono Dynamic will be best for greyscale).
Graeme should decide based on what would "look" better for the hardware sensors (should probably look good to our eyes too).

Well for something like Argyll CMS, I would think mono/static would be optimal for taking repeatable dE measurements on color patches. For what it's worth, the OD32 test build was a mono build.

madshi seems to be asking an opinion about general playback defaults though, since he changed the global default for all dither algorithms to (opposite)colored / dynamic in these madVRfinalDither builds. On most shades OD32 is patternless, though on a few it seems to have heavy patterns. On my tests, OD32 colored was more noticeable on these heavy patterned areas than OD32 mono especially with dynamic changes. Compared to the error diffusion algorithms, the ordered dither also seem to have more sparse and speckled noise, which is not particularly favorable to the visibility of mono or color varieties. Other people would need to test this though. Either way, I think it'd make sense for each algorithm to have individually saved 'options' instead of it being global, as I mentioned a couple posts ago.

[Ver Greeneyes]

Since no one appears to have mentioned it specifically (maybe I missed it), does ED11 dynamic correspond with "Error Diffusion - option 2" + "change dither for every frame"?

I think, OD32 will be an excellent choice for madTPG.
Whether Mono/Color/Static/Dynamic, (probably Mono Dynamic will be best for greyscale).
Graeme should decide based on what would "look" better for the hardware sensors (should probably look good to our eyes too).I could be wrong, but isn't madTPG supposed to just use what madVR normally uses? (Video LUT and 3DLUT toggles aside) In other words, if you change the madVR settings, madTPG will use those settings as well. I imagine it's generally best to calibrate and profile using the same settings you'll be using for viewing.

[cyberbeing]

Yes, ED11 'dynamic' is "option 2" + "change dither for every frame".

[James Freeman]

Well for something like Argyll CMS, I would think mono/static would be optimal for taking repeatable dE measurements on color patches. For what it's worth, the OD32 test build was a mono build.


Agreed,
Dynamic might add fluctuation which might lower the dE accuracy.

Since no one appears to have mentioned it specifically (maybe I missed it), does ED11 dynamic correspond with "Error Diffusion - option 2" + "change dither for every frame"?

None = Rounding.
Random Dithering = Random Dithering.
Ordered Dithering = OD32
ED Option 1 = Adaptive 4
ED Option 2 = ED11

Colored noise = OppositeColor.
Change dither for every frame = Dynamic.


I imagine it's generally best to calibrate and profile using the same settings you'll be using for viewing.

Agreed.

But, I've also heard @AVS about enforcing OD32 on madTPG.

[turbojet]

The new default, OD32?, has noticeably less noise at 8bit on 8 bit display at 24 fps, albeit it slight. I'll be using it, thanks!

[James Freeman]

The new default, OD32?, has noticeably less noise at 8bit on 8 bit display at 24 fps, albeit it slight. I'll be using it, thanks!

OD32 (Ordered Dithering) is an Excellent choice, to me it look as good as ED11 (ED Option 2).

Its amazing that it takes the same amount of GPU power as Random Dithering.
You fellows without DirectX 11 are in good hands.

[truexfan81]

is nnedi ever going to work for nvidia users?

[ryrynz]

Ask Nvidia that, it's not Madshi's problem. It's been passed on to them.

[Toku]

is nnedi ever going to work for nvidia users?

Hopefully we'll see a fix in the next driver update, the last thing Madshi reported got fixed fairly quickly iirc. For now just downgrade your drivers to a version before NNEDI was broken.

[Ver Greeneyes]

But, I've also heard @AVS about enforcing OD32 on madTPG.Isn't OD32 the version with the most randomness? In theory, ordered dithering should produce the best average value (spread out across a number of pixels), but when you start adding randomness I'm not so sure. Though really, I expect that all the new options are better than what we had, if it makes a difference at all to the instrument :)

[6233638]

I just wanted to say that I really like the new options for dithering, and I am glad that the ordered dither builds made it in.
I initially discounted them, but that's because I was looking for "optimal" image quality and pattern avoidance.

I'm actually seeing better performance with ordered dithering than random dither, and while there is a possibility of introducing patterns into the image, it's considerably reduced in the "dynamic" version.
So for roughly the same performance as random dither, the ordered dither option is a big image quality improvement.

When you consider how much lower the performance requirements are for Ordered Dithering, and how low the visibility of dither should be in 8-bit, I may end up using that now.


And I think the other options for dithering are "just right" even though it adds another section to the options window, though some people here might prefer a "mono/color/opposite" option, rather than "color on/off".


Standing back from it all without getting bogged down by which algorithm is "best", if you look at the results in 3-bit, which obviously exaggerates things, it's ridiculous how much better the new dither options are, especially if you compare "no dither" to any of the new options in 3-bit.

[iSunrise]

...Standing back from it all without getting bogged down by which algorithm is "best", if you look at the results in 3-bit, which obviously exaggerates things, it's ridiculous how much better the new dither options are, especially if you compare "no dither" to any of the new options in 3-bit.
Indeed. When I saw them at 3bit for the first time, my instant reaction was "holy shit, that´s just incredible".

I would say our scrutinizing efforts have all been worth it. And thanks to madshi for offering such flexible options for everyone, I simply cannot think of anyone who seriously cannot be pleased with it.

[madshi]

Well the thing is, with my panel set to 8Bit, I can disable dithering and not see a difference. I remember madshi saying one should not disable dithering because it would show banding etc, but I'm not seeing it... or not looking at the right things.

Sure, if I go down to 5Bit and below, I start to see the dithering (and I prefer ordered dithering (color noise, static pattern) over old random dithering in that case).
What I'm trying to figure out is, why would I need to spend resources on dithering in the first place...
The resources aren't very high, as long as you don't use error diffusion. You definitely should be able to see a difference at 8bit, when looking at the "right" content. E.g. try the madTestPattern test patterns, try "colors.ytp" or zoom "smallramp.ytp" up to the full screen, by using any algorithm other than DXVA scaling. With smallramp.ytp without dithering you should see small vertical bands in the image. colors.ytp should look pretty awful without dithering. Or alternatively try any gray ramp test pattern with madVR's debanding algorithm enabled.

Of course such test patterns make banding problems especially visible. With real movie content you'll see less problems. But still, in some scenes at least you should be able to see a difference. In any case, dithering is much more exact the disabling it. The human eye can see about 11-12 bits of brightness information. madVR can only output 8bit. So dithering is necessary to achieve a result which is smooth enough for the human eye to show a perfectly smooth image without any brightness steps (= banding).

Ack, I just checked again and realized ordered dither has very strong patterns on certain shades. I didn't notice this until seeing 'colored' in the latest build, but on close examination it also exists on luma when using 'mono'. Originally I thought I preferred ordered dither as mono / static, but after noticing the patterns with colored / dynamic, I think I'd settle on mono / dynamic instead. I'm torn now though... and unsure if ordered dither makes a good default over random dither.
I think in dynamic mode it's clearly better than random dithering. At least that's my impression. I don't like ordered dithering in static mode, though.

Though I guess defaults don't really matter, as long as configuration options for dithering don't start disappearing at some later date.
I am tempted to reduce the amount of options. But I'll not do so silently without a public discussion first.

Have you tried ED11 dynamic vs A4 static yet, btw?

If you are not already doing so, please allow each dither algorithm choice to have separate saved/restored 'options' checkboxes instead of being a global setting.
That would cost more work and while I see that it would be "nice" I don't consider it really crucial. After all you're supposed to pick the algorithm you like most, and after that you'll probably never touch it again.

madshi, another bug that may be related to the bug that James Freeman already reported, is that when you go into the madVR dithering settings and select "None" and apply it, then you close the madVR settings completely and open them up again, in the dithering settings there suddenly is no selection at all. So it seems madVR doesn´t remember the "None" dithering selection.
Ok, will have a look.

Well, something got "smoother", because now I can just barely run A4 with SmoothMotion On with 1080p 10-bit encodes. Before I could not, a drop fest. Not so with ED11 and SM. Without SM, like a champ.
Well, ordered dithering is ever so slightly faster than the old default of multi-colored random dithering. But the difference should be very small. I guess you're probably right on the edge of it working or not working, so very small changes can make a difference for you.

Image Up/Down-scaling is DXVA. If I don't remember it wrong, madshi ever mentioned that HD4000 GPU contains HW Lanczos4 scaler...
Intel's HW scaler is the reason why I added DXVA scaling as a scaling option in the first place. I do think it's the best DXVA scaler, better than AMD and NVidia. However, madVR's Lanczos AR is still better. E.g. madVR produces high bitdepth output, while Intel's scaler is limited to 8bit output (ouch), and that's only one of the differences.

Well for something like Argyll CMS, I would think mono/static would be optimal for taking repeatable dE measurements on color patches.
I have asked Graeme about mono vs dynamic and he wasn't sure about it himself. For now madTPG enforces mono colored ordered dithering, ignoring the madVR settings. However, static vs dynamic is taken from the settings. Maybe I should enforce that, too, but I guess we should first do some tests to check which is really better...

I could be wrong, but isn't madTPG supposed to just use what madVR normally uses? (Video LUT and 3DLUT toggles aside) In other words, if you change the madVR settings, madTPG will use those settings as well. I imagine it's generally best to calibrate and profile using the same settings you'll be using for viewing.
madTPG does use all the madVR settings - except dithering. Ordered dithering produces very good results for static test patterns, so that's what madTPG is using. Calibration is all about accuracy and when doing the measurements, we want the best accuracy we can get. For static "one color" test patterns ordered dithering does that best with the most even noise distribution, so that's what madTPG is using. For real movie playback the situation is different. There error diffusion produces better results, IMHO. But not for single color test patterns.

Isn't OD32 the version with the most randomness?
No, it's the one with the lowest randomness.

I just wanted to say that I really like the new options for dithering, and I am glad that the ordered dither builds made it in.
I initially discounted them, but that's because I was looking for "optimal" image quality and pattern avoidance.

I'm actually seeing better performance with ordered dithering than random dither, and while there is a possibility of introducing patterns into the image, it's considerably reduced in the "dynamic" version.
So for roughly the same performance as random dither, the ordered dither option is a big image quality improvement.

When you consider how much lower the performance requirements are for Ordered Dithering, and how low the visibility of dither should be in 8-bit, I may end up using that now.

And I think the other options for dithering are "just right" even though it adds another section to the options window, though some people here might prefer a "mono/color/opposite" option, rather than "color on/off".

Standing back from it all without getting bogged down by which algorithm is "best", if you look at the results in 3-bit, which obviously exaggerates things, it's ridiculous how much better the new dither options are, especially if you compare "no dither" to any of the new options in 3-bit.
Agreed. About multiColor vs oppositeColor: Those few users who prefer multiColor over oppositeColor also prefer mono over multiColor. So I don't think it makes any sense offering a multiColor choice. 99.9% of all users seem to favor either monoColor or oppositeColor out of the 3 possible options.

[ryrynz]

I guess random dither might drop off then? Nobody seems to like it over anything else that's been submitted so far. I do have an issue with ordered dithering with FSE enabled however.. added to the bug tracker.

[leeperry]

ED11 dynamic
I watched the latest Riddick yesterday evening with dynamic ED11, PQ was grandiose!

I'll be doing more criticial observations later today and will report back.

Intel [..] DXVA [..] it's the best DXVA scaler, better than AMD and NVidia.
BTW, Quicksync used to only work with i3/i5/i7's but Intel has apparently unlocked it for all Haswell Celeron's & Pentium's in the latest drivers FWIR :)

My G3420 is actually overkill for mVR with the HD7850 IME and software decoding IME but I wanted DDR3-1600 official support. Their cheapest Celeron's would be more than fast enough IMHO, they make it to the top of this bang/bucks comparison (http://www.cpubenchmark.net/cpu_value_available.html#).

[Soukyuu]

You may want to make sure that your screen is actually capable of displaying more than 6bit and doesn't use dithering to increase this to 8bit, because that would also explain why you don't see much difference between 6bit and 8bit.When I last searched the net, I only found information stating my LG W2442PA should be 8Bit (http://www.prad.de/en/monitore/review/2009/review-lg-w2442pa-part6.html#Image), but it has problems with smooth gradients according to the same test, so maybe that's why I don't see an improvement.

Searching again, I found this (http://www.jordansmanuals.com/ServiceManuals%5Clg%5Cmonitor%5CW2442PA%5CW2442PA%20Service%20Manual.pdf), though. My monitor model suffix is -SF, but it's also a TN panel, so it's probably the same...
Do I set my monitor to 6Bit for best results? Or will it still dither madVR's output from the dithered 6Bit -> it's own dithered 8Bit?

[madshi]

@Soukyuu, just try different bitdepths (8bit, 7bit, 6bit) and check which produces the smoothest overall results. I'd suggest to test with the smallramp.ytp test pattern zoomed to fill the screen. Don't use DXVA scaling for this test, just to be safe.

[Soukyuu]

Where do I get those patterns from? I tried starting the TPG but all I see is a black screen (didn't someone reported something similar?)

[madshi]

Look for "madTestPatternSource" in the first post of this thread.

[Soukyuu]

Ok, thanks for your patience. I don't seem to see a difference between setting my panel to 6 vs 8bit, but at least I now see the banding when turning dithering off with 6bit. Using 8bit output with dithering off shows no difference, so I guess my panel takes over dithering after all (so native = 6bit).

edit: actually, setting it to 8bit makes the gradient smoother after all... 8Bit it is :P

Ordered dithering looks much calmer than random even with pattern changing every frame, so I'll go with that.

[TheLion]

Mathias,

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 :)

[*Touche*]

I agree with others that ED2 (ED11) dynamic is great. So, ED2>ED1>OD>RD, all with (opposite)color + dynamic. Tested in 3/4 bit this time since in 8 bit it's too hard to tell apart. Really happy that I can drive 720p24 content with Jinc3+AR chroma/luma, low debanding, ED2+col+dyn, no trade quality, with just a A10-5800k. Hope to get a 270X soon and see if I can push some NNEDI bliss. Great work madshi!


Earlier I have been looking for benchmarks of MadVR, especially with the newer NNEDI3, I didn't find any. So I decide to make my own and share with this community. This is for a 1920x1080 video upscaled to 2560x1440 (monitor res)

That looks interesting.

[DarkSpace]

Mathias,

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 :)
Thanks for posting this. I tried installing the beta driver, and now I also can use NNEDI3 (barely, though)!

[Ver Greeneyes]

madTPG does use all the madVR settings - except dithering. Ordered dithering produces very good results for static test patterns, so that's what madTPG is using. Calibration is all about accuracy and when doing the measurements, we want the best accuracy we can get. For static "one color" test patterns ordered dithering does that best with the most even noise distribution, so that's what madTPG is using. For real movie playback the situation is different. There error diffusion produces better results, IMHO. But not for single color test patterns.Okay, sounds good :)

No, it's the one with the lowest randomness.Oops! Nevermind me then.

[seiyafan]

I will test the 270x this weekend against 770. Game wise the 280x has comparable performance to 770. However I suspect to see surprises with 270x due to its higher OpenCL performance. So it's going to be even more interesting.
Meanwhile feel free to make your own speculations. :D

By the way, for 770 I had to use 327.23 (and even with that I got green screens if deinterlacing was running), for AMD What's the most stable driver to use? 14.2 Beta 1.3 as someone mentioned earlier?

[noee]

What's the most stable driver to use? 14.2 Beta 1.3 as someone mentioned earlier?

I tried 14.1 w/madVR with my older 6570 and with a Kaveri system (only had access to it for a few hours) and didn't really notice any differences to 13.12. Had other issues with 14.1 not madVR-related. Haven't tried 14.2 yet...

I'm hoping to get another Kaveri system soon that I can spend some time with to see how far it will go with madVR.

[aufkrawall]

Does activating the trade for quality option "don't rerender frames when fade in/out is detected" help?

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.

[leeperry]

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.

I'd love a filename tag for dithering at some point if that's not too OCD'ed ^^

:thanks:

[*Touche*]

Just ran a few more tests:
-colorful noise still looks uneasy to watch
-dynamic is still very obvious

In 8 bit or lower?


I will test the 270x this weekend against 770. Game wise the 280x has comparable performance to 770. However I suspect to see surprises with 270x due to its higher OpenCL performance. So it's going to be even more interesting.

Oh, great, I'll get to see what's possible in advance :)

[GREG1292]

[QUOTE=*Touche*;1670882]In 8 bit or lower?

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.

[YxP]

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. Remarkable work madshi.

[James Freeman]

For now madTPG enforces mono colored ordered dithering, ignoring the madVR settings. However, static vs dynamic is taken from the settings. Maybe I should enforce that, too, but I guess we should first do some tests to check which is really better...

madTPG does use all the madVR settings - except dithering. Ordered dithering produces very good results for static test patterns, so that's what madTPG is using.

Thanks for clearing that out.
I got the i1 Display Pro, I will gladly help (choose dynamic vs static).
What to look for?

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. Remarkable work madshi.

Same here.
I really like the OD32 option too (better than ED option 1 [AD4]), and glad that its the default for madTPG.
I really hope there will be NO cut back on the available options even though madshi already stated that there will be.


I settled on 5bit with my projector ED11 OCD
can see a difference on a large screen.

I think too that 5-bit is enough to fully enjoy the movie.
But I wonder why not go 8-bit if the projector/display can do 8-bit?
Is there a substantial performance gain in 5-bit?

[cyberbeing]

I think in dynamic mode it's clearly better than random dithering. At least that's my impression. I don't like ordered dithering in static mode, though.
madshi, I'd be interested in hearing your subjective impression on mono dynamic vs color dynamic with ordered dithering? Though with the 'options' being global, I guess it cannot change to something else anyway.

Have you tried ED11 dynamic vs A4 static yet, btw?
Not yet. So far I've only been doing some quick 8bit tests to see if I was bothered by the noise energy of ED11 mono dynamic, like I was with A4 dynamic.

This is definitely still the case with A4. I take notice of the dynamic dither rather quickly in 8bit, which is an instant fail. I tested this to re-confirm I still prefer A4 as mono static.

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.

That would cost more work and while I see that it would be "nice" I don't consider it really crucial.
Okay, I guess I'll just workaround it with profiles. At the moment, I cannot say I prefer the same two set of 'options' for any of the dithering algorithms.

I have asked Graeme about mono vs dynamic and he wasn't sure about it himself. For now madTPG enforces mono colored ordered dithering, ignoring the madVR settings. However, static vs dynamic is taken from the settings. Maybe I should enforce that, too, but I guess we should first do some tests to check which is really better...
I'd suspect having different patterns for each measurement, could potentially introduce minor error. Though at the end of the day, it likely highly depends on the display and measurement instrument behavior. Instrument measurement speed, instrument measurement surface area in pixels, instrument luminance sensitivity, display response time, display post-processing, etc.

[James Freeman]

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.

I'm really glad to hear it especially from you..
You were one of the last people that still liked AD4.
You may even be the last person give the word before madshi kills it. :D
Please take this comment lightly (not seriously)...;)


I'd suspect having different patterns for each measurement, could potentially introduce minor error.
So you think Static will be better for madTPG?

[cyberbeing]

So you think Static will be better for madTPG?

Who knows, like madshi mentioned, some tests would need to be done. It shouldn't be that hard to figure it out by just taking some measurements with spotread and checking repeatability and dE.

[Shiandow]

I'd suspect having different patterns for each measurement, could potentially introduce minor error. Though at the end of the day, it likely highly depends on the display and measurement instrument behavior. Instrument measurement speed, instrument measurement surface area in pixels, instrument luminance sensitivity, display response time, display post-processing, etc.

I think that static dithering has the same amount of error except it becomes harder to detect since it doesn't change. If you want to know how 'precise' MadVR is at displaying a certain colour it would be better to test with dynamic dithering. Although this all depends on how good those instruments are at handling temporal noise.

[*Touche*]

I got the i1 Display Pro, I will gladly help (choose dynamic vs static).
What to look for?


Put it on continuous reading with something like HCFR, put on a pattern and change dithering modes. Look for any value changes coming from the meter.

[James Freeman]

I did a few "Report Uncalibrated" intermittent runs: Static, Dynamic, Static, Dy...etc..

I (the meter) see no difference at all.
EDIT: Note that MadTPG is only 8-bit, (read my next post).

--------------------------------------------------------------------------------
Report on uncalibrated display device
--------------------------------------------------------------------------------
Command line:
dispcal.exe
-v2
-dmadvr
-c1
-yn
-Ibw
-R


Setting up the instrument
Product Name: i1Display3
Serial Number: I1-13.A-02
Firmware Version: v1.03
Firmware Date: 05Jun12
Created MadVR window
Place instrument on test window.
Hit Esc or Q to give up, any other key to continue:
Measured display update delay of 37 msec, using delay of 155 msec
Patch 3 of 3

Measuring VideoLUT table entry precision.
Patch 9 of 9

Patch 9 of 9

Patch 12 of 12

Patch 12 of 12

Uncalibrated response:
Black level = 0.0548 cd/m^2
50% level = 32.96 cd/m^2
White level = 141.75 cd/m^2
Aprox. gamma = 2.10
Contrast ratio = 2586:1
White chromaticity coordinates 0.3272, 0.3553
White Correlated Color Temperature = 5716K, DE 2K to locus = 11.4
White Correlated Daylight Temperature = 5716K, DE 2K to locus = 8.2
White Visual Color Temperature = 5395K, DE 2K to locus = 11.0
White Visual Daylight Temperature = 5505K, DE 2K to locus = 8.0
Effective LUT entry depth seems to be 11 bits
Black drift was 0.003581 DE
White drift was 0.066035 DE
The instrument can be removed from the screen.
--------------------------------------------------------------------------------
Report on uncalibrated display device
--------------------------------------------------------------------------------
Command line:
dispcal.exe
-v2
-dmadvr
-c1
-yn
-Ibw
-R


Setting up the instrument
Product Name: i1Display3
Serial Number: I1-13.A-02
Firmware Version: v1.03
Firmware Date: 05Jun12
Created MadVR window
Place instrument on test window.
Hit Esc or Q to give up, any other key to continue:
Measured display update delay of 37 msec, using delay of 155 msec
Patch 3 of 3

Measuring VideoLUT table entry precision.
Patch 9 of 9

Patch 9 of 9

Patch 12 of 12

Patch 12 of 12

Uncalibrated response:
Black level = 0.0548 cd/m^2
50% level = 32.96 cd/m^2
White level = 141.49 cd/m^2
Aprox. gamma = 2.10
Contrast ratio = 2581:1
White chromaticity coordinates 0.3272, 0.3553
White Correlated Color Temperature = 5717K, DE 2K to locus = 11.4
White Correlated Daylight Temperature = 5717K, DE 2K to locus = 8.2
White Visual Color Temperature = 5396K, DE 2K to locus = 11.0
White Visual Daylight Temperature = 5506K, DE 2K to locus = 8.0
Effective LUT entry depth seems to be 11 bits
Black drift was 0.001626 DE
White drift was 0.000000 DE
The instrument can be removed from the screen.
--------------------------------------------------------------------------------
Report on uncalibrated display device
--------------------------------------------------------------------------------
Command line:
dispcal.exe
-v2
-dmadvr
-c1
-yn
-Ibw
-R


Setting up the instrument
Product Name: i1Display3
Serial Number: I1-13.A-02
Firmware Version: v1.03
Firmware Date: 05Jun12
Created MadVR window
Place instrument on test window.
Hit Esc or Q to give up, any other key to continue:
Measured display update delay of 36 msec, using delay of 154 msec
Patch 3 of 3

Measuring VideoLUT table entry precision.
Patch 9 of 9

Patch 9 of 9

Patch 12 of 12

Uncalibrated response:
Black level = 0.0548 cd/m^2
50% level = 32.96 cd/m^2
White level = 141.57 cd/m^2
Aprox. gamma = 2.10
Contrast ratio = 2585:1
White chromaticity coordinates 0.3272, 0.3554
White Correlated Color Temperature = 5717K, DE 2K to locus = 11.4
White Correlated Daylight Temperature = 5717K, DE 2K to locus = 8.3
White Visual Color Temperature = 5395K, DE 2K to locus = 11.1
White Visual Daylight Temperature = 5505K, DE 2K to locus = 8.0
Effective LUT entry depth seems to be 12 bits
Black drift was 0.002041 DE
White drift was 0.000000 DE
The instrument can be removed from the screen.
--------------------------------------------------------------------------------
Report on uncalibrated display device
--------------------------------------------------------------------------------
Command line:
dispcal.exe
-v2
-dmadvr
-c1
-yn
-Ibw
-R


Setting up the instrument
Product Name: i1Display3
Serial Number: I1-13.A-02
Firmware Version: v1.03
Firmware Date: 05Jun12
Created MadVR window
Place instrument on test window.
Hit Esc or Q to give up, any other key to continue:
Measured display update delay of 36 msec, using delay of 154 msec
Patch 3 of 3

Measuring VideoLUT table entry precision.
Patch 9 of 9

Patch 9 of 9

Patch 12 of 12

Patch 12 of 12

Uncalibrated response:
Black level = 0.0547 cd/m^2
50% level = 32.96 cd/m^2
White level = 141.49 cd/m^2
Aprox. gamma = 2.10
Contrast ratio = 2584:1
White chromaticity coordinates 0.3272, 0.3553
White Correlated Color Temperature = 5717K, DE 2K to locus = 11.4
White Correlated Daylight Temperature = 5717K, DE 2K to locus = 8.2
White Visual Color Temperature = 5396K, DE 2K to locus = 11.0
White Visual Daylight Temperature = 5506K, DE 2K to locus = 8.0
Effective LUT entry depth seems to be 10 bits
Black drift was 0.000955 DE
White drift was 0.058878 DE
The instrument can be removed from the screen.
--------------------------------------------------------------------------------
Report on uncalibrated display device
--------------------------------------------------------------------------------
Command line:
dispcal.exe
-v2
-dmadvr
-c1
-yn
-Ibw
-R


Setting up the instrument
Product Name: i1Display3
Serial Number: I1-13.A-02
Firmware Version: v1.03
Firmware Date: 05Jun12
Created MadVR window
Place instrument on test window.
Hit Esc or Q to give up, any other key to continue:
Measured display update delay of 36 msec, using delay of 154 msec
Patch 3 of 3

Measuring VideoLUT table entry precision.
Patch 9 of 9

Patch 9 of 9

Patch 12 of 12

Patch 12 of 12

Uncalibrated response:
Black level = 0.0547 cd/m^2
50% level = 32.89 cd/m^2
White level = 141.49 cd/m^2
Aprox. gamma = 2.11
Contrast ratio = 2585:1
White chromaticity coordinates 0.3272, 0.3553
White Correlated Color Temperature = 5717K, DE 2K to locus = 11.4
White Correlated Daylight Temperature = 5717K, DE 2K to locus = 8.2
White Visual Color Temperature = 5396K, DE 2K to locus = 11.0
White Visual Daylight Temperature = 5506K, DE 2K to locus = 8.0
Effective LUT entry depth seems to be 10 bits
Black drift was 0.000427 DE
White drift was 0.076807 DE
The instrument can be removed from the screen.


Put it on continuous reading with something like HCFR, put on a pattern and change dithering modes. Look for any value changes coming from the meter.

I'll try and report.

[Shiandow]

The Black/White drift seems to change quite a bit.

[leeperry]

I settled on 5bit with my projector
Is that to say that your DLP can't spit out more than 5bit?

In 8 bit or lower?
8bit with a 32" LCD from a 80 cm distance in a pitch black room.

static dithering has the same amount of error except it becomes harder to detect since it doesn't change.
Exactly :)

[James Freeman]

madTPG Static Vs Dynamic Report:

i1 Display Pro, HCFR (continues measurement), 30% Grey Field from the AVS709HD, OD32 Static/Dynamic, Real 8-bit (no FRC) 4:4:4 AMVA display.
In 8-6 bit there is no deviation down to the thousand number (0.00X), no difference here.

Only in 5-bit and down I start to see the effect on the i1d3 (which might reflect what's happening beyond the thousandths decimal).
With Dynamic the meter jumps ±50K in Temperature (XYZ changing).
With Static the meter is more consistent.
From this test I can conclude that Static gives a more stable results, without the meter being confused (this is in 5-bit and lower).

Dynamic does not improve the measurement precision for i1D3 from what I've seen, just the opposite.
If the lower bitdepth tests reflect what can happen at precision beyond thousandths (8-bit), then Static is the way to go.

Unlike our eyes,
The i1D3 meter likes a stable picture (not the smoother one) without noise in lower bitdepth, and probably in high bitdepth too, but HCFR show only down to thousandths.

Static it is.


Disclaimer:
I'm not THE JUDGE, here or anywhere...
This whole post is IMO & experience only.

[aufkrawall]

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

[Shiandow]

Only in 5-bit and down I start to see the effect on the i1d3 (which might reflect what's happening beyond the thousandths decimal).
With Dynamic the meter jumps ±50K in Temperature (XYZ changing).
With Static the meter is more consistent.
From this test I can conclude that Static gives a more stable results, without the meter being confused (this is in 5-bit and lower).

Do you see the same kind of deviations if you measure with Static but at a different location?

[mzso]

Hello 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?

[aufkrawall]

Last time I tried I444 in 2012, it was working fine with madVR. Most likely something is wrong in your conversion chain.
Use Avisynth ConvertToYV24(matrix="rec709") and let x264 flag the stream corresponding.
You also need a splitter like LAV that doesn't ignore the flags.

[James Freeman]

Do you see the same kind of deviations if you measure with Static but at a different location?

With certain shades of grey and lower bit depth.
Though, I don't think the i1D3 is made for heavy patterned textures, I think it expects more uniform texture.

I've done some more testing,
It appears that the i1D3 is very sensitive and fast reacting to change.
The brighter the test image gets the faster the i1D3 reacts, so a highly dynamic image is definitely bad.

The difference is minor at higher bit depths, but to eliminate any chance of error I suggest Static.

[mzso]

Last time I tried I444 in 2012, it was working fine with madVR. Most likely something is wrong in your conversion chain.
Use Avisynth ConvertToYV24(matrix="rec709") and let x264 flag the stream corresponding.
You also need a splitter like LAV that doesn't ignore the flags.
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.

[cyberbeing]

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

Set the display mode to XYZ or RGB, highlight all cells (click upper left cell), open Edit menu -> copy, and then paste into a text editor.

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

[aufkrawall]

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