MadVR - ArgyllCMS - Page 52 - AVS Forum

## AVS Forum> Display Devices> Display Calibration > MadVR - ArgyllCMS

Display Calibration

fhoech
12:03 PM Liked: 53
post #1531 of 2877
03-01-2014 | Posts: 295
Joined: Apr 2013
Slightly offtopic, but I have always admired the smooth gamut mapping provided by the Argyll created 3D LUTs, which I never could quite achieve using a "normal" XYZLUT display profile.
So I wondered, could a similar methodology as employed by Argyll's collink (generating the 3D LUT gamut mapping by inverting the display profile A2B "device to PCS" tables) be used to generate a similar result with a regular ICC profile workflow? The answer seems to be "yes"

Basically I've implemented A2B table inversion using xicclu, and added that functionality to dispcalGUI. In the latest development snapshot, you'll notice a new checkbox "Smooth B2A tables" along with a selector for the cLUT table size, as well as a new menu item in the options menu to re-generate the B2A table of existing profiles. It will only re-generate the colorimetric B2A table, and not touch any perceptual or saturation mapping you may have chosen for profile creation.
This seems to improve the smoothness of the colorimetric B2A gamut mapping quite a bit. I've added an example to the changelog in the snapshot ReadMe.

I've started to use 0install ("Zero Install") to roll out development snapshots, and added a wiki page with a how-to for people interested in trying it out. Comments welcome
02:31 AM Liked: 163
post #1532 of 2877
03-02-2014 | Posts: 5,507
Joined: May 2005
@Graeme,

there seems to be a problem with WTW (and possibly BTB) handling. Basically it seems that in some cases ArgyllCMS extrapolates the calibration in such a way that some WTW colors are moved back into the visible/valid range. This then results in WTW bars still being visible in WTW test patterns, even if the display is setup to hide WTW. I think this is not an easy problem to solve, though, because some users might want some WTW data to still be visible, so extrapolating the calibration to the WTW area does make some sense. However, the normal/usual configuration is to have WTW hidden from view, so I think there might have to be an option for ArgyllCMS which defines how to handle WTW data. E.g. like this:

(1) Calibrate WTW data, too.

In this case ArgyllCMS should apply calibration to WTW data, by extrapolating the calibration. And probably we want the gamma response to be continuous, so probably a side effect of this option would be that some WTW colors could potentially be moved back into the valid range.

(2) "Clip" WTW data.

I guess there are 2 ways to do this. The simple way would be to do a straight 1:1 passthrough for all BTB & WTW pixels. The more complicated way would be to still extrapolate the calibration, so that BTB & WTW are calibrated, too. However, ArgyllCMS would have to make sure that all BTB/WTW pixels stay BTB/WTW. This could become difficult, especially if you want to have different values for every color (no flat areas). So I guess maybe the simple passthrough solution would be preferred? I'm not sure how to treat pixels which are "partially" in the WTW area, though. E.g. an RGB pixel [230, 240, 230]. What to do with that pixel?

I think no user wants BTB to be visible. So probably a straight 1:1 passthrough should always be used for BTB. No extrapolation of the calibration needed here. But for WTW the situation is different. Some calibrators like to leave at least a part of WTW visible.

Thoughts?
zoyd
04:59 AM Liked: 466
post #1533 of 2877
03-02-2014 | Posts: 5,103
Joined: Sep 2006
Quote:

@Graeme,

(1) Calibrate WTW data, too.

In this case ArgyllCMS should apply calibration to WTW data, by extrapolating the calibration. And probably we want the gamma response to be continuous, so probably a side effect of this option would be that some WTW colors could potentially be moved back into the valid range.

Could you also directly include this region in the process by allowing test points up to 254,254,254 in conjunction with the -E switch?
gwgill
05:18 AM Liked: 93
post #1534 of 2877
03-03-2014 | Posts: 691
Joined: Jan 2013
Quote:

@Graeme,

