madVR - high quality video renderer (GPU assisted)

[cyberbeing]

Originally Posted by Graeme Gill

As I keep explaining, it's not meant to.

I've heard you that the current behavior is intentional. Which I why I continue to request to add support for this alternative behavior which is more suited for the results I want to achieve.

Originally Posted by Graeme Gill

It's meant to be reproducing the colorspace defined by the source profile + the BT.1886 curves (if invoked using -Ib). Setting the VideoLUT to BT.1886 or any other pure power curve is probably not the best thing to do for a good profile. The reason is that the power curve is extremely shallow near zero, and this makes the device behaviour very hard to control (ie. very subject to noise or inaccuracies). Instead a curve with a steeper slope near zero such as sRGB or L* is probably a better choice for accurate profiling and good results using a device link/.3dlut.

Can Argyll create an L* calibration with Dispcal? I did notice that results were better with my 32 lux ambient light scaled BT.709 profile calibrated to with Dispcal, but I was still getting strange/different Y gamma measurements when using the collink 3DLUT. I'm not seeing any way to get my display to measure the custom gamma curve I'm targeting when using a collink 3DLUT. Intentional or not, I would like to see this change.

Originally Posted by Graeme Gill

See my previous reply. I'm not able to reproduce this problem. There must be something about your system or MadVR or .3dlut or VideoLUT setup that is different. The first thing is therefore to pin this down, before going on to look at the video reproduction.

Provided some ICC profile in my previous post if that helps.

Originally Posted by Graeme Gill

"Hacking" the destination profile would completely break this, since it would ruin our ability to know what device values to send to the display to reproduce our target colors.

That is that opposite of what I've been saying. Argyll should have an option "hack" the gamma curve the source profile to match your destination profile and then adapt your destination profile to the desired gamma response.

Source (native monitor gamma / source gamut) -> Destination (native monitor gamma / monitor gamut) -> Final user-defined gamma target (verified by measurements)

Source -> Destination = Linear gamma adaption (Input=Output gamma)
Source -> Destination = Gamut adaption
Destination -> Gamma Target = User defined gamma adaption (w/ src->dst gamut adaption maintained)

Which is does. That's what the -I parameter is doing, + intent + CIECAM viewing condition adjustment.

This is only for BT.1886 though, what about support for other curves which Dispcal can calibrate to with/without ambient light scaling?

I'd also find it useful if you could specify ambient light lux instead of a numerical gamma number when using -I override, in order to scale a curve for viewing conditions in the same fashion as Dispcal.

Originally Posted by Graeme Gill

In theory, you could get what you want by calibrating your display to Rec709 gamma curves, profiling it, and then linking it with one of the Rec709 gamma curve video input profiles. That should give you a .3dlut that doesn't significantly change the transfer curve. You would then switch the calibration back to what you want while using it.

Could you explain this step by step with Argyll command lines for each tool, and point me towards the source ICM profile to use?

I frequently do calibrate to Rec709 with ambient light scaling in Dispcal for video calibration, but it seem like you are suggesting something different. I guess the question would be, how do I create a source ICM profile which agrees with Dispcal's method of ambient light scaling? The REC709 profiles bundled with Dispcal GUI scale the the native Rec709 curves in a more traditional fashion while Dispcal scales to ambient light with CIECAM based on your display measurements.

[Graeme Gill]

Originally Posted by cyberbeing

Another problem I've noticed Argyll CMS collink is that the "4-Color Clipping.mp4" chart from the AVS HD 709 test patterns isn't behaving correctly.
Colors are being clipped before 235 even if I use Perceptual for the 3DLUT.

My testing of "3-White Clipping.mp4" indicates that the white clip is close to perfect. The "4-Color Clipping.mp4" is not likely to be the same, unless some specific conditions are met - basically the source has to be within the gamut of the display. Yes, perceptual will try and avoid any clipping that normally results for colorimetric reproduction where the input is out of gamut, but there are a bunch of constraints on perceptual, such as ensuring smoothness and erring on the side of the primaries being fully saturated. You will find that increasing the resolution of the perceptual gamut mapping by using "-qh" or "-qu" will improve the individual channel clipping behaviour, and you should get nearer to perfect. It will be very close to perfect with -ims, but you may not want the gamut expansion. (I will change it to default to -qh 3dlut output in the next version.)

