madVR - high quality video renderer (GPU assisted)

[JonnyRedHed]

:(

How about the new test build (see bottom of this post)? Does the problem still occur with that build?





With your latest test build, I'm sorry to say it does still have the black screen issue. After 2 videos x2 43min 1080p mkv tv show eps. It just froze the picture for a brief second and then went black, whilst in full screen. No madvr crash reporter or zoom player crash pop up window. I pressed 'esc' and after a few seconds it returned to windowed mode, the playing area is see thru to my desktop. The video paused ok when I click the playing area, and can start again, I can hear the audio. But the playing area remains see thru in windowed mode. If I try and go full screen again, the screen is just black but the audio plays and pauses ok. But needs zoomplayer restarting.

So I click close zoomplayer and reopen again to continue. It loses its place in the time line and restarts the video.

I only have the main plasma TV on via hdmi. The other two monitors are connected but not on. No other issues in windows as far as I know. And reverting again to 87.4 seems to remedy the issue.

*edit, in fact now its done it once, the times between further black screens is much shorter. I just continued viewing and within 10 seconds I got my 2nd black screen. Same again, no crash reporter or zoom player crashing bad enough for its prompt window. I press 'esc' and it returns to windowed mode where I then close and restart.

[leeperry]

OK gotcha on the lagom test pattern, the difference is very obvious.

It's a double-edged game to play around with low bit-depth options because afterwards the dither noise becomes very apparent, even in 8bit duh.

Anyway, I've played around with all the dithering options again and colored noise still feels very uneasy to watch, dynamic raises the noise floor way too much to my taste, A4 looks too noisy on 30fps 1080p video content but ED11 looks really good, OTOH the latter is too "polite" on 24p movies and I much prefer A4 and on either of them LL looks "smoother" but it lacks the EE of GL.

The EE I'm seeing is more than likely due to the gamma errors then I presume, but hey I'm no mastering house and I kinda like EE if it doesn't come with nasty white halos. I'll keep toggling the LL/GL option if there is no question that LL does it right(er), TYVM for implementing it BTW.

For the record, my TV runs a rather dark gamma curve.

[madshi]

With your latest test build, I'm sorry to say it does still have the black screen issue. After 2 videos x2 43min 1080p mkv tv show eps. It just froze the picture for a brief second and then went black, whilst in full screen. No madvr crash reporter or zoom player crash pop up window. I pressed 'esc' and after a few seconds it returned to windowed mode, the playing area see thru to my desktop. The video paused ok when I click the playing area, and can start again. But the playing area remains see thru in windowed mode.

So I click close zoomplayer and reopen again to continue. It loses its place in the time line and restarts the video.
Ok, there are still 2 things you could do to help find the cause of this problem:

(1) In the situation where playback doesn't work, anymore, create a freeze report (Ctrl+Alt+Shift+Break), and mail it to me. The freeze report should appear as a text file on your desktop. It might take a couple of seconds after you pressed those keys.

(2) Activate the madVR debug mode by double clicking "activate debug mode.bat". After doing this madVR will log everything down to a big log file on your desktop. Be careful, the file will grow very large very quickly. If it takes too long to reproduce the problem, it might make sense to stop zoomPlayer, delete the log file and try again. Otherwise the log file might grow too big (several GBs). Once the problem has occurred, stop zoomPlayer right away. Then zip up the log file (it will compress very well) and send it to me. If the log file is too big to send, you can delete everything until the last maybe 200MB of text. Of course you'll need a tool which can do that. E.g. the freeware HxD should be able to. Zipped up it should be less than 10MB, I think.

Thanks!

OK gotcha on the lagom test pattern, the difference is very obvious.
:D

[iSunrise]

...If your display can really only handle 6bit, then your display will do the rounding down. So madVR doesn't have to do that. In theory it should not harm if madVR already rounds down to 6bit, if your display can only handle 6bit, anyway. However, that's only true if the display handles the rounding down in *exactly* the same way as madVR. If it does it differently, having a rounding down in both madVR and in the display could reintroduce banding artifacts. Because of that versions v0.87.4 and older - and v0.87.7 and newer do not round down to 6bit, when using random dithering. Because it's not necessary and *might* introduce artifacts. When doing comparisons, if your display really can do 8bit, and if you set madVR to 6bit, this means that nobody is rounding down to 6bit, anymore, which means the final image quality will be better than a real 6bit display would look like.

Ordered dithering and error diffusion internally work totally differently. If you tell madVR to dither to 6bit with ordered dithering or error diffusion, you really only get 6bit worth of data. So if your display can do 8bit, but you tell madVR to dither down to 6bit, with ordered dithering and error diffusion you really get results which looks like a native 6bit display.

Basically this means that v0.87.5+6 are nice for comparison random dithering to ordered dithering and error diffusion, because all 3 algorithms produce a true 6bit look. All other builds potentially produce better image quality when using random dithering, but are not good for comparing random dithering with the other algorithms, when setting your display to a lower bitdepth than it really has.
Thanks.

Ok, let me try this again:

So what you wanted to avoid is letting madVR rounding down with RD, because that could interfere with the display "in the real world" instead of just simulating a 6bit display on higher bit displays (which would not suffer from such issues) and that experience would not necessarily be transferable to a real 6bit display.

So the solution for you is to only let the display round it down, instead of madVR and that´s why we now inevitably lose the ability to directly compare, but potentially gain a bit more image quality when we´re dealing with true 6bit(+FRC) displays.

OK, then I am all for it. No further explanations needed. As long as the 'None' option is reverted to the old behaviour, this should satisfy everyone.

[cyberbeing]

So you want some patches of a single 16-bit color that's in between two 8-bit values? I don't think that would work, because photoshop would take the gamma light average value, so gamma light would always perform better.

Photoshop just reads raw unmodified RGB values from the image. There is no concept of gamma when you write an RGB value to a bitmap. Color and gamma management is a separate layer which is transparent to the user, and does not effect RGB values written or read from the image.

You'd have to transform to linear light in photoshop before measuring the average, and that depends on what gamma curve you choose.

There is no gamma curve when you write raw RGB values to a bitmap.

Average how, though? Using simple math? That would produce wrong results. A value of 50% pixels with value 1 and 50% pixels with value 2 blended together in gamma light would produce 1.5, but not in linear light! Which means that 50%/50% is actually the incorrect solution for 1.5. Our eyes do not see that as 1.5!

No, that would produce correct results. Our eyes having a non-linear response is an entirely different matter. madVR does not post-processes video to be perceptually linear, it displays it as-is with optional gamma processing if the display gamma if not correct for linear display. If I open an 8bit bitmap encoded with R10-G10-B10, guess what, madVR displays R10-G10-B10 on your screen. Gamma is an abstract concept which is entirely distinct from the linear values encoded to an RGB computer image.

Gamma (Image) -> Gamma Light (Image & Processing) -> Gamma (Image) -> Display
Gamma (Image) -> Linear Light (Image & Processing) -> Gamma (Image) -> Display

Both should yield the same target of 1.5 in this case. The conversion from Gamma to Linear and back should be perfectly reversible. You should know this, since you done exactly this in madVR in the past. Remember back to our debates about having untouched gamma output in madVR years ago, and how it related to linear light conversions.

If you are saying you want linear in terms of the Human Visual System (subjective post-processing), rather than mathematically linear (8bit color) then you have something as follows which modifies the image:

Gamma (Image) -> Linear (Processing) -> Gamma (Image) -> Display

That's an entirely different goal, and if you do settle on including something such at that in a future release build, it should not be enabled by default since it would be considered a non-standard image modification rather than nominal display.

[leeperry]

BTW, I see that reading PNG/JPG/GIF with mVR & PotP works pretty well...with sRGB gamut mapping and all, yay :)