there seems to be a problem with WTW (and possibly BTB) handling. Basically it seems that in some cases ArgyllCMS extrapolates the calibration in such a way that some WTW colors are moved back into the visible/valid range. This then results in WTW bars still being visible in WTW test patterns, even if the display is setup to hide WTW.
Can you mail me an example ? ie. .ti3 file + collink options.

Any value over the 235/255 should stay over 235/255 after passing through the cLUT, and any value less than 16/255 stays less than 16/255.

It's always possible I've got a bug though.
Quote:
I think this is not an easy problem to solve, though, because some users might want some WTW data to still be visible, so extrapolating the calibration to the WTW area does make some sense. However, the normal/usual configuration is to have WTW hidden from view, so I think there might have to be an option for ArgyllCMS which defines how to handle WTW data.
The current handling was in direct response to user requests to extrapolate the mapping beyond white. Prior to that it used to linearly interpolate from the encoding limit to 255/255
Quote:
E.g. like this:

(1) Calibrate WTW data, too.

In this case ArgyllCMS should apply calibration to WTW data, by extrapolating the calibration. And probably we want the gamma response to be continuous, so probably a side effect of this option would be that some WTW colors could potentially be moved back into the valid range.
That's what currently happens. I don't think that any values will go back into their visible range once above/below the encoding limit.
Quote:
(2) "Clip" WTW data.

I guess there are 2 ways to do this. The simple way would be to do a straight 1:1 passthrough for all BTB & WTW pixels. The more complicated way would be to still extrapolate the calibration, so that BTB & WTW are calibrated, too. However, ArgyllCMS would have to make sure that all BTB/WTW pixels stay BTB/WTW. This could become difficult, especially if you want to have different values for every color (no flat areas). So I guess maybe the simple passthrough solution would be preferred? I'm not sure how to treat pixels which are "partially" in the WTW area, though. E.g. an RGB pixel [230, 240, 230]. What to do with that pixel?
I think by definition, if you clip it's got to be per component, just like with extrapolation, it's per component. That's because the encoding limits are per component.
Quote:

I think no user wants BTB to be visible. So probably a straight 1:1 passthrough should always be used for BTB. No extrapolation of the calibration needed here.
It really shouldn't make much difference, although I think that extrapolating leaves less room for surprises, since we're talking about sparse interpolated cLUT grids, and you can't always manage thing so that the encoding limit lands exactly on a grid point.
05:35 AM Liked: 163
post #1535 of 2877
03-03-2014 | Posts: 5,507
Joined: May 2005
@Graeme,

thanks for looking into this. My post was a reaction to this user report in the doom9 madVR forum thread:

http://forum.doom9.org/showpost.php?p=1671430&postcount=24165

There's a RAR download link in that post which contains several files. I'm not sure if all the files you need are in there. If not, please let me know, then I'll ask the user to provide the missing information. Here's the direct RAR download link:

https://dl.dropboxusercontent.com/u/93831976/Yellow%20Bars.rar
Elix
06:00 AM Liked: 39
post #1536 of 2877
03-03-2014 | Posts: 1,294
Joined: Jun 2011
Quote:
Originally Posted by fhoech

I've started to use 0install ("Zero Install") to roll out development snapshots, and added a wiki page with a how-to for people interested in trying it out. Comments welcome
Florian, you're the man! This new algorithm produced the best 3DLUT yet for my color-deficient DLP projector (Optoma GT760). The picture now is so smoooooth! I will post some graphs and pictures later but for now I just wanted to say - thanks! That inversed B2A method works great.

Oh, and 0install is nice too.

P.S. Of course credit also goes to Graeme.
gwgill
06:52 AM Liked: 93
post #1537 of 2877
03-03-2014 | Posts: 691
Joined: Jan 2013
Quote:

@Graeme,

thanks for looking into this. My post was a reaction to this user report in the doom9 madVR forum thread:

http://forum.doom9.org/showpost.php?p=1671430&postcount=24165
Ah yes, Mister MonarchX, who doesn't seem to appreciate help.
Quote:
There's a RAR download link in that post which contains several files. I'm not sure if all the files you need are in there. If not, please let me know, then I'll ask the user to provide the missing information. Here's the direct RAR download link:

https://dl.dropboxusercontent.com/u/93831976/Yellow%20Bars.rar

Nope, no .ti3, no linking details, no point investigating the end result when I can't see how it was arrived at.
fhoech
07:31 AM Liked: 53
post #1538 of 2877
03-03-2014 | Posts: 295
Joined: Apr 2013
Quote:
Originally Posted by Elix

Florian, you're the man! This new algorithm produced the best 3DLUT yet for my color-deficient DLP projector (Optoma GT760). The picture now is so smoooooth!

Hmm. I'm doubting it's because of my change, which shouldn't affect 3D LUT creation at all If it does, it may be a bug that I should fix.
Quote:
Oh, and 0install is nice too.
I like it because it makes it very easy for me to release development snapshots - it's just one archive I need to create, and two XML files I need to change (and that can even be automated).
Asmodian
08:07 AM Liked: 10
post #1539 of 2877
03-03-2014 | Posts: 11
Joined: Mar 2014

I am actually having a very similar problem with the collink option "-a" vs "-H".

If I apply the .cal file with -a I get yellowish whites (vs 255) up to 252.  If I use -H everything looks perfect.  This is using madVR in windowed or full screen exclusive mode, Nvidia GTX Titan, LED IPS (Overlord X270OC), and an i1display pro.

Here is the collection of files (.ti3 etc) I used and got along with the batch file I ran:

noLUT.7z

The 3DLUT incase you want it.

Please let me know if you need anything else.

I didn't notice this at first because I usually use madVR in overlay mode which I understand clips brighter than white in this situation.  I would be very grateful if could take a look, having Argyllcms + madVR is wonderful for my HTPC. :)

08:31 AM Liked: 163
post #1540 of 2877
03-03-2014 | Posts: 5,507
Joined: May 2005
Quote:
Originally Posted by gwgill

no .ti3, no linking details, no point investigating the end result when I can't see how it was arrived at.

You can find the details in Asmodian's post (one above this), he has the same problem.
zoyd
09:22 AM Liked: 466
post #1541 of 2877
03-03-2014 | Posts: 5,103
Joined: Sep 2006
Quote:
Originally Posted by Asmodian

I am actually having a very similar problem with the collink option "-a" vs "-H".

One thing I notice in your nolut measurements is that you have a very high white level (250 cd/m^2) and that the blue channel luminance has very poor scaling. I suspect this has something to do with the appearance of yellow, which is essentially blue clipping, in your wtw range.

Asmodian
09:39 AM Liked: 10
post #1542 of 2877
03-03-2014 | Posts: 11
Joined: Mar 2014

I see, so it is not really an issue, it is only that color correction breaks down above white?  This makes sense as it is not possible to increase blue to go whiter than white with a correct white.  I suppose the ramps included by -H are clipping whiter than white?

Thanks :)

zoyd
09:48 AM Liked: 466
post #1543 of 2877
03-03-2014 | Posts: 5,103
Joined: Sep 2006
Quote:
Originally Posted by Asmodian

I see, so it is not really an issue, it is only that color correction breaks down above white?  This makes sense as it is not possible to increase blue to go whiter than white with a correct white.  I suppose the ramps included by -H are clipping whiter than white?

Thanks

Yes, I suspect it is a display limitation and not the 3DLUT, but I don't know why -a gives different wtw behavior vs. -H.
Asmodian
10:08 AM Liked: 10
post #1544 of 2877
03-03-2014 | Posts: 11
Joined: Mar 2014

Actually I think -H has to clip wtw.  If desktop 255:255:255 white is my correct white point then there is no way for madVR to output any color wtw.  I see how it is a feature to allow wtw display when using only a 3DLUT, only on my display it goes so yellow it looks odd.

mightyhuhn
10:20 AM Liked: 132
post #1545 of 2877
03-03-2014 | Posts: 810
Joined: Nov 2013