[cyberbeing]

Originally Posted by Graeme Gill

The "4-Color Clipping.mp4" is not likely to be the same, unless some specific conditions are met - basically the source has to be within the gamut of the display.

"4-Color Clipping.mp4" is Rec709, while my GDM-F520 monitor (white line) has a gamut smaller than Rec709 (true color line) in RED & BLUE, so I guess that means the color clipping pattern will never be perfect. I still wonder why Blue is affected the heaviest, while Red is not affected at all, considering the gamut of my GDM-F520. I'll try -qh & -qu in collink later.

Edit: Not seeing any visible improvement on "4-Color Clipping.mp4" using -qu -ip or -qu -ir
Edit2: It would seem the -q switch is broken or not affecting ouput when using -ir , since the 3DLUT generated with defaults vs -qu are 100% byte-identical.
Edit3: Using -ir or -ila causes Green to be clipped the heaviest on "4-Color Clipping.mp4", even though that is the only color of my monitor gamut which falls within REC709.

[Graeme Gill]

Originally Posted by cyberbeing

I'm unconvinced that Dispcal & Collink are in agreement on what a BT.1886 curve is, since my gamma curve always gets changed.

No, they aren't quite the same in the current version. Assuming you are using "colprof -G2.4 -f0", there will be some subtle differences near black, depending on the dispcal -k factor. By default it is automatic, to best adapt to LCD type displays. Closer to equivalent behaviour to collink is "dispcal -k 1", but that's not an exact match either, since dispcal raises the black until it can fully correct the black point, whereas (currently) collink chooses a compromise (RGB weighted) black level to fully correct to, possibly clipping 1 or 2 channels. I am wondering whether to move the collink BT.1886 closer to "dispcal -k 0" or an automatic factor, but I haven't figured out how the neutral bend to black in the BT.1886 would interact with the gamut black point "extend and bend" code, since they essentially are aimed at solving the same problem.

Most notable is that the collink 3DLUT somewhat crushes neutral shadow tones, and gives really strange overly desaturated results on low luminance colors when using -I b Rec709.icm.
If I use -I b -I 2.2 Rec709.icm, both shadow tones and saturation of low luminance colors are mostly normal, but everything in mid-tones and above are then using a completely different much brighter gamma curve than the video source pixels.

Without seeing what you're seeing, it's hard to comment.

Here's a sanity check: On my display for black, 50% grey and White using
a .3dlut created with "-Ib -I2.2 -ir" I get:

Video in	3dlut out	                Expected display XYZ
0 0 0		0.010435 0.005188 -0.000180	0.000341 0.000352 0.000302
.5 .5 .5	0.533183 0.536744 0.535794	0.217556 0.229262 0.226722
1 1 1		1.000001 1.000008 1.000019	0.951394 1.000018 0.978644

[I'm using xicclu -et -Et on the device link, and icclu -ff -ia -px on the display profile. I've updated Win32_collink_3dlut.zip to include the xicclu that supports -e and -E]

So the effective display gamma is log(0.229262)/log(0.5) = 2.1249, which is what you expect for a slight input offset. The overall effective viewing gamma is therefore about 2.1249/(Rec709 ~= 2.0) = 1.06. Which is plum in the target range for a not super dark viewing conditions.

The reason I mentioned the issue with madVR gamma correction with the Argyll 3DLUT in my previous post, is because dispcal BT.1886 + -I b Rec709.icm + madVR gamma BT.709 2.0 comes somewhat close to normalizing the gamma curve so the source pixels (linear gamma response) of the video aren't modified.

Sorry, it's hard to follow what your setup is. "dispcal BT.1886" is irrelevant if you are created a .3dlut as per recommendations. I'm certainly not bringing MadVR gamma into it - it's hard enough to follow as it is.

From what I remember, yCMS post-processes the 16 bit output with dithering when writing the 3DLUT, and I assume Argyll also performs smoothing of some kind on the 16bit output.

