MadVR - ArgyllCMS - Page 4 - AVS Forum
Forum Jump: 
 20Likes
Reply
 
Thread Tools
post #91 of 2493 Old 05-12-2013, 11:38 AM - Thread Starter
AVS Special Member
 
N3W813's Avatar
 
Join Date: Feb 2003
Posts: 1,137
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 4 Post(s)
Liked: 28
Quote:
Originally Posted by MSL_DK View Post

Yes ...

I uninstalled it all yesterday ... before was y = 6 Now is y = e and I can do nothing ... Can I get you to make a copy of your ArgyllCMS so I can compare with the one I just downloaded?

Do you meant the -y option for dispcal and dispread? If Graeme changed the parameters for the -y option, then I think DispcalGUI needs to be updated. You can contact Florian Hoech at http://sourceforge.net/p/dispcalgui/discussion/932493.

What meter are you using?

My ArgyllCMS/MadVR 3DLUT Creation Workflow
My Sharp Elite Movie THX AV Mode Settings
--Aug 2011 Set, 2.2 gamma [ link ]
--Nov 2012 Set, 2.2 gamma [ link ]
N3W813 is offline  
Sponsored Links
Advertisement
 
post #92 of 2493 Old 05-12-2013, 11:46 AM
Member
 
MSL_DK's Avatar
 
Join Date: Nov 2011
Location: Denmark
Posts: 116
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by N3W813 View Post

Do you meant the -y option for dispcal and dispread?

What meter are you using?

Yes ..

i1 DisplayPro: Argyll_V1.5.1/doc/instruments.html#i1d3
MSL_DK is offline  
post #93 of 2493 Old 05-12-2013, 11:57 AM - Thread Starter
AVS Special Member
 
N3W813's Avatar
 
Join Date: Feb 2003
Posts: 1,137
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 4 Post(s)
Liked: 28
Quote:
Originally Posted by MSL_DK View Post

Yes ..

i1 DisplayPro: Argyll_V1.5.1/doc/instruments.html#i1d3
Quote:
Originally Posted by MSL_DK View Post

Yes ..

i1 DisplayPro: Argyll_V1.5.1/doc/instruments.html#i1d3

I have a i1 Display Pro (i1D3) and I have no issues. In looking at my logs, the dispcal/dispread commandlines have the -y option set to -yn

Like I said, if Graeme changed the parameters for the -y option, then I think DispcalGUI needs to be updated. You can contact Florian Hoech at http://sourceforge.net/p/dispcalgui/discussion/932493.

Or else, just use ArgyllCMS from the command line instead until DispcalGUI is updated with the new parameter changes.

My ArgyllCMS/MadVR 3DLUT Creation Workflow
My Sharp Elite Movie THX AV Mode Settings
--Aug 2011 Set, 2.2 gamma [ link ]
--Nov 2012 Set, 2.2 gamma [ link ]
N3W813 is offline  
post #94 of 2493 Old 05-12-2013, 08:03 PM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 561
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 24 Post(s)
Liked: 70
Quote:
Originally Posted by alamagar View Post


I calibrate first using HCFR, and then I get the 3dLut file hitting the button "only profile" form dispcalGUI. Therefore I think no .cal file is created.
Wich method I should follow?

The display needs to be in the same state of calibration as it was when it was profiled. Anything other than that makes the profile invalid and useless.
gwgill is offline  
post #95 of 2493 Old 05-12-2013, 08:23 PM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 561
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 24 Post(s)
Liked: 70
Quote:
Originally Posted by cyberbeing View Post


Is the following working as intended? I thought the old builds were using Technical Gamma only, or did you silently change something in the 5/9/2012 build to do black point mapping?

Bt.1886 has always done black point mapping. -ila would also be doing it as well, except that the BT.1886 adjusts the source black point appropriately, which should null any black point mapping effect of -ila out.
Quote:


Collink 5/9/2012 [CRC: 66A544A9]: "collink -v -3m -et -Et -Ib -I2.4 -G -ila"

the above 3DLUT is nearly identical in gamma & black level (equaling zero) to:

Collink 5/11/2013 [CRC: BE98B91A]: "collink -v -3m -et -Et -Ib:2.253912 -G -ila" (Technical Gamma 2.400000, 2.253912 Effective Gamma)

but the following now has an elevated black level and a different gamma than the previous collink build:

Collink 5/11/2013 [CRC: BE98B91A]: "collink -v -3m -et -Et -IB:2.4 -G -ila" (Technical Gamma 2.400000)
Sorry, I've no idea why that would be. I would expect to see some changes to the black point calculation between 5/9/2012 and 5/11/2013 if the display black is out of gamut of the source space, but no difference otherwise in these three cases if the technical gamma for all of them is 2.4.
Quote:
[Edit2]

After doing some measurements, it would seem -Ib:x.x is working as intended. Whatever value you put in, it what you'll measure as the average gamma of the BT.1886 curve.
Yes. I would expect a log/log plot to go through the effective gamma value at 50%.
Quote:
The behavior I noted above, must have been a bug in the Collink 5/9/2013 [CRC: 66A544A9] build.
Not as far as I'm aware.
gwgill is offline  
post #96 of 2493 Old 05-12-2013, 08:41 PM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 561
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 24 Post(s)
Liked: 70
Quote:
Originally Posted by MSL_DK View Post

When I use "collink.exe -v -3m -qh -et -Et -Ib:2.2 -G -a display.cal -ial Rec709.icm display.icm madvr.icm" (ON: GPU gamma ramps)
Unfortunately I've little ideal what "ON: GPU gamma ramps" means or implies. I've yet had no definitive explanation from someone who knows, and on my system this switch does exactly nothing.
If it does something on your system, perhaps you can explain what it does.

Certainly if you are using "collink -a display.cal" then the calibration curves should not be used by the graphics card or MadVR, since that would be applying them twice, which is not how the display was being used when it was profiled.
Quote:
Before ArgyllCMS Viewing a white clipping pattern (flashing steps from 230-234)
Before ArgyllCMS Viewing a color clipping pattern (flashing steps from 219-233)
I really hope you can explain what's going on ...
Once again I'm struggling to know what you are asking, since you are not explicit about exactly what you think is a problem. Having the white clip pattern flag up to 234 is (as best I understand) ideal behaviour. As explored in a previous posting, the color ramp behaviour depends on how in or out of gamut the display is at its primaries. If the video primary is out of gamut for the display, then it will clip somewhere below 235. If the video primary is well within the display gamut, then it will clip somewhere over 235, although no video media should ever get that far. This is to be expected. The exact behavior can be modified to some degree by using other (non colorimetric) gamut mappings.
gwgill is offline  
post #97 of 2493 Old 05-12-2013, 08:49 PM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 561
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 24 Post(s)
Liked: 70
Quote:
Originally Posted by Sandy B Ridge View Post

So, will the test patches be displayed as windows desktop levels and clearly clipped, or at MadVR levels and be full range (but at 16-235)?
The dispcal/dispread -E options are analogous to MadVR outputing full or video range. If the graphics card is converting 0-255 to 16-235, then the application (ie. both dispcal/dispread and MadVR) should output full range. If on the other hand full range is being fed to the display, then the application (ie. both dispcal/dispread and MadVR) should output video range. In the case of dispcal/dispread, that's done by using the -E flag. To put it another way, if your display is expecting video range signals, make sure that exactly one part of the display chain of application->video_card->display is doing that conversion.
gwgill is offline  
post #98 of 2493 Old 05-12-2013, 11:02 PM
Member
 
cyberbeing's Avatar
 
Join Date: Apr 2006
Posts: 61
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by cyberbeing View Post

Device Link & Display ICM profiles + TI3

Is there any way to improve the color temperatures result after 3DLUT gamma correction, without resorting to dispcal?

I'm assuming the gamut mapping issue with CIECAM02 is a bug.

[All measurements taken with i1pro rev D in ColorHFCR 2.1]
_

@Graeme Gill

I could still use some advice about how to fix this color temperature issue.

Is this behavior actually a bug, or is there some way I could re-tweak my patch set to help prevent issues like this?

That patch set had 1.25% grayscale steps, 2.5% single channel steps, 25% multi-dimensional steps, and 768 full-spread. I would have expected it to be able to change the gamma without affecting color temperature by just finding the nearest measured step and interpolating. As my ColorHFCR 2.1 measurements were showing, color temperature was nearly perfect D65 down to the point where the i1pro starts to become less reliable. Was there something funky about my full-spread measurements which was throwing off the red channel?
cyberbeing is offline  
post #99 of 2493 Old 05-13-2013, 12:01 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 561
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 24 Post(s)
Liked: 70
Quote:
Originally Posted by cyberbeing View Post

I'm seeing some problems with the "or you could do it using pure CIECAM02 adjustment and a black point mapping" Scenario.