i get "pink" bars up to 237 on 3-whiteClipping.mp4.my display got a white point of d6500 0.2 - 0.3 delta before calibration with 280 cm^2.

does this mean my calibration is not working or is this a display limitation too?

10:25 AM Liked: 163
post #1546 of 2877
03-03-2014 | Posts: 5,507
Joined: May 2005
Quote:
Originally Posted by zoyd

Yes, I suspect it is a display limitation and not the 3DLUT

I don't think so. Let's look at some numbers:

WTW test pattern, bar 240:

encoded YCbCr value: F0 80 80 -> 240 128 128
TV RGB without 3dlut: F0 F0 F0 -> 240 240 240
TV RGB Asmodian 3dlut: F0 E9 D9 -> 240 233 217

So it's pretty clear that the white bar 240, which before 3dlut processing is completely (all 3 components) in the WTW area, after 3dlut processing moves back into the visible range, and very noticeably so. This is clearly not as intended and needs to be fixed, IMHO.
zoyd
01:13 PM Liked: 466
post #1547 of 2877
03-03-2014 | Posts: 5,103
Joined: Sep 2006
Quote:

I don't think so. Let's look at some numbers:

WTW test pattern, bar 240:

encoded YCbCr value: F0 80 80 -> 240 128 128
TV RGB without 3dlut: F0 F0 F0 -> 240 240 240
TV RGB Asmodian 3dlut: F0 E9 D9 -> 240 233 217

So it's pretty clear that the white bar 240, which before 3dlut processing is completely (all 3 components) in the WTW area, after 3dlut processing moves back into the visible range, and very noticeably so. This is clearly not as intended and needs to be fixed, IMHO.

I think something about the native behavior of the display's blue channel causes the extrapolation to fail and generate that 217 which will cause a 240,240,240 input to look yellow. It doesn't move anything back into the visible range, it just gets the wrong correction for that input. Extrapolation may not be a good idea if this type of thing is common.

edit:

I should have read Graeme's response above where he states output values should not range below wtw if they start out above, so that does appear to be unintended regardless of what's going on with display native response.
Elix
12:44 PM Liked: 39
post #1548 of 2877
03-04-2014 | Posts: 1,294
Joined: Jun 2011
Quote:
Originally Posted by fhoech

Hmm. I'm doubting it's because of my change, which shouldn't affect 3D LUT creation at all
Yes, you must be right. I might've done everything right this time is all.

My Optoma GT760 is quite color-deficient:

Yet 3DLUT-corrected images look very good. Greens are fixed especially well. On the comparison photos I made you can clearly see that: http://screenshotcomparison.com/comparison/65322/picture:4

One thing though, my gamma is a little bit low: 2.12 average. I chose BT1886 absolute gamma during calibration.

I have a question. If I haven't done calibrate & profile but just profile, can I make a calibration curve out of that profile curve above?
Asmodian
06:17 PM Liked: 10
post #1549 of 2877
03-05-2014 | Posts: 11
Joined: Mar 2014
Quote:

I don't think so. Let's look at some numbers:

WTW test pattern, bar 240:

encoded YCbCr value: F0 80 80 -> 240 128 128
TV RGB without 3dlut: F0 F0 F0 -> 240 240 240
TV RGB Asmodian 3dlut: F0 E9 D9 -> 240 233 217

So it's pretty clear that the white bar 240, which before 3dlut processing is completely (all 3 components) in the WTW area, after 3dlut processing moves back into the visible range, and very noticeably so. This is clearly not as intended and needs to be fixed, IMHO.

I have been thinking about this issue some more and I was wondering what encoded YCbCr value: EB 80 80 -> 235 128 128 looked like after my "TV RGB Asmodian 3dlut"?  If all values were less than 240, 233, 217 wouldn't that mean 240 233 217 was actually outside visible range if I was clipping wtw?

Maybe there really isn't anything to improve and an option to clip wtw/btb when using a TV range 3DLUT would be helpful for those of us with displays whose native behavior is bad enough extrapolated wtw display looks funny?