It doesn't work like that. The 3dlut processes each pixel independently, so it's not possible to apply spatial dithering with it. It's MadVR that is the position to apply spatial dithering. All the Argyll stuff is floating point, but it is limited by the precision of the measurements, smoothing and fitting in the profiles, limited cLUT table resolution, and the 16 bit precision of the standard ICC profiles.

[cyberbeing]

Originally Posted by Graeme Gill

No, they aren't quite the same in the current version. Assuming you are using "colprof -G2.4 -f0", there will be some subtle differences near black, depending on the dispcal -k factor. By default it is automatic, to best adapt to LCD type displays. Closer to equivalent behaviour to collink is "dispcal -k 1", but that's not an exact match either, since dispcal raises the black until it can fully correct the black point, whereas (currently) collink chooses a compromise (RGB weighted) black level to fully correct to, possibly clipping 1 or 2 channels. I am wondering whether to move the collink BT.1886 closer to "dispcal -k 0" or an automatic factor, but I haven't figured out how the neutral bend to black in the BT.1886 would interact with the gamut black point "extend and bend" code, since they essentially are aimed at solving the same problem.

I assume that's a typo and you mean "dispcal -G2.4 -f0" not "colprof".

It appears that the profile I linked earlier was "-g2.4 -f0 -k1.0" and not "-G2.4 -f0 -k1.0", since using "-G2.4" was crushing shadow tones too much on my CRT. I actually seem to get closer to the values on that BT.1886 Excel sheet calculator using -g2.4 because of the difficulty which the i1pro has reading extremely low luminance levels. (note: I'm the same guy from the mailing list troubleshooting the i1pro crt problem which resulted in you to adding adaptive i1pro integration time for dispcal back in 2009).

Originally Posted by Graeme Gill

Without seeing what you're seeing, it's hard to comment.

Essentially the following:

3DLUT Disabled
yCMS 3DLUT
Argyll collink -Ib -I2.4 -ir 3DLUT
Argyll collink -Ib -I2.2 -ir 3DLUT (edit: fixed link)

Originally Posted by Graeme Gill

Here's a sanity check: On my display for black, 50% grey and White using
a .3dlut created with "-Ib -I2.2 -ir" I get:

Video in	3dlut out	                Expected display XYZ
0 0 0		0.010435 0.005188 -0.000180	0.000341 0.000352 0.000302
.5 .5 .5	0.533183 0.536744 0.535794	0.217556 0.229262 0.226722
1 1 1		1.000001 1.000008 1.000019	0.951394 1.000018 0.978644

[I'm using xicclu -et -Et on the device link, and icclu -ff -ia -px on the display profile. I've updated Win32_collink_3dlut.zip to include the xicclu that supports -e and -E]

So the effective display gamma is log(0.229262)/log(0.5) = 2.1249, which is what you expect for a slight input offset. The overall effective viewing gamma is therefore about 2.1249/(Rec709 ~= 2.0) = 1.06. Which is plum in the target range for a not super dark viewing conditions.

I'm not familiar with the functionality or purpose of the xicclu or icclu tools, but I'll try to figure out from the documentation what you mean by this.

[Graeme Gill]

Originally Posted by cyberbeing

There must be a madVR bug with this option on WinXP.
If you want this fixed, you should file a bug report on madshi's bug tracker: http://bugs.madshi.net/my_view_page.php

Hard to file a bug, when I don't precisely know what the switch is meant to do.

What was your calibration target with Dispcal? Could you provide step by step command lines for each Argyll tool which will result the identical measurements you are seeing? I'd like to see if I could reproduce your results, since you must be doing something different than I am.

The step by step is as per Scenarios.html#TV1.

The .3dlut without the calibration curve is built with

collink -v -I b -I 2.2 -G -i r Rec709.icm TV.icm HD.icm

tested with the display profile in place: "dispwin TV.cal".

The .3dlut with calibration curve was built with

collink -v -I b -I 2.2 -G -i r -a TV.cal Rec709.icm TV.icm HD.icm

and tested with "dispwin -c"

For this sort of testing it shouldn't matter exactly what device profile and calibration you use, ie. you could use srgb.icm for TV.icm, and strange.cal for the calibration file, and it should still prove the equivalence.

My conclusion thus far is that the gamma curve of the Rec709.icm source profile is throwing things off when it doesn't match the curve in your Monitor.icm profile.

It can't possibly be, since the monitor response is irrelevant to the overall response. The monitor profile is used to lookup the device RGB values to send to it, to produce the desired colors. The desired colors are determined by the video data values + input profile + (optional) BT.1886 curve.

It seem as though you are doing a gamma adaption from Rec709.icm to Monitor.icm, and then finally doing an adaption from that result to disp.cal.

That's not how it works at all (or rather, it's a confusing way to think about it). Monitor.icm encapsulates the display response to RGB values being fed into it, including the effects of disp.cal. The colors to be displayed are determined by the video data values + input profile + (optional) BT.1886 curve. Then the monitor RGB values are then determined by lookup them up in the Monitor.icm. The disp.cal is part of the display path, just like the display controls and the display itself, and characterised by Monitor.icm.

