MadVR - ArgyllCMS - Page 52 - AVS Forum
First ... 50  51  52 53  54  ... Last
Display Calibration > MadVR - ArgyllCMS
fhoech's Avatar fhoech 12:03 PM 03-01-2014
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" smile.gif

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

madshi's Avatar madshi 02:31 AM 03-02-2014
@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's Avatar zoyd 04:59 AM 03-02-2014
Quote:
Originally Posted by madshi View Post

@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's Avatar gwgill 05:18 AM 03-03-2014
Quote:
Originally Posted by madshi View Post

@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.
madshi's Avatar madshi 05:35 AM 03-03-2014
@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's Avatar Elix 06:00 AM 03-03-2014
Quote:
Originally Posted by fhoech View Post

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 smile.gif
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's Avatar gwgill 06:52 AM 03-03-2014
Quote:
Originally Posted by madshi View Post

@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's Avatar fhoech 07:31 AM 03-03-2014
Quote:
Originally Posted by Elix View Post

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 smile.gif 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's Avatar Asmodian 08:07 AM 03-03-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. :)


madshi's Avatar madshi 08:31 AM 03-03-2014
Quote:
Originally Posted by gwgill View Post

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's Avatar zoyd 09:22 AM 03-03-2014
Quote:
Originally Posted by Asmodian View Post

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's Avatar Asmodian 09:39 AM 03-03-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's Avatar zoyd 09:48 AM 03-03-2014
Quote:
Originally Posted by Asmodian View Post

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

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's Avatar Asmodian 10:08 AM 03-03-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's Avatar mightyhuhn 10:20 AM 03-03-2014

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?


madshi's Avatar madshi 10:25 AM 03-03-2014
Quote:
Originally Posted by zoyd View Post

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's Avatar zoyd 01:13 PM 03-03-2014
Quote:
Originally Posted by madshi View Post

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's Avatar Elix 12:44 PM 03-04-2014
Quote:
Originally Posted by fhoech View Post

Hmm. I'm doubting it's because of my change, which shouldn't affect 3D LUT creation at all smile.gif
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's Avatar Asmodian 06:17 PM 03-05-2014
Quote:
Originally Posted by madshi View Post


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


madshi's Avatar madshi 01:16 PM 03-06-2014
Quote:
Originally Posted by Asmodian View Post

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.
madshi's Avatar madshi 01:23 PM 03-06-2014
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's Avatar MSL_DK 01:08 AM 03-07-2014
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
dispread -v -dmadvr -c1 -Yp -yn -X WLEDFamily_07Feb11.ccss 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
ti1ti3icm.zip 406k .zip file

Without 3DLUT (Pattern Intensity 75%)
75_u_3dlut.zip 3k .zip file



Without 3DLUT (Pattern Intensity 100%)
100_u_3dlut.zip 3k .zip file



With 3DLUT (Pattern Intensity 75%)
75.zip 3k .zip file



With 3DLUT (Pattern Intensity 100%)
100.zip 3k .zip file


Attached: 75_u_3dlut.zip (3.2 KB)  100_u_3dlut.zip (3.2 KB)  75.zip (3.2 KB)  100.zip (3.2 KB)  ti1ti3icm.zip (405.7 KB) 
zoyd's Avatar zoyd 03:27 PM 03-07-2014
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's Avatar gwgill 10:32 PM 03-07-2014
Quote:
Originally Posted by MSL_DK View Post

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's Avatar MSL_DK 04:30 AM 03-08-2014
Quote:
Originally Posted by zoyd View Post

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
dispread -v -dmadvr -c1 -Yp -yn -X WLEDFamily_07Feb11.ccss 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
dispread -v -dmadvr -c1 -Yp -yn -X WLEDFamily_07Feb11.ccss 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 View Post

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

How this?

With 3DLUT




Without 3DLUT


zoyd's Avatar zoyd 04:40 AM 03-08-2014
Quote:
Originally Posted by MSL_DK View Post

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
dispread -v -dmadvr -c1 -Yp -yn -X WLEDFamily_07Feb11.ccss 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's Avatar MSL_DK 05:04 AM 03-08-2014
Quote:
Originally Posted by zoyd View Post

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
dispread -v -dmadvr -c1 -Yp -yn -X WLEDFamily_07Feb11.ccss 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's Avatar zoyd 05:07 AM 03-08-2014
Quote:
Originally Posted by MSL_DK View Post

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's Avatar MSL_DK 07:42 AM 03-08-2014
Quote:
Originally Posted by zoyd View Post

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's Avatar zoyd 08:05 AM 03-08-2014
Quote:
Originally Posted by MSL_DK View Post

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. smile.gif
First ... 50  51  52 53  54  ... Last

Up
Mobile  Desktop