Is there any way to make a profile for still images in order to go 256 neurons for both chroma & luma? And why is mVR going 50Hz :confused:

Also, zooming in realtime with 64 neurons luma is pretty fast but 256 is sluggish, I guess this cannot be helped?

It feels a bit like being part of CSI when zooming small pictures with 256 neurons :devil:

[Shiandow]

Some may have a linear segment near black. Ok, that is a somewhat problematic, but I don't see an easy solution for that.


I think that should be reasonably easy to solve, since to simulate a linear segment you can just use the original values. The easiest (slightly hackish) way I can think of is to add


#define threshold round(depth*0.03928)/depth


and change the last line in the code to


return lerp(c0,low+(c1/depth),saturate(depth*(low-threshold)));


shouldn't use too many instructions (uses 3 more in my case). You should make sure that whatever you put inside the 'saturate' function is not between 0, and 1, although it isn't that big of a problem if it is.

[iSunrise]

Also, zooming in realtime with 64 neurons luma is pretty fast but 256 is sluggish, I guess this cannot be helped?
The zooming is directly related with how high your queues are, your processing settings and the performance of your graphics card. Also, if you increase the zooming steps in PotP, there is less need for madVR to process every small step and it should be faster. However, you would lose the ability to use a finer zoom, when you want to zoom into some detailed areas more clearly. All are basically trade-offs you have to decide for yourself.

[Ver Greeneyes]