Video RGB in Rec709 -> BT.1886 curve -> Input profile -> PCS - (optional gamut mapping) -> target PCS -> display profile -> calibrated display RGB -> disp.cal -> raw display RGB -> display -> expected PCS.

Monitor.icm is the inverse of how the display behaves, so that when concatenated with the actual display, it cancels out.

[The BT.1886 is plonked in front of the input profile because we know the input profile is a matrix. For a general input profile, we would have to do it in PCS space.]

It seem as though you are doing a gamma adaption from Rec709.icm to Monitor.icm.

This is the very intention of the 3dlut.

[Graeme Gill]

Originally Posted by cyberbeing

I've heard you that the current behavior is intentional. Which I why I continue to request to add support for this alternative behavior which is more suited for the results I want to achieve.

Then I can't help you, because that's not the best way of doing this kind of thing, and I'm not going to waste time pursuing it. But I fail to understand why you want to do that. If you were using the tool the way it was intended and not getting a good result, then I'm interested in figuring out why.

Can Argyll create an L* calibration with Dispcal?

Yes, but it's not very relevant to the task at hand.

Provided some ICC profile in my previous post if that helps.

Not in themselves, no. The device link might help, but not without the details about how it was created, and only if the intention is the workflow outlined in Scenarios.html#TV1.

That is that opposite of what I've been saying. Argyll should have an option "hack" the gamma curve the source profile to match your destination profile and then adapt your destination profile to the desired gamma response.

That doesn't make any sense. The source profile is what determines how the Video is interpreted, and that's the part that should be independent of the actual display. The whole point is to reproduce the video in a way that doesn't depend on the behaviour of the display.

I'd also find it useful if you could specify ambient light lux instead of a numerical gamma number when using -I override, in order to scale a curve for viewing conditions in the same fashion as Dispcal.

I'm hoping that won't be necessary, as you have the full CICAM02 available to you. See the "or using both to model a reference video display system that is adapted to your viewing conditions" suggestion.

[cyberbeing]

Originally Posted by cyberbeing

Essentially the following:

3DLUT Disabled
yCMS 3DLUT
Argyll collink -Ib -I2.4 -ir 3DLUT
Argyll collink -Ib -I2.2 -ir 3DLUT (edit: fixed link)

A few more with Grayscale steps:

3DLUT Disabled (Steps)
yCMS 3DLUT (Steps)
Argyll collink -Ib -I2.4 -ir 3DLUT (Steps)
Argyll collink -Ib -I2.2 -ir 3DLUT (Steps)

(currently reading your prior two posts)

[madshi]

Originally Posted by Graeme Gill

I'm unable to find any combination of MadVR settings that doesn't use the Graphics card VideoLUTs.

I've tried:

Window mode - No "disable GPU gamma ramps"
Window mode - With "disable GPU gamma ramps"
Full screen exclusive - No "disable GPU gamma ramps"
Full screen exclusive - With "disable GPU gamma ramps"

and in every case, the Video is being rendered through the calibration curves in the VideoLUTs.
This is quite obvious if you first load the VideoLUTs with "dispwin strange.cal".