Edit: Though I have been using a similar 3DLUT (collink -a) with the new madVR (v0.87.5) for a bit now and because none of my content has much in the way of wtw I am happy with the way it is now.  At least as far as I can tell, I will leave it to others better able to tell if something unintended is going on with wtw display.

01:16 PM Liked: 163
post #1550 of 2877
03-06-2014 | Posts: 5,507
Joined: May 2005
Quote:
Originally Posted by Asmodian

I have been thinking about this issue some more and I was wondering what encoded YCbCr value: EB 80 80 -> 235 128 128 looked like after my "TV RGB Asmodian 3dlut"?  If all values were less than 240, 233, 217 wouldn't that mean 240 233 217 was actually outside visible range if I was clipping wtw?

I don't think so. But let's wait for Graeme to analyze this.
01:23 PM Liked: 163
post #1551 of 2877
03-06-2014 | Posts: 5,507
Joined: May 2005
The latest madVR build v0.87.6 now offers several dithering algorithms. Older builds used random dithering, which worked alright, but was quite noisy. The new build now has several options. However, for single-colored test patterns "ordered dithering" seems to work best, so that is what madTPG will always use now. Which means that it doesn't matter which dithering algorithm you select in the madVR settings, madTPG will overwrite your choice and always use ordered dithering. There are however 2 additional options which affect every algorithm and madTPG will honor your wishes for these 2 options:

(1) "use colored noise": Using multi-colored noise means that the noise will use more shades of different colors to achieve a smoother result. This option lowers luma noise but slightly increases chroma noise.

(2) "change dither for every frame": This option results in madVR/TPG using a different dither pattern for every rendered video frame, which means that the dither dots are dancing around quite a bit. Enabling this option hides the dither pattern nicely, but results in some temporal noise.

Now it would be great if you guys could run a few tests to find out how these options should ideally be set for madTPG. Maybe if we can find a clearly best option set, I can enforce those for madTPG, to protect users from using suboptimal options. Feedback welcome!
MSL_DK
01:08 AM Liked: 10
post #1552 of 2877
03-07-2014 | Posts: 135
Joined: Nov 2011
Is there someone who can tell what is happening with cyan and yellow? Cyan is way off with 3DLUT

.chc files for HCFR is attached.

Workflow
Code:
targen -v -d3 -G -e4 -B8 -g40 -s20 -f2500 -V1.3 -N0.75 -c C:\Argyll_V1.6.3\ref\Rec709.icm mvr
colprof -v -qh -bl -ax mvr
collink -v -qh -3m -et -Et -G -IB -ia -w  C:\Argyll_V1.6.3\ref\rec709.icm mvr.icm 3DLUT_madVR.icm


Argyll ti1 + ti3 + icm

Without 3DLUT (Pattern Intensity 75%)

Without 3DLUT (Pattern Intensity 100%)

With 3DLUT (Pattern Intensity 75%)

With 3DLUT (Pattern Intensity 100%)

zoyd
03:27 PM Liked: 466
post #1553 of 2877
03-07-2014 | Posts: 5,103
Joined: Sep 2006
You seem to have an uncooperative gamut, I would give it one more try but use your measured profile (mvr.icm) to precondition and up the patch count to 3k or 4k.
gwgill
10:32 PM Liked: 93
post #1554 of 2877
03-07-2014 | Posts: 691
Joined: Jan 2013
Quote:
Originally Posted by MSL_DK

Is there someone who can tell what is happening with cyan and yellow? Cyan is way off with 3DLUT
From the look of it you aren't actually using the 3DLut. The plots look almost identical.
MSL_DK
04:30 AM Liked: 10
post #1555 of 2877
03-08-2014 | Posts: 135
Joined: Nov 2011
Quote:
Originally Posted by zoyd

You seem to have an uncooperative gamut, I would give it one more try but use your measured profile (mvr.icm) to precondition and up the patch count to 3k or 4k.