Problem #1: Gamut correction on my primary colors is not being performed.
Well, your own chromaticity plots show that the primaries are being corrected.

Note that there is a lot of gamut clipping going on in this situation, since all the Reec709 primaries are out of gamut of your display. This leaves some scope for different but equally valid clipping results, and such clipping is affected by the details of the mapping space:

xicclu -ff -ir -pl -a 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]

xicclu -fif -ir -pl -a GDMF520_1084.icm
54.285218 80.831212 69.906123 [Lab] -> Lut -> 1.000000 0.000000 0.064667 [RGB] (clip)
[Actual 57.514318 78.530772 69.749600, deltaE 3.967822]

87.820812 -79.285064 80.992273 [Lab] -> Lut -> 0.186427 1.000000 0.012334 [RGB] (clip)
[Actual 85.630279 -79.336492 80.785155, deltaE 2.200903]

29.569144 68.284819 -112.028372 [Lab] -> Lut -> 0.386165 0.000000 1.000000 [RGB] (clip)
[Actual 39.359712 53.436849 -96.391294, deltaE 23.681969]
Quote:
Problem #2: Color temperature issues wherever the 3DLUT lowers gamma
I'm not sure what you mean. Color temperature numbers are notoriously non-perceptual,
therefore the significance of any deviation from ideal can't be judged by looking at such a graph.

If you check the neutrality of the two links, they are less than 1 delta E of each other
at 25% (the worst case according to your graph):

collink -v -r65 -Ib:2.4 -G -ila Rec709.icm GDMF520_1084.icm:
0.250000 0.250000 0.250000 [RGB] -> Lut -> 0.266033 0.265896 0.264235 [RGB]

-r65 -ctv -ds:n -da:1 -dl:86.224792 -G -ila Rec709.icm GDMF520_1084.icm:
0.250000 0.250000 0.250000 [RGB] -> Lut -> 0.273980 0.268591 0.265761 [RGB]

xicclu -ff -ir -pl -a GDMF520_1084.icm
0.266033 0.265896 0.264235 [RGB] -> Lut -> 23.978634 0.189930 0.148262 [Lab]
0.273980 0.268591 0.265761 [RGB] -> Lut -> 24.440102 0.761707 0.595471 [Lab]

In addition, you are applying CIE colorimetric error measures to a link that is not aiming at minimising such errors, it is instead aiming to minimise appearance discrepancies. For instance, simple models assumed that the viewer 100% adapts to the source white point. The model that CIECAM uses doesn't assume that. Rec709 and your display have a slightly different white point, and (as far as I am able to determine), this is what causes the very slight shift in neutral axis response in the mid tones illustrated above.
Quote:
Is there any way to improve the color temperatures result after 3DLUT gamma correction, without resorting to dispcal?
As far as I can currently tell, CIECAM viewing condition adaptation is working as intended. You are probably heading in the wrong direction if you want it to measure like a CIE XYZ based mapping, since that is not what it sets out to do.