[I've no idea if this is system and/or graphics card dependent. I'm running WinXP with a
GeForce 8600 GT. ]

I would imagine that anything using a Video overlay would not be affected by the VideoLUTs,
and I notice there is an option for that for Win7+.

Weird, I'm telling Direct3D to disable the VideoLUT and from all the feedback I got so far this reportedly works in fullscreen exclusive mode but fails in windowed mode. Maybe it fails to work in XP with your specific GPU drivers, I'm not sure. There is one other API I can use to disable the VideoLUT. I will try that, maybe it works better...

Originally Posted by Graeme Gill

I'm not sure this is a viable path, although it depends on your expectations. I would imagine that the whole ArgyllCMS tool-chain is too complex to manage this easily. Installing system drivers for instruments for instance, has its complications, and switching to LibUSB-win32 drivers from the manufacturers drivers should only be done with user accent. Better to look towards DispcalGUI if this is the scope.

If you are thinking of a lesser scope, such as being able to use an existing or installed display profile, then the current tool (collink) is built more for quality than speed. You might get away with it with a judicious choice of options, but the scheme I outlined previously of the .3dlut being built by MadVR using an ICC profile library is probably a better long term goal I think.

As long as the ArgyllCMS license is complied with, you can use it as you see fit. If MadVR is not shipped/packaged with ArgyllCMS, and does not depend on it for its normal operation, ie. if ArgyllCMS is downloaded at the user instigation, and is made use of by MadVR as an optional feature, then I think this would be acceptable from a licensing point of view.

Got it - thanks!

Originally Posted by cyberbeing

I've heard you that the current behavior is intentional. Which I why I continue to request to add support for this alternative behavior which is more suited for the results I want to achieve.

That is that opposite of what I've been saying. Argyll should have an option "hack" the gamma curve the source profile to match your destination profile and then adapt your destination profile to the desired gamma response.

I don't think your feature wish is possible to realize with the general concept used by ArgyllCMS (or any comparable solution like e.g. Calman's 3D cube calibration). As far as I understand, ArgyllCMS works like this:

(1) First of all it measures your display's exact behaviour. The measurements are done in 3D (not in 2D at 75IRE or 100IRE like yCMS). And the 3D measurement grid doesn't even have to be regular.
(2) In the second step ArgyllCMS calculates the desired display behaviour. Basically is calculates how your display *should* measure at every 3D measurement point.
(3) Finally, ArgyllCMS calculates a LUT that for every LUT point transforms the actual display behaviour to the desired behaviour.

The problem with your feature wish is that your gamma response is not strictly a 2D curve, and it is not separate from your overall display behaviour. Measuring primaries and gamma response separately makes things easier to understand for us humans. But ArgyllCMS's algorithms don't separate between them, I believe. ArgyllCMS just for every 3dlut data point implements a transformation which makes sure that the display measures as calculated in step (2).

In order to implement your feature wish you would either have to "hack" the measurements done in step (1), or you would have to "hack" the desired display response calculated in step (2). Both is theoretically possible. But please understand that doing such hacks would have to be done in 3D, and the hacks would affect both gamma and colors. Doing this in a way that produces the results you wish for would be really really complicated.

I don't think ArgyllCMS could do such hacks automatically, because what you ask for is to keep gamma the same but change colors, while the way ArgyllCMS works it doesn't even separate gamma and gamut (except in step (2) where gamma and primaries are specified to calculate the "wanted display response"). ArgyllCMS just tries to make the display measure a specific XYZ value at every LUT point.

I think the only practical way to implement your feature wish with the way ArgyllCMS works would be to create a very complex target model for step (2) which would somehow maintain your display's original transfer response while correcting the primaries. But such a model would have to be 3D for ArgyllCMS to make sense. Basically what you could do is take the "wanted display response" (step (2)) and then tweak it by moving around the calculated wanted XYZ values of each 3D measurement point. You could do that with trial and error, to try achieve the desired affect. But trial and error means you'd have to test every modification to see if it produces the desired results. This process would be very painful, IMHO, because it would have to be done in 3D and you'd have to move around the surrounding measurement points in 3D somewhat, too, and it would screw up ArgyllCMS' calculations, so in the end while you might be able to maintain your transfer response more or less (with a *lot* of manual work), you would likely hurt the primary calibration quality.

