madVR - high quality video renderer (GPU assisted)

[Graeme Gill]

Originally Posted by madshi

@Graeme, are ICC 3dluts hard limited to max 65x65x65 resolution? Would it be worth considering an option to create bigger ICC 3dluts? Maybe not for using them as actual ICC profiles, but it would allow producing a more exact 3dlut for madVR.

The limit is 256x256x256. But in practice it will start to get slow above 65x65x65. If it takes 1 minute at 65x65x65, it will be an hour at 256x256x256.

My thinking is that it might help adding a lot of grayscale measurements to prettify the measured gamma response. E.g. if you go hardcore and measure every 219 possible 8bit grayscale values, producing a 219x219x219 3dlut with a fully scanned gamma curve (and then converting it to a 256x256x256 madVR 3dlut) might noticably improve gamma measurements.

The general approach is typically to do per channel calibration at higher resolution (ie. dispcal goes up to 128 measurements with perceptual like distibution, so it's even closer than 256 steps at the dark end), and then heavily weight the cLUT in the profile by a run of samples down the neutral axis. I'm not sure there is much really to be gained here, without a careful analysis of where the errors come from. The repeatability of the instrument and the display are going to be in there somewhere I think, as well as the limitations of sampling and modelling.

[madshi]

Does it really make sense to do "per channel calibration" in addition to a big 3dlut? I mean a really big 3dlut can do the same as "per channel calibration". So why doing two separate calibrations?

[Graeme Gill]

Originally Posted by cyberbeing

You would need to explain what you mean by equivalence. Different calibration targets do not give equivalent final gamma response on the display with collink generated 3DLUT files.

The stated issue was that a calibration loaded in the graphics card VideoLUT was not behaving the same as one incorporated into the 3dlut. So to check whether these two situations are equivalent, it doesn't matter what the device profile and calibration curves are, it just matters that the two ways of using the calibration are equivalent.

I'm having a bit of trouble wrapping my head around this, and how I'm supposed to have control over the final gamma response measured on my display after a video passes through an Argyll 3DLUT.

By setting the source colorspace details, ie. how the video RGB values are to be interpreted as device independent color values.

Which knob do I need to turn to change the gamma output of an Argyll 3DLUT if I (for example) do not want to use BT.1886 or REC709, and no ICM device profiles exist from my intended target?

None at the moment. It's a matter of establishing why the current controls are not sufficient. - ie. why BT.1886 is either not a good place to start, or is not working as intended.
[Ideally there would be no knobs to turn - the result should be what the creator of the video intended. In practice, that's not entirely knowable or desirable, but it's something to start with.]

My problem with this in general, is you are assuming that a given video does not have a linear response on a particular display, and has a known gamma curve which need to be adapted to something else. I'm of the opinion that the video gamma should not be touched at all input=output. Only the absolute gamma response of the of the display at the end of the chain matters.

That's precisely what we're trying to avoid. Depending on the actual response of the display is fine if you have a studio grade display setup and available to you, but mere mortals have whatever displays they can afford. So the aim is to make a silk purse out of a sow's ear - we want to make the display we've got operate like it's a fully calibrated studio grade display using the device link/3dLut to do the work. And what's defining our perfect studio display is the Rec709 primaries of the source profile + the BT.1886 gamma curve pre-ended to it.

So is the ultimate conclusion that I should just give up on having control over the final gamma response of my display when viewing a video? If so, I don't like that...

See above. Yes, you should have control. You do have control - it's just not via the display calibration curves. If the current control is not satisfactory, and you are able to illustrate how and why it is not, then I'll fix it. I'm already contemplating changing some of the details to improve usability.

I know yesgrey had mentioned dithering before in relationship the processing he did for the creation of 3DLUT files, was he talking about madVR then? Are you positive that his high internal bitdepth pre-processing didn't include dithering? The post is somewhere here on Doom9. His latest

There doesn't seem to be any mention of it in the Manual.txt. It could be that there is an image processing application associated with yCMS that does this. The "denoise" may be some sort of roll off curve to push noise down below black.

[madshi]

yCMS does not use dithering, never has, never will. Technically not possible.

[Graeme Gill]

Originally Posted by cyberbeing

I had forgotten about the 3D gamut projection. Bright green tones are indeed missing compared to Rec709 (white wireframe).
GDM-F520 3D Gamut

Yes, the gamuts are a similar size, but the primaries are in slightly different places.

I have long had an idea on how to fix this type of problem, at a slight cost to brightness, that would work really well in a full screen Video context. I'll have to look into it a bit further down the track.

My preference is usually to have a gamma curve which goes from somewhere in the range of 1.9-2.2 near-black, ~2.4 in midtones, and ~2.6 in highlights. When I scale a REC709 curve to 32 lux ambient light, that is basically the end-result on my GDM-F520. Recently I've been testing out BT.1886, but still think I prefer the characteristics of the dispcal scaled REC709 curve instead. What all this ultimately comes down to is that I'm just very picky about the final gamma response of my display, and I don't like loosing control and flexibility for the end result.

Right, I understand. Have you had a play with the combination of BT.1886 and CIECAM02 viewing condition adjustments ? The pure CIECAM02 adjustment may be too far the other way, but a combination of low BT.1886 override gamma and CIECAM02 ambient adjustment may be closer to what you are looking for.

I may need to consider getting an i1d3 at some point for cost reasons, as I don't think I'll get lucky and find an i1pro2 for <$600 like I did when I bought my i1pro basic from Amazon when they were closing out the old bundle package.

It will be a while before i1pro2's are available second hand at a good price. An i1d3 that you can calibrate using your i1pro is a good combination.

[Graeme Gill]

Originally Posted by madshi

Does it really make sense to do "per channel calibration" in addition to a big 3dlut? I mean a really big 3dlut can do the same as "per channel calibration". So why doing two separate calibrations?

For creating the display characterisation - yes. You quickly use up points trying to fill 3D space. Rough calculation 100x100x100 perceptual L*a*b* cube with 10000 measurement points is 10000^1/3 = 21 points per axis, 100/21 = 5 delta E spacing between the sample points. If the display behaviour curvature is high, you could have several delta E error at points you haven't sampled. But displays are largely additive, so any such curvature is primarily a result of per channel curvature, and you can sample per channel response with high precision with a few hundred points. Use them to transform the sample and cLUT grid space into a much more linear space, and the limited cLUT grid resolution has much less impact on the overall accuracy.

[cyberbeing]

Playing around with this a bit more, it seems I found a workaround of sorts.

Using that Dispcal REC709 (32lux ambient scaled) profile I posted earlier, I linked it to a REC709 source profile containing a linear 1.0 gamma, set madVR gamma controls to BT.709 2.60 & brightness -90... Problem solved. Gamut correction without the source gamma of the video being modified in any significant way. It's too bad that madVR doesn't have a bigger range for the gamma controls, even though the brightness control is just an extension of gamma control for madVR.

Yes, I'm being serious. First impression is the results actually look quite good, much better than the default collink workflow, so I may actually consider using it this way. Need to take some measurements.

@Graeme Gill
Do you have an opinion about the pros/cons about doing gamut correction using a source profile with a linear curve, and then allowing madVR to handle gamma linear 1.0 gamma to desired gamma? Is there anything technically incorrect or inherent problems with doing things in this way?

[madshi]

Originally Posted by Graeme Gill

For creating the display characterisation - yes. You quickly use up points trying to fill 3D space. Rough calculation 100x100x100 perceptual L*a*b* cube with 10000 measurement points is 10000^1/3 = 21 points per axis, 100/21 = 5 delta E spacing between the sample points. If the display behaviour curvature is high, you could have several delta E error at points you haven't sampled. But displays are largely additive, so any such curvature is primarily a result of per channel curvature, and you can sample per channel response with high precision with a few hundred points. Use them to transform the sample and cLUT grid space into a much more linear space, and the limited cLUT grid resolution has much less impact on the overall accuracy.

Ah, interesting!

Ok, but this simply means that in addition to the sparse cube measurements we need a few hundred additional measurements across the channel axises (and maybe some more across the grayscale axis). It should still be possible to turn all those measurements into one giant 256^3 3dlut without needing additional 1D VideoLUTs, or am I wrong?

Wouldn't we even get better results using just one 256^3 3dlut instead of a 65^3 3dlut plus three 256^1 1dluts? Using just one 256^3 3dlut would mean only one trilinear interpolation. We'd save the 3 bilinear 1dlut interpolations. That should reduce math/rounding errors, no?

[leeperry]

Originally Posted by madshi

I don't know exactly how and when exactly Reclock draws the judder test, so I can't really say...

OK, thought so....anyway, movies appear dead smooth(with the old rendering path on XP) and Reclock's judder test code is prolly ages old and might have been initially coded for XP Overlay for all we know.

Originally Posted by madshi

I'm not sure if the NVidia driver bug was fixed in XP.

I don't think it's ever been as the new rendering path would appear to cause random presentation glitches from time to time, as if mVR missed the VSYNC fliptime or something....the old rendering path remains the unstoppable train it's always been, and I'm currently having a ball with smooth-motion in 140Hz

I do get occasional ghosting and all(even though my brain seems to get used to it), but it's either this or normal 24/25p judder so pick your poison....and you said that the higher the refresh rate the better, so lemme tell you that 140Hz does take care of smoothness. It's funny as sometimes it feels a bit like matrix'eque "bullet time" with more fps than reality hah, excellent work of yours on the smooth-motion feature...business as usual

PS: the improved motion smoonthness also drastically increases the subjective pop effect

[zoyd]

@Graeme User specified transfer functions as input to collink?

[cyberbeing]

Originally Posted by cyberbeing

REC709 source profile containing a linear 1.0 gamma
madVR gamma controls to BT.709 2.60 & brightness -90
Gamut correction without the source gamma of the video being modified in any significant way.
....
Need to take some measurements.

My measurements with a linear source profile + madVR gamma have overall improved compared to the default collink BT.1886 workflow.

Maximum monitor gamut within the REC709 gamut is now used with -ir
0-25-75% Saturation points are closer to optimal locations with lower dE
16-16-16 -> 0-0-0 = Black (with default BT.1886 workflow it was near-black)
Grayscale measurements with linear VideoLUT (dispwin -c) almost exactly monitor's native gamma.

So far so good. Sometime this week I'll make some fresh calibrations with both methods and various collink intent parameters to see if this improvement with a linear source profile is reproducible.

[corporalgator]

Madshi, I cannot get DXVA2 (Native or copyback) decoding through lav filters to work with madvr. The screen goes completely green after a few seconds. It does not happen with evr. Intel Quick sync decoding works fine as well. I've tried several different options within madvr with no luck.

[dansrfe]

Sometimes when I press the next arrow button rapidly when trying to find a scene in a movie the window gets "stuck" on a a few frames and just keeps repeating in exclusive mode. The audio keeps going like normal though. If I go back to windowed mode then the problem goes away but going back to exclusive mode just gives a black screen thereafter. The only resolution at that point is to restart MPC-HC. I have smooth motion on.

Win 7 x64, GTX 670. latest: MPC-HC, LAV Filters, madVR

[corporalgator]

Originally Posted by dansrfe

Sometimes when I press the next arrow button rapidly when trying to find a scene in a movie the window gets "stuck" on a a few frames and just keeps repeating in exclusive mode. The audio keeps going like normal though. If I go back to windowed mode then the problem goes away but going back to exclusive mode just gives a black screen thereafter. The only resolution at that point is to restart MPC-HC. I have smooth motion on.

Win 7 x64, GTX 670. latest: MPC-HC, LAV Filters, madVR

I've experienced the same problem although with pause.

[n3w813]

@cyberbeing/graeme/madshi

I want to try to put cyberbeing's issue into layman's layman's terms to see if I'm understanding it correctly... (sorry, I'm very new to color managment )

Cyberbeing currently have a display with a gamma curve (=cb_gamma_curve) that he prefers. He wants to create a 3DLUT that corrects the gamut but keep the same cb_gamma_curve response.

cb_gamma_curve + 3DLUT = cb_gamma_curve

But the current issue is when incorporating the generated 3DLUT....

cb_gamma_curve + 3DLUT <> cb_gamma_curve

The 3DLUT is based on the reference profile/gamma curve options used with collink.exe. So the problem lies with the options selected not able to produce the gamma curve cyberbeing prefers. So...

1. Cyberbeing wanted an option to disable any gamma processing when creating the 3DLUT. But this is not possible since the 3DLUT needs a gamma target to profile to.
2. Cyberbeing can somehow create a custom target reference .icm file to use instead of Graeme's Rec709.icm
3. Graeme can implement a function in collink.exe that allows the user to specify a custom gamma curve (if technically possible)

Am I on the right track??

[n3w813]

Originally Posted by dansrfe

Sometimes when I press the next arrow button rapidly when trying to find a scene in a movie the window gets "stuck" on a a few frames and just keeps repeating in exclusive mode. The audio keeps going like normal though. If I go back to windowed mode then the problem goes away but going back to exclusive mode just gives a black screen thereafter. The only resolution at that point is to restart MPC-HC. I have smooth motion on.

Win 7 x64, GTX 670. latest: MPC-HC, LAV Filters, madVR

Ditto, I have this issue also ever since smooth motion was enabled in my setup. Never bothered to report the bug (shame on me) since I could easily exit and restart the player with playback resume with my remote.

Win 7 x86, GTS 450. latest: Zoom Player, LAV Filters, madVR
FSE enabled, smooth motion enabled

[mrkazador]

Having this weird problem with a random black frame appearing during a movie. It probably happens 2 or 3 times during the whole film. At first I thought I was blinking too slow lol but definitely not me. All drivers and filters are up to date.

Intel NUC i3 (HD4000)
Win7 x64
MPC HC x86
LAV Filters

Everything in madVr is set to default except these options.
Upscaling: DXVA2
Downscaling: DXVA2
Chroma: Bicubic 75
Smooth Motion: Enabled (disabled linear light)

With smooth motion enabled I get the random black frames. Once I disabled smooth motion I have not noticed a black frame since... Anyone know what the problem could be? My rendering time was in the high 30's while watching a 720p movie on a 1080p display set to 60hz. Disabling smooth motion reduced my rendering time to around 20ms.

[DragonQ]

Random black frames appearing with Smooth Motion on is a bug. madshi hasn't updated MadVR in a while as he's busy with other things but presumably this will be fixed in the next version.

[Graeme Gill]

Originally Posted by n3w813

@cyberbeing/graeme/madshi
3. Graeme can implement a function in collink.exe that allows the user to specify a custom gamma curve (if technically possible)

You don't use a screwdriver to hammer in a nail.

So you don't set the desired reproduction of a device-link/3dlut by changing the calibration of the very device you are trying to make the reproduction not depend on. You set it by choosing the source definition.

There is already lots of possible settings that modify the source definition and the gamut mapping. See the examples in the tutorial (I show 12 as an illustration of where to start).

If you think that this is not capable achieving what you want, then you need to kick off a discussion of what and why, probably starting by justifying why Rec709 encoding + BT.1886 decoding is all wrong, because (as far as I have been able to gather), that's what current best practice says we should be using. See http://www.avsforum.com/t/1409045/ho...crushed-blacks. But none of this is set in stone - there are standards, there is industry practice, there are actual display limitations and viewing conditions, and there is user preference. So the current tool-set is a starting point.

But trying to defy the very way it works is no way to progress.

[n3w813]

Originally Posted by Graeme Gill

You don't use a screwdriver to hammer in a nail.

But trying to defy the very way it works is no way to progress.

You are preaching to the choir, my friend. I was simply suggesting 'possible' fixes to cyberbeing's issue but I know they may not be the 'correct' approach.

I am all for standards. Best scenario, ALL video production houses in the 'world' should all use the same targets. Gamut, gamma, framerate, etc. So the end user can all calibrate their display devices to those targets and be done with it. Especially TV broadcast stations, what you get between one station to another....