Like this?
Code:
targen -v -d3 -G -e4 -B8 -g40 -s20 -f4000 -V1.3 -N0.75 -c C:\Argyll_V1.6.3\ref\Rec709.icm mvr_PASS_1
colprof -v -qh -bl -ax mvr_PASS_1

targen -v -d3 -G -e4 -B8 -g40 -s20 -f4000 -V1.3 -N0.75 -c mvr_PASS_1.icm mvr_PASS_2
colprof -v -qh -bl -ax mvr_PASS_2
collink -v -qh -3m -et -Et -G -IB -ia -w  C:\Argyll_V1.6.3\ref\rec709.icm mvr_PASS_2.icm 3DLUT_madVR.icm


Quote:
Originally Posted by gwgill

From the look of it you aren't actually using the 3DLut. The plots look almost identical.

How this?

With 3DLUT

Without 3DLUT

zoyd
04:40 AM Liked: 466
post #1556 of 2877
03-08-2014 | Posts: 5,103
Joined: Sep 2006
Quote:
Originally Posted by MSL_DK

Like this?

You can skip step 1 and just use your prior mvr.icm in step 2.
Code:

targen -v -d3 -G -e4 -B8 -g40 -s20 -f4000 -V1.3 -N0.75 -c mvr.icm mvr_PASS_2
colprof -v -qh -bl -ax mvr_PASS_2
collink -v -qh -3m -et -Et -G -IB -ia -w  C:\Argyll_V1.6.3\ref\rec709.icm mvr_PASS_2.icm 3DLUT_madVR.icm


MSL_DK
05:04 AM Liked: 10
post #1557 of 2877
03-08-2014 | Posts: 135
Joined: Nov 2011
Quote:
Originally Posted by zoyd

You can skip step 1 and just use your prior mvr.icm in step 2.
Code:

targen -v -d3 -G -e4 -B8 -g40 -s20 -f4000 -V1.3 -N0.75 -c mvr.icm mvr_PASS_2
colprof -v -qh -bl -ax mvr_PASS_2
collink -v -qh -3m -et -Et -G -IB -ia -w  C:\Argyll_V1.6.3\ref\rec709.icm mvr_PASS_2.icm 3DLUT_madVR.icm


Thanks a lot. i'll give it a try tonight.

But i think i have to start over and set my samsung to native instead of auto. I don't quite understand what that setting does relative to profiling with argyll.
zoyd
05:07 AM Liked: 466
post #1558 of 2877
03-08-2014 | Posts: 5,103
Joined: Sep 2006
Quote:
Originally Posted by MSL_DK

Thanks a lot. i'll give it a try tonight.

But i think i have to start over and set my samsung to native instead of auto. I don't quite understand what that setting does relative to profiling with argyll.

Use native, it gives you a larger volume to work with. You do not need 4000 patches to do the first run, 1500 would be fine.
MSL_DK
07:42 AM Liked: 10
post #1559 of 2877
03-08-2014 | Posts: 135
Joined: Nov 2011
Quote:
Originally Posted by zoyd

Use native, it gives you a larger volume to work with. You do not need 4000 patches to do the first run, 1500 would be fine.

Ok. I think i have misunderstood native versus auto ... I thought this were wider (auto)

Than this (native)

Another thing ... looking on the gamma plot, would it be better to calibrate to 20% and 80% than 20% and 100% and profile, or does it have no effect on gamma?

Using your recommendation i get this result

zoyd
08:05 AM Liked: 466
post #1560 of 2877
03-08-2014 | Posts: 5,103
Joined: Sep 2006
Quote:
Originally Posted by MSL_DK

Ok. I think i have misunderstood native versus auto ... I thought this were wider (auto)

Usually it's the other way around but you are right, your green primary in auto is more saturated than native.
Quote:
Another thing ... looking on the gamma plot, would it be better to calibrate to 20% and 80% than 20% and 100% and profile, or does it have no effect on gamma?

no, stick to 100% for white balance calibration, gamma is adjusted through the linking process.
Quote:
Using your recommendation i get this result

Looks better.