BTW, the CMS I considered adding to madVR would have worked *exactly* the same way ArgyllCMS works. And that btw was also the plan for yCMS v2. Meaning your wishes wouldn't have worked with my own CMS or with yCMS v2, either.

I didn't know that ArgyllCMS already did exactly what I was planning for. So now I think I will probably not do my own CMS. Why reinvent the wheel? Instead I'll probably invest some time to make it easier for users to work with ArgyllCMS (or Calman or [...]) in combination with madVR.

Edit: After thinking about it: Maybe you could simply tell ArgyllCMS to use a different gamma curve to calculate the "desired display behaviour" in step (2)? If you choose a gamma curve that is near to your display's native behaviour, shouldn't that produce the desired effect?

Originally Posted by Graeme Gill

It doesn't work like that. The 3dlut processes each pixel independently, so it's not possible to apply spatial dithering with it. It's MadVR that is the position to apply spatial dithering.

Absolutely correct. yCMS doesn't dither, either - it's not technically possible. The only way for 3dlut creation software to produce good quality is to use a high internal bitdepth and to output 3dluts with the highest possible bitdepth and resolution.

-------

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

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.

Ok, I'm not sure if this would just prettify those measurement charts, or if it would also help with real life video playback. Just a thought...

[madshi]

Originally Posted by Aleksoid1978

When use madVR as video renderer - SetWindowText() have this issue .

Ok, but is this a bug in madVR or a bug in MPC-BE? Do I have to change anything in madVR to fix it?

FWIW, this problem does *not* occur with the latest MPC-HC build. So does this mean it's a bug in MPC-BE?

[Aleksoid1978]

Originally Posted by madshi

Ok, but is this a bug in madVR or a bug in MPC-BE? Do I have to change anything in madVR to fix it?

FWIW, this problem does *not* occur with the latest MPC-HC build. So does this mean it's a bug in MPC-BE?

There is no special code - just call CWnd::SetWindowText().
I do not understand.

[madshi]

Weird. Why does the problem not occur with MPC-HC? I don't understand, either!!

[sneaker_ger]

Originally Posted by madshi

Does this occur with all DVDs? Then please create a bug tracker report.

I've created a report. Just delete the ticket without the attachment. It didn't take the .7z extension and then I must have misclicked (or it's a bug in the tracker?). It also made "~4 minute mark" into "0000001:0000004 minute mark".

[cyberbeing]

Originally Posted by Graeme Gill

For this sort of testing it shouldn't matter exactly what device profile and calibration you use, ie. you could use srgb.icm for TV.icm, and strange.cal for the calibration file, and it should still prove the equivalence.

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.

Originally Posted by Graeme Gill

It can't possibly be
...
That's not how it works at all (or rather, it's a confusing way to think about it)
...
Video RGB in Rec709 -> BT.1886 curve -> Input profile -> PCS - (optional gamut mapping) -> target PCS -> display profile -> calibrated display RGB -> disp.cal -> raw display RGB -> display -> expected PCS.

Monitor.icm is the inverse of how the display behaves, so that when concatenated with the actual display, it cancels out.

[The BT.1886 is plonked in front of the input profile because we know the input profile is a matrix. For a general input profile, we would have to do it in PCS space.]

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.

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?

Originally Posted by Graeme Gill

This is the very intention of the 3dlut.

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.

If dispcal were capable of re-calibrating VideoLUT gamma based on 3DLUT grayscale output, that could be nice, but it still means that the 3DLUT is messing with gamma of video pixels in an undesired way.

Originally Posted by madshi