(It is a little hard to explore all the underlying explanations for your various measurement results due to the Rec709 primaries being out of gamut, and not being 100% sure what some of your test values are - for instance, what's the center of your plots from neutral to the primaries - is it 50% grey or something else ?)

CIECAM02 attempts to model appearance more accurately than pure CIE XYZ values, so at the end of the day it would be interesting to know what it look like in real life ?
gwgill is offline  
post #100 of 2493 Old 05-13-2013, 12:04 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 561
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 24 Post(s)
Liked: 70
Quote:
Originally Posted by MSL_DK View Post

Newest ArgyllCMS update for madVR 3DLUT version does not work with DispcalGUI due to changes in "Argyll_V1.5.1/doc/instruments.html#i1d3"

Before -y6 now -ye

You'd best contact Florian Hoech then. (V1.5.0 has been out a little while now).
gwgill is offline  
post #101 of 2493 Old 05-13-2013, 12:46 AM
Member
 
MSL_DK's Avatar
 
Join Date: Nov 2011
Location: Denmark
Posts: 116
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by gwgill View Post

You'd best contact Florian Hoech then. (V1.5.0 has been out a little while now).

dispcalGUI 1.2.7.0 works with ArgyllCMS V1.5.1 but not with "ArgyllCMS beta update for madVR 3DLUT creation ** last update 05-11-13"
MSL_DK is offline  
post #102 of 2493 Old 05-13-2013, 02:53 AM
Member
 
cyberbeing's Avatar
 
Join Date: Apr 2006
Posts: 61
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by gwgill View Post

I'm not sure what you mean. Color temperature numbers are notoriously non-perceptual,
therefore the significance of any deviation from ideal can't be judged by looking at such a graph.

Native 30% gray: 1.9dE x0.312 y0.327 Y4.476 6549K
Native 50% gray: 1.0dE x0.313 y0.328 Y15.653 6509K
Native 70% gray: 0.5dE x0.313 y0.329 Y35.746 6483K
Native 90% gray: 0.5dE x0.312 y0.328 6519K
Native Whitepoint: 1.3dE x0.313 y0.328 6502K


3DLUT BT.1886 30% gray: 2.9dE x0.316 y0.329 Y5.074 6327K
3DLUT BT.1886 50% gray: 1.1dE x0.314 y0.329 6435K
3DLUT BT.1886 70% gray: 1.2dE x0.314 y0.330 6424K
3DLUT BT.1886 90% gray: 0.1dE x0.313 y0.329 6495K
3DLUT BT.1886 Whitepoint: 0.4dE x0.313 y0.329 6482K


3DLUT CIECAM02 30% gray: 3.8dE x0.317 y0.329 Y5.012 6227K
3DLUT CIECAM02 50% gray: 3.2dE x0.316 y0.329 Y15.443 6316K
3DLUT CIECAM02 70% gray: 2.1dE x0.315 y0.329 Y35.012 6383K
3DLUT CIECAM02 90% gray: 1.0dE x0.313 y0.328 6483K
3DLUT CIECAM02 Whitepoint: 1.0dE x0.312 y0.328 6537K

The D65 target of REC709 is 0.312713x 0.329016y 6504K, so when the 3DLUT adds too much red channel which lowers the color temperature to ~6200-6300K that's too far off.

I'd like to see <=1.5dE from 0.312713x 0.329016y 6504K, which just isn't happening with CIECAM02 3DLUT <=70% and BT.1886 3DLUT <=40%.

The 3DLUT is shifting the X chromaticity coordinate of the neutral grayscale away from target, which I don't think should be occurring.

Quote:
If you check the neutrality of the two links, they are less than 1 delta E of each other
at 25% (the worst case according to your graph):

My measurements show a difference of ~2dE between the two 3DLUTs @25%.

CIECAM02 3DLUT has a 4.1dE @25%
BT.1886 3DLUT has a 2.3dE @25%

Quote:
In addition, you are applying CIE colorimetric error measures to a link that is not aiming at minimising such errors, it is instead aiming to minimise appearance discrepancies. For instance, simple models assumed that the viewer 100% adapts to the source white point. The model that CIECAM uses doesn't assume that. Rec709 and your display have a slightly different white point, and (as far as I am able to determine), this is what causes the very slight shift in neutral axis response in the mid tones illustrated above.

Hmm.. Argyll's white point reading may be half the problem.


Official X-Rite driver reported white point: 0.312919x 0.327632y

Argyll TI3 file shows an average white point: 0.311757x 0.327943y

Argyll Dispcal reported white point pre-calibration (as of now): 0.3122x 0.3280y


So it would seem that could partially explain the problem, especially if this difference becomes larger in lower luminance. The differences in X chromaticity readings compared to the official driver are much larger than I would have imagined. Argyll's readings seem to think white point is too cool, while the X-Rite driver thinks white point is very close to neutral D65.


I only fixed my problems with ColorHCFR 3.0.4.2 & Libusb after I did these measurements with ColorHCFR 2 & X-Rite driver.
I'll try to repeat everything using ColorHCFR 3.0.4.2 for pre-calibration, and see if that improves these results.

Quote:
As far as I can currently tell, CIECAM viewing condition adaptation is working as intended. You are probably heading in the wrong direction if you want it to measure like a CIE XYZ based mapping, since that is not what it sets out to do.

(It is a little hard to explore all the underlying explanations for your various measurement results due to the Rec709 primaries being out of gamut, and not being 100% sure what some of your test values are - for instance, what's the center of your plots from neutral to the primaries - is it 50% grey or something else ?)

CIECAM02 attempts to model appearance more accurately than pure CIE XYZ values, so at the end of the day it would be interesting to know what it look like in real life ?

The plots are from ColorHCFR, so whatever it defaults to.

Well, the only reason I'm using CIECAM02 for scaling the BT.709 curve, is because Collink does not support Dispcal style luminance only CIECAM02 ambient light scaling. When I asked on Doom9, you said I should just use the entire CIECAM02 model to achieve this instead.

From what I can tell, it does scale gamma similar to Dispcal, but the values needed don't seem to match up. I needed to specify -d a:1 in order to get a curve similar to Dispcal 32lux ambient with a REC709 curve which confused me a bit. If you think CIECAM02 is indeed heading me in the wrong direction, I'd encourage you to add support for the simplified CIECAM02 luma-only ambient light scaling method of Dispcal.
cyberbeing is offline  
post #103 of 2493 Old 05-13-2013, 05:38 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 561
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 24 Post(s)
Liked: 70
Quote:
Originally Posted by MSL_DK View Post

dispcalGUI 1.2.7.0 works with ArgyllCMS V1.5.1 but not with "ArgyllCMS beta update for madVR 3DLUT creation ** last update 05-11-13"

I'm not quite sure then, what change has broken it. There are a couple of minor option changes, but I would be a bit surprised if DispcalGUI was using them, since they are rarely used options.
gwgill is offline  
post #104 of 2493 Old 05-13-2013, 06:12 AM
Member
 
MSL_DK's Avatar
 
Join Date: Nov 2011
Location: Denmark
Posts: 116
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by gwgill View Post

I'm not quite sure then, what change has broken it. There are a couple of minor option changes, but I would be a bit surprised if DispcalGUI was using them, since they are rarely used options.

One thing could be the "2D Diagnostic Graph Plot" you are showing smile.gif As I am forced to close before "dispcal-r" to continue
MSL_DK is offline  
post #105 of 2493 Old 05-13-2013, 07:18 AM
Member
 
MSL_DK's Avatar
 
Join Date: Nov 2011
Location: Denmark
Posts: 116
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by gwgill View Post

Unfortunately I've little ideal what "ON: GPU gamma ramps" means or implies. I've yet had no definitive explanation from someone who knows, and on my system this switch does exactly nothing.
If it does something on your system, perhaps you can explain what it does..

I do not know ... but I know it does not work for me. I hope madshi can provide some answers to the question.

"collink.exe -v -3m -qh -et -Et -Ib:2.2 -G -ial Rec709.icm display.icm madvr.icm" dispwin display.cal (OFF: GPU gamma ramps)

Gives me a good result!
MSL_DK is offline  
post #106 of 2493 Old 05-13-2013, 07:34 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 561
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 24 Post(s)
Liked: 70
Quote:
Originally Posted by cyberbeing View Post


3DLUT BT.1886 30% gray: 2.9dE x0.316 y0.329 Y5.074 6327K
3DLUT BT.1886 50% gray: 1.1dE x0.314 y0.329 6435K
3DLUT BT.1886 70% gray: 1.2dE x0.314 y0.330 6424K
3DLUT BT.1886 90% gray: 0.1dE x0.313 y0.329 6495K
3DLUT BT.1886 Whitepoint: 0.4dE x0.313 y0.329 6482K

3DLUT CIECAM02 30% gray: 3.8dE x0.317 y0.329 Y5.012 6227K
3DLUT CIECAM02 50% gray: 3.2dE x0.316 y0.329 Y15.443 6316K
3DLUT CIECAM02 70% gray: 2.1dE x0.315 y0.329 Y35.012 6383K
3DLUT CIECAM02 90% gray: 1.0dE x0.313 y0.328 6483K
3DLUT CIECAM02 Whitepoint: 1.0dE x0.312 y0.328 6537K
I'm not sure why there is such a discrepancy between what the profile predicts, and what you are measuring. I can see nothing like DE 3.2 at 50% according to the numbers:

CIECAM02 cLUT:
0.500000 0.500000 0.500000 [RGB] -> Lut -> 0.502586 0.495144 0.494496 [RGB]

Display profile:
0.502586 0.495144 0.494496 [RGB] -> Lut -> 49.802371 0.735699 0.599404 [Lab]

So that's a predicted 0.95 delta E. It seems like the profile is not reflecting the display behaviour ??
Quote:
The 3DLUT is shifting the X chromaticity coordinate of the neutral grayscale away from target, which I don't think should be occurring.

It can happen. CIECAM02 models the range compression in each of the eye's color sensors, and that appears to interact with the incomplete chromatic adaptation to to give a slight variance down the neutral axis from the white color. If chromatic adapation was complete, this effect basically disappears. You can't simply say this is wrong, since it is modelling human perception, something that Yxy numbers don't.
Quote:

Hmm.. Argyll's white point reading may be half the problem.

Official X-Rite driver reported white point: 0.312919x 0.327632y

Argyll TI3 file shows an average white point: 0.311757x 0.327943y

Argyll Dispcal reported white point pre-calibration (as of now): 0.3122x 0.3280y

So it would seem that could partially explain the problem, especially if this difference becomes larger in lower luminance. The differences in X chromaticity readings compared to the official driver are much larger than I would have imagined. Argyll's readings seem to think white point is too cool, while the X-Rite driver thinks white point is very close to neutral D65.
I'm pretty confident that Argyll's driver and X-Rite's are in very close agreement, since I've done a fair amount of testing on that aspect. My testing indicates a difference of less than 0.2 delta E or less, smaller than screen re-positioning errors, display inconsistency, and instrument drift. So I would look elsewhere first for an explanation.
Quote:
The plots are from ColorHCFR, so whatever it defaults to.
It's not something I'm familiar with.
Quote:
When I asked on Doom9, you said I should just use the entire CIECAM02 model to achieve this instead.
Which you can. But it does it's CIECAM02 thing, and needs to be assessed on its merits, and not as some means to do Rec709 by the numbers, since it goes rather beyond that.
Quote:
From what I can tell, it does scale gamma similar to Dispcal, but the values needed don't seem to match up. I needed to specify -d a:1 in order to get a curve similar to Dispcal 32lux ambient with a REC709 curve which confused me a bit.
Right, but you were doing something a little strange, which was not using a pre-canned viewing condition as a starting point. The other thing is that my CIECAM02 model includes a flare & glare model, and this has an impact on how it behaves. Once these are taken into account, you do not get quite the same response as a pure gamma/power model that excludes these factors. The use of CIECAM02 to create an ambient lighting model in dispcal is slightly different, since it is distilled into a pure adjustment curve.
Quote:
If you think CIECAM02 is indeed heading me in the wrong direction, I'd encourage you to add support for the simplified CIECAM02 luma-only ambient light scaling method of Dispcal.
If you want something that is more easily verified, what's wrong with the existing power adjustment options ?
gwgill is offline  
post #107 of 2493 Old 05-13-2013, 07:42 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 561
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 24 Post(s)
Liked: 70
Quote:
Originally Posted by MSL_DK View Post

One thing could be the "2D Diagnostic Graph Plot" you are showing smile.gif As I am forced to close before "dispcal-r" to continue
Yes, that would explain it. I've updated http://www.argyllcms.com/Win32_collink_3dlut.zip with a version that (I hope) doesn't have that compiled into it. See if it works better with DispcalGUI.
gwgill is offline  
post #108 of 2493 Old 05-13-2013, 07:52 AM
Member
 
MSL_DK's Avatar
 
Join Date: Nov 2011
Location: Denmark
Posts: 116
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by gwgill View Post

Yes, that would explain it. I've updated http://www.argyllcms.com/Win32_collink_3dlut.zip with a version that (I hope) doesn't have that compiled into it. See if it works better with DispcalGUI.

Thank you ... smile.gif I'll give it a try later today.
MSL_DK is offline  
post #109 of 2493 Old 05-13-2013, 08:13 AM
Member
 
MSL_DK's Avatar
 
Join Date: Nov 2011
Location: Denmark
Posts: 116
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by gwgill View Post

Yes, that would explain it. I've updated http://www.argyllcms.com/Win32_collink_3dlut.zip with a version that (I hope) doesn't have that compiled into it. See if it works better with DispcalGUI.

The problem is unfortunately not solved.

MSL_DK is offline  
post #110 of 2493 Old 05-13-2013, 01:16 PM - Thread Starter
AVS Special Member
 
N3W813's Avatar
 
Join Date: Feb 2003
Posts: 1,137
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 4 Post(s)
Liked: 28
Quote:
Originally Posted by MSL_DK View Post

The problem is unfortunately not solved.


I also confirm this issue.

My ArgyllCMS/MadVR 3DLUT Creation Workflow
My Sharp Elite Movie THX AV Mode Settings
--Aug 2011 Set, 2.2 gamma [ link ]
--Nov 2012 Set, 2.2 gamma [ link ]
N3W813 is offline  
post #111 of 2493 Old 05-13-2013, 02:38 PM
Member
 
cyberbeing's Avatar
 
Join Date: Apr 2006
Posts: 61
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by gwgill View Post

It seems like the profile is not reflecting the display behaviour ??
That seems to be the case, but I'm wondering why? Is it a problem with my patch set, my measurements, or a bug in colprof/collink code?

Is there anything I can do myself to attempt to fix it?

Quote:
Which you can. But it does it's CIECAM02 thing, and needs to be assessed on its merits, and not as some means to do Rec709 by the numbers, since it goes rather beyond that.

It it even possible to objectively assess CIECAM02 quality?

I must have gone through ~20-30 different variations of CIECAM02 3DLUT since the parameters are confusing. The more I read about CIECAM02, the more I think it's not designed to be used in the static way you've implemented it for anything but gamma correction. The CIECAM02 parameters seem like they need to adapt dynamically to the exact properties of each and every single image frame of a video. In particular the surround parameter, I believe is supposed to be content adaptive.

My interpretation:
Image white = TV/Monitor Peak Luminance
Adaptation luminance = Ambient Light
Background = Image Luminance (median) / Peak Luminance (Film: ~20%, Japanese Anime ~40%)
Surround = Needs to be content/pixel adaptive? Otherwise it seemed to describe the luminosity from the Background parameter.

Do I have the purpose of "Adaptation Luminance" and "Surround" mixed up?

Quote:
Right, but you were doing something a little strange, which was not using a pre-canned viewing condition as a starting point. The other thing is that my CIECAM02 model includes a flare & glare model, and this has an impact on how it behaves. Once these are taken into account, you do not get quite the same response as a pure gamma/power model that excludes these factors.
What is the source of the pre-canned profiles, I looked and I couldn't find them in the CIECAM02 specification? Do they trigger options not shown by collink -v?

I started with pre-canned profiles but after extensive testing, I discovered there was really no point in doing so. Almost no correction is done if you maintain identical values and/or ratios between source and destination for various parameters. For example, collink -ctv -da:17.2449584 -dl:86.224792 will yield almost identical results to collink -ctv -dmt because in both cases there is a 20% ratio between "Image white" & "Adaptation Luminance" At that point, it seemed better to fine-tune for my exact display properties.

Quote:
The use of CIECAM02 to create an ambient lighting model in dispcal is slightly different, since it is distilled into a pure adjustment curve.

I assume there is no way to force the current CIECAM02 options in collink to do this?

Quote:
If you want something that is more easily verified, what's wrong with the existing power adjustment options ?

I thought those were only for BT.1886 style curves? I was attempting to mimic that REC709 ambient light scaling which Dispcal uses. Was there a way to do this without enabling the entire CIECAM02 color appearance model?
cyberbeing is offline  
post #112 of 2493 Old 05-13-2013, 03:17 PM
Member
 
alamagar's Avatar
 
Join Date: Dec 2008
Posts: 31
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by N3W813 View Post

I also confirm this issue.
Me too
alamagar is offline  
post #113 of 2493 Old 05-13-2013, 07:31 PM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 561
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 24 Post(s)
Liked: 70
Quote:
Originally Posted by MSL_DK View Post

The problem is unfortunately not solved.
This should fix it for the i1d3 as well: http://www.argyllcms.com/Win32_collink_3dlut.zip
gwgill is offline  
post #114 of 2493 Old 05-14-2013, 01:42 AM
Member
 
cyberbeing's Avatar
 
Join Date: Apr 2006
Posts: 61
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by cyberbeing View Post

CIECAM02
...
My interpretation:
Image white = TV/Monitor Peak Luminance
Adaptation luminance = Ambient Light
Background = Image Luminance (median) / Peak Luminance (Film: ~20%, Japanese Anime ~40%)
Surround = Needs to be content/pixel adaptive? Otherwise it seemed to describe the luminosity from the Background parameter.

Do I have the purpose of "Adaptation Luminance" and "Surround" mixed up?

Thinking about this a bit more, should I be changing the scope of the CIECAM02 adaption from the TV/Display+Video+Room (as above) to just TV/Display+Room, ignoring the video properties?

Image white = TV/Monitor Peak Luminance
Adaptation luminance = Ambient Light
Background = Room Size + Luminance % in relation to TV/Monitor Size + Luminance?
Surround = Dark when Image white > Adaptation luminance. Mid when Image white is nearly equal to Adaptation luminance. Bright when Image white < Adaptation luminance?

That may allow CIECAM02 adaption to be used in a static way, but is it compatible with the Argyll implementation? When Argyll performs CIECAM02 adaption, what is the assumed scope? It would be problematic if CIECAM02 expected to be able to adjust the Background or Surround with an interpretation like this. Graeme can you explain why "Argyll Usage Scenarios" use the CIECAM02 parameters how they do in relation to my confusion over proper use of the parameters if I desired to fine-tune them for my exact viewing conditions?
cyberbeing is offline  
post #115 of 2493 Old 05-14-2013, 02:40 AM
Member
 
MSL_DK's Avatar
 
Join Date: Nov 2011
Location: Denmark
Posts: 116
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by gwgill View Post

This should fix it for the i1d3 as well: http://www.argyllcms.com/Win32_collink_3dlut.zip

Now collink is damaged ... "-v" does not work and I get a somewhat strange result ...

EDIT: dispcalGUI LOG
MSL_DK is offline  
post #116 of 2493 Old 05-14-2013, 03:27 AM
Member
 
cyberbeing's Avatar
 
Join Date: Apr 2006
Posts: 61
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by MSL_DK View Post

Now collink is damaged ... "-v" does not work and I get a somewhat strange result ...
That collink build isn't damaged, it just appears to be a debug build which outputs ~16.5 million lines (~581MB) of verbosity to the cmd window by default. The 3DLUT files it generates are identical to the prior build.

For the time being, you can silence it by adding >nul to the end of the command line, which will redirect the cmd window output to null.
Code:
collink -3 m -e t -E t -I b -G -i r Rec709.icm TV.icm HD.icm >nul
cyberbeing is offline  
post #117 of 2493 Old 05-14-2013, 03:49 AM
Member
 
MSL_DK's Avatar
 
Join Date: Nov 2011
Location: Denmark
Posts: 116
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by cyberbeing View Post

That collink build isn't damaged, it just appears to be a debug build which outputs ~16.5 million lines (~581MB) of verbosity to the cmd window by default. The 3DLUT files it generates are identical to the prior build.

For the time being, you can silence it by adding >nul to the end of the command line, which will redirect the cmd window output to null.
Code:
collink -3 m -e t -E t -I b -G -i r Rec709.icm TV.icm HD.icm >nul

Yes you are right ... But "Win32_collink_3dlut.zip" does not work with dispcalGUI. Readings works though. I have attached dispcalGUI log so you can see what happens, hope it is helpful.
MSL_DK is offline  
post #118 of 2493 Old 05-14-2013, 05:17 AM
Member
 
cyberbeing's Avatar
 
Join Date: Apr 2006
Posts: 61
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by cyberbeing View Post

Quote:
Originally Posted by gwgill View Post

It seems like the profile is not reflecting the display behaviour ??
That seems to be the case, but I'm wondering why? Is it a problem with my patch set, my measurements, or a bug in colprof/collink code?

Is there anything I can do myself to attempt to fix it?

Thinking towards a possible solution.

What would you think of the idea of integrating collink with dispread to do preliminary measurements of multiple potential 3DLUT corrections expanded from 16-235 -> 0-255 to mimic madVR? It could function in similar fashion to dispcal, except it would test multiple potential 3DLUT/DeviceLink corrections instead of VideoLUT corrections in order to fine-tune within a certain deltaE threshold compared to the optimal predicted deltaE based on profiling? Collink could then use these display measurement verified corrections to fine-tune/offset the 3DLUT for better results? A variation of this idea, would be to treat collink as a virtual measurement instrument, and use a modified version of ccxxmake to create a matrix correction file with a physical instrument (i.e. i1pro) used as the reference?

I'd expect doing something like this would increase the quality of Argyll CMS cLUT profiles all around, and mostly resolve problems with the generated cLUT occasionally making a bad prediction under certain conditions.
cyberbeing is offline  
post #119 of 2493 Old 05-14-2013, 05:42 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 561
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 24 Post(s)
Liked: 70
Quote:
Originally Posted by MSL_DK View Post

Now collink is damaged ... "-v" does not work and I get a somewhat strange result ...
Update with collink debugging turned off: http://www.argyllcms.com/Win32_collink_3dlut.zip
gwgill is offline  
post #120 of 2493 Old 05-14-2013, 06:38 AM
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,431
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 78 Post(s)
Liked: 299
Quote:
Originally Posted by gwgill View Post

Black is absolute in BT.1886, just like white, so if you scale white to 1, you have to scale black by the same amount, and the resulting offset & scale numbers come out of BT.1886 exactly the same.

You are absolutely correct (as usual). One last question regarding BT.1886, is the -I B switch in combination with Rec709.icm source profile exactly equivalent to using a source profile with technical BT.1886 embedded within it (assuming one could do that)?
zoyd is offline  
Reply Display Calibration

User Tag List

Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off