There is no gamma curve when you write raw RGB values to a bitmap.Your monitor applies its nonlinear gamma to the image when it is displayed. The whole point of doing error diffusion in linear light is to counteract the nonlinear nature of what your monitor displays, by spreading the error in a way that statistically looks the same as the theoretical unrounded original (not so theoretical if you're comparing 1-bit through 7-bit to 8-bit). Therefore you'd have to do your averaging in linear gamma, then convert it back to display gamma, otherwise the different colors will be weighted incorrectly. But when you do that, you'll always get the best result if you use the same transform as madVR uses - which doesn't help answer anything.

Edit: I mean, all of that is assuming the implementation is working correctly. If you compare gamma light and linear light dithering in madVR by doing the averaging in linear light, and gamma light comes out better, then there's obviously something wrong. But it doesn't sound like there's any evidence for that. The only thing people are questioning is the exact transfer function used. For my monitor, which is calibrated to the Rec.709 transfer function except with an effective gamma of 2.23, obviously it would look best to use the Rec.709 transfer function with an effective gamma of 2.23 (good luck). But I can recalibrate if that really bothers me, so..

[6233638]

Fair enough. But how much visible difference will there be between 2.222 and 2.4...You're right that it's unlikely that there will be much if any visible difference whatsoever.

But I thought madVR was a no-compromise approach, and it would be better to be technically correct than "close enough".

Either way it's not really a big deal though.

[JonnyRedHed]

Ok, there are still 2 things you could do to help find the cause of this problem:

(1) In the situation where playback doesn't work, anymore, create a freeze report (Ctrl+Alt+Shift+Break), and mail it to me. The freeze report should appear as a text file on your desktop. It might take a couple of seconds after you pressed those keys.

(2) Activate the madVR debug mode by double clicking "activate debug mode.bat". After doing this madVR will log everything down to a big log file on your desktop. Be careful, the file will grow very large very quickly. If it takes too long to reproduce the problem, it might make sense to stop zoomPlayer, delete the log file and try again. Otherwise the log file might grow too big (several GBs). Once the problem has occurred, stop zoomPlayer right away. Then zip up the log file (it will compress very well) and send it to me. If the log file is too big to send, you can delete everything until the last maybe 200MB of text. Of course you'll need a tool which can do that. E.g. the freeware HxD should be able to. Zipped up it should be less than 10MB, I think.

Thanks!


:D

Ok will do, just got to wait for another black screen.

[iSunrise]

You're right that it's unlikely that there will be much if any visible difference whatsoever.

But I thought madVR was a no-compromise approach, and it would be better to be technically correct than "close enough".
In that case, madshi would need to let us decide, again. Otherwise neither 2.4 nor the current approach is the correct one, as it´s so highly dependent on the display. Theoretically we could test if we are even able to see a difference between these two approaches or we get a drop-down box (or use the already present one, like you suggested, which I support), where madshi would only have to add another one for the yCMS/3DLUT users.

CRTs will soon die off completely, the broadest user base has their PC monitors directly attached to their PC, only after that comes the additional TV user base. So, while madVR can also be used on TV displays, instead of PC monitors, it´s still a PC application where countless people are using their (2.20 gamma) sRGB monitors to watch movies.

[madshi]

So what you wanted to avoid is letting madVR rounding down with RD, because that could interfere with the display "in the real world" instead of just simulating a 6bit display on higher bit displays (which would not suffer from such issues) and that experience would not necessarily be transferable to a real 6bit display.

So the solution for you is to only let the display round it down, instead of madVR and that´s why we now inevitably lose the ability to directly compare, but potentially gain a bit more image quality when we´re dealing with true 6bit(+FRC) displays.
Yes.

No, that would produce correct results. Our eyes having a non-linear response is an entirely different matter. madVR does not post-processes video to be perceptually linear, it displays it as-is with optional gamma processing if the display gamma if not correct for linear display. If I open an 8bit bitmap encoded with R10-G10-B10, guess what, madVR displays R10-G10-B10 on your screen. Gamma is an abstract concept which is entirely distinct from the linear values encoded to an RGB computer image.

Gamma (Image) -> Gamma Light (Image & Processing) -> Gamma (Image) -> Display
Gamma (Image) -> Linear Light (Image & Processing) -> Gamma (Image) -> Display

Both should yield the same target of 1.5 in this case. The conversion from Gamma to Linear and back should be perfectly reversible. You should know this, since you done exactly this in madVR in the past. Remember back to our debates about having untouched gamma output in madVR years ago, and how it related to linear light conversions.

If you are saying you want linear in terms of the Human Visual System (subjective post-processing), rather than mathematically linear (8bit color) then you have something as follows which modifies the image:

Gamma (Image) -> Linear (Processing) -> Gamma (Image) -> Display

That's an entirely different goal, and if you do settle on including something such at that in a future release build, it should not be enabled by default since it would be considered a non-standard image modification rather than nominal display.
For dithering I'm not converting the image to linear light and then back to gamma light. This got nothing to do with all the conventional processing algorithms like scaling, gamut conversion, saturation adjustments etc which can be performed either in linear light or in gamma light. We're talking here about drawing an image in such a way that the dithering dots average together to the correct brightness and color. When you mix colors in an algorithm, you have to do that in linear light to get correct results. But this time it's our eyes which do the processing, so everything is different compared to the other processing algorithms.

But anyway, there's really no need to discuss this. Let your eyes be the judge. I can only interpret your comment in such a way that you haven't actually tried linear light dithering yourself yet. Please do the following very simple test: Use the latest test build (linear light 2), then set the display to 4bit, then show a smooth gray ramp (e.g. like this (http://www.lagom.nl/lcd-test/img/gradient-h.png)), then toggle between linear light and gamma light dithering and your eyes will tell you which algorithm is better. It's not even close.

Or let me make it simple: If what you're saying is true, then with 1bit dithering a gamma RGB value of 127,127,127 should be dithered with 50% 0,0,0 pixels and 50% 254,254,254 pixels. So tell me, do those 2 squares seem to have the same brightness to you?

http://madshi.net/ditherTest.png

The left square shows how madVR would dither the right square with 1bit dithering, with linear light disabled.

BTW, I see that reading PNG/JPG/GIF with mVR & PotP works pretty well...with sRGB gamut and all, yay :)

Is there any way to make a profile for still images in order to go 256 neurons for both chroma & luma? And why is mVR going 50Hz :confused:
To madVR everything looks like a video, so a profile can't see a difference between a still image and a video. Framerate/refresh rate depends on what the framerate reported by the splitter.

I think that should be reasonably easy to solve, since to simulate a linear segment you can just use the original values.
I didn't mean the algorithm. It's easy enough to make dithering use a linear segment. My point was that some displays are calibrated with a linear segment and some are not, some are calibrated with BT.1886, some with conventional black point compensation. So many variations, and I'm not sure if it makes sense to try to match the exact transfer curve. I'm thinking naively always using 2.222 might just be good enough.

But I thought madVR was a no-compromise approach, and it would be better to be technically correct than "close enough".
True. But then there is always a limit. E.g. pixel shaders only work in 32bit floating point per component. madVR stores the pixels only in 16bit buffers. So I can only do accuracy up to a certain point. Furthermore I need to balance usability vs. accuracy. If I wanted to make linear light dithering literally perfect, I'd have to add a way for the user to define the *exact* gamma curve his display is calibrated to (including black point compensation, BT.1886, exact black level etc). All of this would be a usability nightmare, without any *visible* benefits. I'm all for accuracy, but I'm not going to chase invisible quality improvements if they come at the cost of usability.

[e-t172]

Hey,

So I got frame drop/presentation glitches issues when using madVR with a 780 Ti. To be fair it's almost perfect but I still get at least one frame drop or other discontinuity every 10 minutes or so (it seems to happen at random times). I tried every combination of flushing settings/queue depths/use separate device for presentation/disable composition imaginable (well, almost) without any success. I'm out of ideas and asking for help.

Additional details:
- Playing 24p with smooth motion FRC to 60Hz (Smooth Motion is never supposed to drop or repeat any frames, right?)
- 780 Ti and not using any performance-hungry features (so I highly doubt it's a performance problem)
- Problem correlated with the "dropped frames" counter and/or the "presentation glitches" counter increasing
- All queues always look full and stable, except there is a small hiccup at the exact moment the glitch happens (even with very large queues)
- Latest madVR version (not a regression though - it's been happening for quite some time)
- Latest NVidia drivers
- Windows 7 x64

Ideas, anyone?

[Incriminated]

Try to check if your card operates within the normal range with tools like MSI-Afterburner.

Im with a 670, and i can see latest 334.** sometimes clocking down memory to minimum in the middle of the load for no reason. In games these produces "hiccups" like you explain.

[iSunrise]

...- All queues always look full and stable, except there is a small hiccup at the exact moment the glitch happens (even with very large queues)
- Latest madVR version
- Latest NVidia drivers
- Windows 7 x64

Ideas, anyone?
Personally, I would try the 327.23 drivers first, as the latest NV drivers currently can´t support (due to a bug) NNEDI3 for instance and most of the madVR NV users currently have to use this driver, where there are no such problems known to me. I also didn´t encounter such hiccups with the last driver releases, so this could also be a completely different issue, though.

Because if it´s even happening with very large queues, something else seems to interrupt your graphics card from doing it´s job. You could also try an update of DirectX through the online updater just in case.

Also, I would monitor the graphics card (with GPU-Z or MSI Afterburner) while you´re playing something just for testing purposes and look at the exact values when the hiccups happen.

[markanini]

Dialing down the output bits with random dithering looks great on not so great sources.

[pankov]

Hey,

So I got frame drop/presentation glitches issues when using madVR with a 780 Ti. To be fair it's almost perfect but I still get at least one frame drop or other discontinuity every 10 minutes or so (it seems to happen at random times).
....
Ideas, anyone?
e-t172,
your card is very powerful but since you didn't share your settings with us I'm guessing you've disabled all "trade quality for performance" option including "don't rerender frames when fade in/out is detected". Try enabling it and see if this eliminates the dropped frames.

madshi,
I was thinking about this option and I'm not sure if it makes sense at all but isn't it possible to only rerender frames one by one and substitute them in the queues one by one so if madVR runs out of time for rerendering all of them not to drop frames but to use the ones rendered at the lower debanding strength?

[leeperry]

To madVR everything looks like a video, so a profile can't see a difference between a still image and a video. Framerate/refresh rate depends on what the framerate reported by the splitter.
Right, but I'm sure you could easily detect that an "image source" filter is fueling the graph? This would allow for a still images profile and no black frames either.

mVR has set the bar so high that I can't find a single picture viewer that would match it......they all look terribly dated, with lanczos scaling at best :rolleyes:

[seiyafan]

I am not sure if this is feasible, for those of us with Intel processors, is it possible for MadVR to make good use of the idling iGPU when we have nVidia/AMD video card?

[Asmodian]

LL corrected dither looks amazing, when watching anime even 3-bit looks pretty good. At 4-bit (ED2 colored, dynamic) the image is only a bit noisy. Wow, think of those 256 color images from 1995, they could have looked so much better.

Using the linear2 build and playing with 1-bit dither I noticed colored dots even with "use colored noise" disabled, is this expected? I can see faint pink dots in the 1-Grayscale Ramp.mp4 even at 4-bit. The colored dots do become more numerous with "use colored noise" enabled. This is without my 3DLUT active; "this display is already calibrated" is selected.

EDIT: Ah! this is due to my gamma ramps. I am using overlay mode, of course, so both my 3DLUT or gamma ramps happen before dithering. At 1 bit any attempt to correct the white point by removing blue or adding red become little spots of color. This is actually a very nice way to visualize a calibration. :D
With "disable gamma ramps" enabled all extra colors go away. The 1-bit colored dither does manage to do a pretty good job hitting the white point too, amazing. :eek:

I am not sure if this is feasible, for those of us with Intel processors, is it possible for MadVR to make good use of the idling iGPU when we have nVidia/AMD video card?

To use the iGPU madVR would need to copy the video frames back off the iGPU after it was done and then copy it to the main GPU for display. This adds a lot of extra time and the iGPU is slow enough that this would probably add to rendering times vs simply using the dGPU.

[cyberbeing]

I can only interpret your comment in such a way that you haven't actually tried linear light dithering yourself yet.
Correct, I have not tested these recent linear light builds myself. I'll do so now.

Please do the following very simple test: Use the latest test build (linear light 2), then set the display to 4bit, then show a smooth gray ramp (e.g. like this (http://www.lagom.nl/lcd-test/img/gradient-h.png)), then toggle between linear light and gamma light dithering and your eyes will tell you which algorithm is better. It's not even close.
I tested this and Gamma dithering wins by a large margin in 4bit. Linear produces lots of banding and crushes colors near-black.

Source vs Gamma (http://screenshotcomparison.com/comparison/65824)
Source vs Linear (http://screenshotcomparison.com/comparison/65825)

Direct Links:
Source (http://i1.someimage.com/lAo0eFs.png)
Gamma (http://i1.someimage.com/BEW1Nfk.png)
Linear (http://i1.someimage.com/5Jkxu0o.png)


The left square shows how madVR would dither the right square with 1bit dithering, with linear light disabled.
I don't think using 1-bit or any lower bitdepth is the best to prove a point one way or the other. I mean with 1bit, sure gamma dithering (left) appears too bright, but linear dither (right) in the latest build appears too dark for what should be 50% gray (center).
http://i.imgbox.com/DfLz2C8F.png

[QBhd]

Linear Looks better to me on your two comparison links... just saying :)

QB

[Asmodian]

Wow, on my display Source vs. Linear looks much better than Source vs. Gamma too.

[seiyafan]

I got a question for all of you videophiles: what color temperature do you calibrate a computer monitor to? I calibrate mine in my office (with fluorescent lighting) to D65. At home I do the same thing but my room is lit with one CCFL (~3000k) bulb. Only today I question myself if I had been doing it wrong for over a decade. :o

[nautilus7]

I tested this and Gamma dithering wins by a large margin in 4bit. Linear produces lots of banding and crushes colors near-black.

Source vs Gamma (http://screenshotcomparison.com/comparison/65824)
Source vs Linear (http://screenshotcomparison.com/comparison/65825)


Linear Light looks better by far here as well...

[Ver Greeneyes]

I tested this and Gamma dithering wins by a large margin in 4bit. Linear produces lots of banding and crushes colors near-black.

Source vs Gamma (http://screenshotcomparison.com/comparison/65824)
Source vs Linear (http://screenshotcomparison.com/comparison/65825)So to me it looks like gamma light consistently brightens the source - 4-bit looks like the original but with brighter dots layered on top. Linear light actually looks closer in terms of average brightness, although because it introduces more darker dots it looks like the average 'error' is greater.

Near black, gamma light clearly wins for me as well, and I think that does have to do with the transfer function not including a linear section (where my monitor, which is calibrated to Rec.709, expects one). I suspect that the average would still be correct if my monitor was calibrated to a straight up power law transfer function, though I'd have to recalibrate to confirm it.

One other thing to keep in mind is that my test patterns are encoded using the Rec.709 transfer function, so the darkest bits go to black faster than with a power law. I don't think making a version that uses a power law instead would remove the effect, but it might make it less glaring (of course that does also imply that material encoded with the Rec.709 transfer function should be dithered using the Rec.709 transfer function).

[Asmodian]

I got a question for all of you videophiles: what color temperature do you calibrate a computer monitor to? I calibrate mine in my office (with fluorescent lighting) to D65. At home I do the same thing but my room is lit with one CCFL (~3000k) bulb. Only today I question myself if I had been doing it wrong for over a decade. :o

Personally I go for D65 too and I also have CCFL but keep my viewing room only indirectly lit by them. Having tested the room lighting white point compensation option in various calibration software over the past five or so years I do not like how they end up looking. I think most of this work around color theory was based on matching colored prints on various kinds of paper under different lighting conditions to on-screen images. For movie watching I notice I adapt to the screen white point quite quickly and even D65 is warmer than most un-calibrated screens. Somehow my brain seems to think the coolest white it can see is "white" so daylight should not be cooler than my white point. :).

edit: actually I calibrated to the rounded D65 that BT.709 uses, x0.3127 y0.3290

[cyberbeing]

I don't know what to say, the difference is strong in favor of the Gamma screenshot when viewed on my CRT. Linear dithering must not get along with my calibration at all.

Edit, checked into this:

With my display calibration enabled, the Gamma screenshot is perfectly smooth and a near identical match to the Source screenshot. Linear screenshot has banding.

With my display calibration disabled, the Linear screenshot is perfectly smooth and a near identical match to the Source screenshot. Gamma screenshot has banding.

Rather amusing, but this actually makes logical sense in a way. It just means Argyll CMS has done an excellent job of calibrating my display for perceptually linear display. Double checked, and it seems this past calibration I went back to using an ambient light scaled BT.709 curve (-g709 -f1.0 -a32.0) instead of BT.1886 (-G2.4 -f0). On my CRT, the natural gamma response is such that both usually end up calibrating to a curve which is identical to L* across almost the entire luminance range, except near-black where BT.1886 & scaled BT.709 have similar special characteristics.

[seiyafan]

With my calibrated monitor which gamma setting is preferred? Pure power curve or BT .709/601?

[Asmodian]

Are you using windowed, windowed overlay, or FSE?

I notice different dither behavior if I let madVR dither after my calibration corrections (overlay) vs before them. I also have my screen calibrated close to BT.1886 but it is an IPS LCD. (dispcal -g2.4 -f0 -k0)

With my calibrated monitor which gamma setting is preferred? Pure power curve or BT .709/601?

Pure power

[seiyafan]

To use the iGPU madVR would need to copy the video frames back off the iGPU after it was done and then copy it to the main GPU for display. This adds a lot of extra time and the iGPU is slow enough that this would probably add to rendering times vs simply using the dGPU.

That clears it up for me, thanks!

[6233638]

I got a question for all of you videophiles: what color temperature do you calibrate a computer monitor to? I calibrate mine in my office (with fluorescent lighting) to D65. At home I do the same thing but my room is lit with one CCFL (~3000k) bulb. Only today I question myself if I had been doing it wrong for over a decade. :oAll displays should be D65 for accurate image reproduction.

I use D55 fluorescents for task lighting, because I prefer a pure white light to work under, and 3000K halogens for ambient light in the evenings.

Recently I have been using f.lux (http://justgetflux.com/) on my display, which gradually transitions the display to ~3400K in the evenings, but I have madVR bypass it if I'm going to watch a film, as I care about accurate color reproduction with them. (note: if you're going to use f.lux, put it in safe mode or it will cause dropped frames during playback)

[markanini]

Linear appears "black-crushed" but is smoother than gamma somehow.

[Ceremony]

I recently got a the DLP projector BenQ W1070. It employs a single Texas Instruments DarkChip3.

Naturally, with projectors like these, one doesn't get the full 24bit depth and instead very noticeable dithering.

My question now is how to configure madVR to work and look beautiful. How can i easily determine its bit depth and configure madVR accordingly, so that it takes care of the dithering and not the projector?

[leeperry]

my display calibration
8bit 3x1D CLUT you mean? Over a 10bit VGA analog connection to a CRT?

Here's for the drastic improvement with LL on my rig, I've got a gamut mapping PS script enabled in PotP and the TV has been calibrated to D65 in its OSD, the GPU CLUT isn't used:

Source (http://someimage.com/YzY6LoQ)
Gamma (http://someimage.com/bRianrX)
Linear (http://someimage.com/cxOhsWU)

I'm not a big screenshot scrutinizer though and I still very much prefer GL in movies.

[Asmodian]

I think a lot of displays have very different behavior near black. If I remember right I have a gamma of 1.86 0-5% and ~2.2 5-10%. I will have to measure mine again as the linear looks very good, the detail/resolution gets low near black because the dither is fairly sparse (like my 2010 LG plasma TV) but the average brightness looks very good. Maybe it is a black level effect? Mine is not as low as I could wish. :(

At 1-bit the grayscale ramp looks much too bright on my screen if that means anything. :p

[Ver Greeneyes]

Here are versions of my test patterns encoded with x^0.45 for the gamma function (the ones in my signature use Rec.709). I have to admit, the difference is bigger than I expected! Of course using 0.45 directly is closer to sRGB than Rec.709 so maybe I shouldn't be so surprised. But they go to black much more suddenly than the patterns in my signature, which looks weird to me (but maybe that's because they don't match my Rec.709 calibrated monitor).

grayscale (http://www.mediafire.com/?19mg4rec9116ejq) (8-bit (http://www.mediafire.com/?jx4srcowi8yx3wf))
colored (http://www.mediafire.com/?fyjsf1j76pp1wf6) (8-bit (http://www.mediafire.com/?ce6c4d684fxxc5g))

madshi, did you ever try out Rec.709 or sRGB for the transfer function used for linear light dithering? Here they are again in shader-friendly form:

Rec.709:return (gammaValue < 0.081 ? 0.2215435 * gammaValue : pow(0.9099181 * (gammaValue + 0.099), 2.222222));
sRGB:return (gammaValue < 0.03928571 ? 0.07738015 * gammaValue : pow(0.9478673 * (gammaValue + 0.055), 2.4));

I suspect either of these will look much better on my monitor, but maybe I should just bite the bullet and recalibrate to a different target..

[Asmodian]

I notice a band near black in the top of your new grayscale video but not the bottom one?

[cyberbeing]

8bit 3x1D CLUT you mean? Over a 10bit VGA analog connection to a CRT?
Yes, but they are 16bit 3x1D CLUT however NVIDIA chooses to handle it. With your images I see a bigger difference in brightness, but the LL version still has strong banding while the GL version is perfectly smooth with my calibration enabled. Disable calibration and it flip-flops. I just hope there will always be a toggle. Interesting phenomenon either way. It must go back madVR assuming an inverse power-curve for linear light, rather than a BT.709 or BT.1886 curve as others have mentioned. Both those curves usually end up with a gamma around 1.9 near-black.

[Ver Greeneyes]

I notice a band near black in the top of your new grayscale video but not the bottom one?They should be identical.. Certainly there's nothing in my program that would cause asymmetry in the colors. Are you watching it at 100% zoom? The only thing I can think of is that maybe on one side the pattern overlaps differently with ED's 16x16 pixel blocks, and this causes an artifact.

[MistahBonzai]

I tested this and Gamma dithering wins by a large margin in 4bit. Linear produces lots of banding and crushes colors near-black.

Source vs Gamma (http://screenshotcomparison.com/comparison/65824)
Source vs Linear (http://screenshotcomparison.com/comparison/65825)

Direct Links:
Source (http://i1.someimage.com/lAo0eFs.png)
Gamma (http://i1.someimage.com/BEW1Nfk.png)
Linear (http://i1.someimage.com/5Jkxu0o.png)


Not sure if this is useful..however, here is how I saw the comparisons between linear and gamma:

Viewing them via Screenshot Comparison I was positive something was amiss. Linear was noticeably smoother than gamma - banding in gamma was more noticeable in the darker region. The dithering seemed to extend right up to the black edge. It was in reverse to what you claimed to see - to the point I was going to ask that perhaps you had reversed the images.

I downloaded and viewed them in the Picasa image viewer. At native resolution I had the same impression. Then I zoomed..it was very apparent that the linear shot had quite severe banding while gamma remained fairly smooth. I figured it was due to a resolution mismatch but it doesn't appear to be as regardless of the zoom factor it was apparent that gamma was smoother and the transition to black was m ore linear. So there ya have it.:confused:

Sony KDL 40W3000 (1080P 40" LCD with 10-bit panels,sRGB full range /ITU 709 inputs and extensive calibration capabilities). Visually 'calibrated' with professional test images to BT.709/2.25 gamma target. Not perfect but I continually cross check it at every opportunity and have not found any display discontinuities.

[cyberbeing]

it was apparent that gamma was smoother and the transition to black was more linear. So there ya have it.:confused:
No that sounds about right, considering my results with/without calibration.
The phenomenon is likely similar to what is described at the following gamma correction tutorial.
With linear dithering, there are just not enough tones near-black to maintain smoothness when being brightened by my near-black calibration.
http://i.imgbox.com/AqmRj5Zh.png
Link (http://www.cambridgeincolour.com/tutorials/gamma-correction.htm)

General conclusion: Linear light dithering is unsuitable for use with a GPU gamma ramp enabled, or any other adjustments applied after madVR performs dithering. If I use Overlay mode with madVR applying my gamma ramp via shaders, there is no issues with linear light dithering (as expected). Unfortunately, this is not as practical for madVR to do with Windowed or FSE mode.

@madshi did anything ever come of that hybrid 8bit 3DLUT + attached 16bit RGB Gamma ramp (for madVR to load via shaders) format you were talking about long ago with Graeme? I haven't been paying attention to recent developments. Otherwise, maybe it would be useful to have a special toggle to have madVR disable the active GPU gamma ramp and reload it via madVR shaders with Windowed and FSE mode as well. Last time I tested this though (long ago), I had superior results with my GPU's hardware gamma ramp compared to madVR applying the ramp via shaders.

[James Freeman]

madshi,
Strange... I can still change dithering depth from the menu with Random Dithering (it takes effect).
Isn't that supposed to be gone with the latest LinearLight2 test build?

Its about Dynamic/Static dithering and how they eye perceives the apparent gamma curve.
There's only one scientific reason that comes to my mind why dynamic dithering would produce a different gamma curve compared to static dithering: Which is that your display isn't able to reproduce dynamic dithering correctly.
Maybe your display is too slow, or maybe Overdrive is overcompensating, or something like that.

I don't think my display is too slow (OD is completely off) for 24fps (42.7ms).
Try the same test in this post (http://forum.doom9.org/showpost.php?p=1672549&postcount=24550) but with 2-bit.
I don't believe you can't see the gamma change when the video is Playing vs Paused (Dynamic vs Static) with LL.
If low bit depth reflects what is happening in 8-bit but to a lesser degree (like we tested dithering so far), clearly a gamma of 1/0.45 LL is not suited for Dynamic dithering.
In comparison images you can clearly see that 1/0.45 is perfect for static images, but no one seems to thoroughly test LL with Dynamic dithering in real playback (ie, not a screenshot).


I'm sorry to be a "pain in the neck" and post this over and over again, but in my experience this is a real problem.
Can someone else please try this experiment and report if they can see gamma difference between Paused vs Playing video in LL.

Thanks.

[Asmodian]

With linear dithering, there are just not enough tones near-black to maintain smoothness when being brightened by my near-black calibration.

I think you are also mixing linear light dither and linear light encoding. Dithering always uses the shades from the Gamma Encoding bar. It is only the ratio of, for example, 18 and 19 required to approximate a gamma light value of 18.5 that is determined in linear light, not the actual shades used.

I too believe that the post-dither changes caused by GPU gamma ramps can cause issues with dither. However, I do not see how it would always be worse with linear dither vs gamma dither. GPU ramps can cause issues with either gamma, linear, or both. They can cause other issues too; some people see banding after the GPU gamma ramps at 8 bit.

[cyberbeing]

I think you are also mixing linear light dither and linear light encoding. Dithering always uses the shades from the Gamma Encoding bar. It is only the ratio of, for example, 18 and 19 required to approximate a gamma light value of 18.5 that is determined in linear light, not the actual shades used.
I'm just saying that something similar appear to be going on. With that 4bit dithering comparison madshi requested, linear light does not distribute enough of the available tones steps near black, and crushes blacks slightly not all unlike what occurs with linear light encoding.

Source = X0->X8 the image has values of 0->3.
Gamma = X0->X8 the image has avg values of 0->3.
Linear = X0->X8 the image has avg value of 0!

Source = X9->X16 the image has values of 4->6.
Gamma = X9->X16 the image has avg values of 4->6.
Linear = X9->X16 the image has avg values of 1->2.

Source = X19->X32 the image has values of 7->12.
Gamma = X19->X32 the image has avg values of 7->12.
Linear = X19->X32 the image has avg values of 3->7.


Source = X33->X64 the image has values of 13->22.
Gamma = X33->X64 the image has avg values of 13->22.
Linear = X33->X64 the image has avg values of 8->20.

Source = X65->X96 the image has values of 23->33.
Gamma = X65->X96 the image has avg values of 23->33.
Linear = X65->X96 the image has avg values of 21->33.

X = X coordinate in pixels

This just becomes 10x worse when my calibration attempt to brighten near-black tone steps which just do not exist with linear light dithering. It takes ~96 pixels on that gradient before linear dithering finally catches up and matches the source again at an RGB value of ~33. These RGB values between 0-32 are where my calibration curve is most aggressive, which makes it rather problematic if tones are missing.

[Asmodian]

I don't think my display is too slow (OD is completely off) for 24fps (42.7ms).
Try the same test in this post (http://forum.doom9.org/showpost.php?p=1672549&postcount=24550) but with 2-bit.
I don't believe you can't see the gamma change when the video is Playing vs Paused (Dynamic vs Static) with LL.
If low bit depth reflects what is happening in 8-bit but to a lesser degree (like we tested dithering so far), clearly a gamma of 1/0.45 LL is not suited for Dynamic dithering.
In comparison images you can clearly see that 1/0.45 is perfect for static images, but no one seems to thoroughly test LL with Dynamic dithering in real playback (ie, not a screenshot).

I just tried that test and I really cannot see a difference in gamma at 1 bit, 2 bit, or 4 bit between playing and paused ED2 mono dynamic. I think you have to accept it is an artifact of your display, do you have another screen you could test on?

[jkauff]

Sorry to interrupt the dithering discussion, but I noticed a puzzling occurrence on one particular DVD. The profile I use for standard DVDs using the latest madVR typically pushes my GTX 770 to about 90% load. Playing back this one b&w video, however, causes the load to drop down to 45% about once every minute, then it returns to normal. Playback looks fine--I just can't understand what's causing the drop in GPU load. Image doubling is enabled, BTW, and the fact that the drop is almost exactly 50% makes me wonder if the image doubling is involved.

Again, not a problem, I'm just curious.

[MistahBonzai]

In LL or GL the dark shades are brighter when paused (or when Static dithering is used).


Yeah, I tried it with "Ordered Dithering" w/wo "change dithering with every frame" and saw an abrupt increase in the 'brightness' of the area from ~32(RGB) down to black 0(RGB) with dynamic. Conversely, when the video played there was a distinct loss of 'brightness' in the same area while the transition from ~32(RGB) to 0(RGB) became more abrupt with the '0' area expanding (dithering decreased close to 0 area while playing).

It also appeared that a slight brightness change occurred above the ~32(RGB) area when pausing/restarting the video. I attribute this to a 'redistribution' of the dithering while transitioning form pause to play (remember dynamic dither here).

What I saw on my 40" monitor was dithering extending toward 0(RGB) when paused while it contracted while playing.

While play/pause with static there was no visible change in 'brightness' either playing or paused. I tried to capture screen shots (alt+I) while playing but they were the same as when paused (as I expected).

Edit: Whoops..I see that you expected ED2 (mono) rather than OD (mono). Just went back and redid the tests as stated above and noted much the same results but at a lessor extent. I don't really have a working knowledge of the math but my eye tells me (notoriously untrustworthy) that it's all about the dither distribution. I don't think the actual pixel values are changing - just the amount/distribution of them. Of course if you averaged them over a suitably large area (like the eye does) then the 'brightness' changes..or does it really?

I'll never take 'dithering' for granted again :)

[Asmodian]

Linear = X0->X8 the image has avg value of 0.
Linear = X9->X16 the image has avg values of 1->2.
Linear = X19->X32 the image has avg values of 3->7.
Linear = X33->X64 the image has avg values of 8->20.
Gamma = X65->X96 the image has avg values of 21->33.

Gamma = X0->X8 the image has avg values of 0->3.
Gamma = X9->X16 the image has avg values of 4->6.
Gamma = X19->X32 the image has avg values of 7->12.
Gamma = X33->X64 the image has avg values of 13->22.
Gamma = X65->X96 the image has avg values of 23->33.

Source = X0->X8 the image has values of 0->3.
Source = X9->X16 the image has values of 4->6.
Source = X19->X32 the image has values of 7->12.
Source = X33->X64 the image has values of 13->22.
Source = X65->X96 the image has values of 23->33.

X = X coordinate in pixels

Are these averages done in gamma or linear light? The whole point is that 50% 1 and 50% 2 does not give a brightness equal to 100% 1.5. To approximate 100% 1.5 we need to use a few more 1s than 2s.

I think it is not missing shades in linear dithering vs gamma dithering it is just that madVR thinks the increase in brightness of 2 compared to 1 is larger than it actually is on your display. Do you have a very flat native response near black? Can you make out bar 17 in a black clipping test video?