I don't think your feature wish is possible to realize with the general concept used by ArgyllCMS (or any comparable solution like e.g. Calman's 3D cube calibration). As far as I understand, ArgyllCMS works like this:
...
(1) First of all it measures your display's exact behaviour. The measurements are done in 3D (not in 2D at 75IRE or 100IRE like yCMS). And the 3D measurement grid doesn't even have to be regular.
(2) In the second step ArgyllCMS calculates the desired display behaviour. Basically is calculates how your display *should* measure at every 3D measurement point.
(3) Finally, ArgyllCMS calculates a LUT that for every LUT point transforms the actual display behaviour to the desired behaviour.
...
The problem with your feature wish is that your gamma response is not strictly a 2D curve
...
Doing this in a way that produces the results you wish for would be really really complicated.
...
I don't think ArgyllCMS could do such hacks automatically
...
I think the only practical way to implement your feature wish with the way ArgyllCMS works would be to create a very complex target model for step (2)

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

You, me, and yesgray had these very same discussions during yCMS v1 development, and came to the ultimate conclusion that no gamma correction should be the default behavior. As well as that the video should not be assumed to have any gamma curve and treated linearly in yCMS unless grayscale measurements were specified. It would be sad if you had done away with the capability to do gamut correction without gamma correction in a future madVR version.

Originally Posted by madshi

Absolutely correct. yCMS doesn't dither, either - it's not technically possible. The only way for 3dlut creation software to produce good quality is to use a high internal bitdepth and to output 3dluts with the highest possible bitdepth and resolution.

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 version of yCMS even added a Denoise_Black_Level option, which was just one of the latest of the special tweaks he did internally in yCMS when calculating gamma and gamut correction for 3DLUT files. I seem to remember him mentioning special handling for reducing 3DLUT color banding as well. He also used to say that yCMS did neither Perceptual or Relative Colorimetric gamut adaption, but some kind of custom hybrid approach. What this means, who knows? Did you ever see his source code to know what he was talking about half the time?

Originally Posted by madshi

Edit: After thinking about it: Maybe you could simply tell ArgyllCMS to use a different gamma curve to calculate the "desired display behaviour" in step (2)? If you choose a gamma curve that is near to your display's native behaviour, shouldn't that produce the desired effect?

@Graeme is this possible? It seems similar to what I've already been requesting by using Dispcal measurements to override things.

[madshi]

Originally Posted by cyberbeing

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?

No, ArgyllCMS does allow you to specify which gamma curve you want to target. However, at the moment at least dispcalGUI seems to be limited to a specific set of gamma curves and values. If none of these curve/value combinations comes close to what you want to have, you've got a problem. Maybe it would be worth a thought for ArgyllCMS to allow specifying a totally custom gamma target curve. You could then model it to match an estimation of your current gamma response. But I'm just thinking out loud here, only Graeme can say if that is making any sense or not.

[cyberbeing]

Originally Posted by madshi

No, ArgyllCMS does allow you to specify which gamma curve you want to target. However, at the moment at least dispcalGUI seems to be limited to a specific set of gamma curves and values. If none of these curve/value combinations comes close to what you want to have, you've got a problem. Maybe it would be worth a thought for ArgyllCMS to allow specifying a totally custom gamma target curve. You could then model it to match an estimation of your current gamma response. But I'm just thinking out loud here, only Graeme can say if that is making any sense or not.

I'm happy with the curves which dispcal allows, I'm unhappy that I so far have failed to get the dispcal curves I normally calibrate to, to display properly after passing through an Argyll collink 3DLUT. All I want to be able to do is calibrate to a curve with dispcal, create a 3DLUT, and still have the same final display gamma response with the 3DLUT vs dispcal only. What should be simple, obviously is not. Graeme Gill has said dispcal curves not matching the 3DLUT curve when measured on your display is intended behavior in a previous post, so as far as I can tell I am out of luck.

[madshi]

I'm not sure I understand. What exactly do you mean with "3DLUT vs dispcal only"? Do you mean "3DLUT = VideoLUT + madVR 3dlut" and "dispcal only = VideoLUT"? If so: What happens if you disable the VideoLUT when using the madVR 3dlut, do you get correct results then?

[Graeme Gill]

Originally Posted by cyberbeing

"4-Color Clipping.mp4" is Rec709, while my GDM-F520 monitor (white line) has a gamut smaller than Rec709 (true color line) in RED & BLUE, so I guess that means the color clipping pattern will never be perfect. I still wonder why Blue is affected the heaviest, while Red is not affected at all, considering the gamut of my GDM-F520. I'll try -qh & -qu in collink later.

Edit: Not seeing any visible improvement on "4-Color Clipping.mp4" using -qu -ip or -qu -ir
Edit2: It would seem the -q switch is broken or not affecting ouput when using -ir , since the 3DLUT generated with defaults vs -qu are 100% byte-identical.
Edit3: Using -ir or -ila causes Green to be clipped the heaviest on "4-Color Clipping.mp4", even though that is the only color of my monitor gamut which falls within REC709.

It's pretty obvious in the verbose output. -qm is "Gamut map resolution: 25". -qu is "Gamut map resolution: 41". I get two .icm's and .3dluts that differ within a few hundred bytes of the cLUT data.

Red, Green and Blue are all outside your displays gamut:

icclu -ff -ir -pl Rec709.icm

/src/argyll/link:icclu -ff -ir -pl Rec709.icm
1.000000 0.000000 0.000000 [RGB] -> MatrixFwd -> 54.285218 80.831212 69.906123 [Lab]
0.000000 1.000000 0.000000 [RGB] -> MatrixFwd -> 87.820812 -79.285064 80.992273 [Lab]
0.000000 0.000000 1.000000 [RGB] -> MatrixFwd -> 29.569144 68.284819 -112.028372 [Lab]

/src/argyll/test/cyberbeing:xicclu -a -fif -ir -pl GDM-F520_2013-04-15_BT.1886_MQ.icm

54.285218 80.831212 69.906123 [Lab] -> Lut -> 0.952400 0.000000 0.000000 [RGB] (clip)
[Actual 55.227343 75.324788 72.225882, deltaE 6.048933]

87.820812 -79.285064 80.992273 [Lab] -> Lut -> 0.399021 1.000000 0.000000 [RGB] (clip)
[Actual 86.520454 -69.126831 81.851552, deltaE 10.277110]

29.569144 68.284819 -112.028372 [Lab] -> Lut -> 0.000000 0.000000 0.998954 [RGB] (clip)
[Actual 34.504783 47.212857 -103.267859, deltaE 23.348120]

[Graeme Gill]

Originally Posted by cyberbeing

I assume that's a typo and you mean "dispcal -G2.4 -f0" not "colprof".

Yes.

It appears that the profile I linked earlier was "-g2.4 -f0 -k1.0" and not "-G2.4 -f0 -k1.0", since using "-G2.4" was crushing shadow tones too much on my CRT.

Right. -G2.4 is for standard BT.1886, but one potential problem with BT.1886 is that the effective gamma (ie. what it does to the mid tones) is highly sensitive to the black point. But I would expect moving to -g2.4 to make this even darker !

I actually seem to get closer to the values on that BT.1886 Excel sheet calculator using -g2.4 because of the difficulty which the i1pro has reading extremely low luminance levels.

It's certainly a trick to get the i1pro stable with very low black levels. i1d3 is pretty good, and the i1pro2 is much improved over the i1pro.

I'm not familiar with the functionality or purpose of the xicclu or icclu tools, but I'll try to figure out from the documentation what you mean by this.

They are tools for looking up colors in icc profiles and links. xicc is a superset of icclu. The res 65 device link is what's interpolated up to build the res. 256 .3dlut.

[cyberbeing]

Originally Posted by Graeme Gill

Red, Green and Blue are all outside your displays gamut

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

Right. -G2.4 is for standard BT.1886, but one potential problem with BT.1886 is that the effective gamma (ie. what it does to the mid tones) is highly sensitive to the black point. But I would expect moving to -g2.4 to make this even darker !

Well as mentioned before, even with adaptive integration, my i1pro has trouble taking a reliable black point measurement. Using -g2.4 I ended up with an average gamma curve of ~2.35, but closer to 2.2 near black. Using -G2.4 I ended up with nearly exactly as 2.4 gamma power-curve which I didn't want.

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.

It's certainly a trick to get the i1pro stable with very low black levels. i1d3 is pretty good, and the i1pro2 is much improved over the i1pro.

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.