or Connect
AVS › AVS Forum › Display Devices › Display Calibration › MadVR - ArgyllCMS
New Posts  All Forums:Forum Nav:

MadVR - ArgyllCMS - Page 3

post #61 of 1683
Thread Starter 
Go back 4-5 posts to Graeme's last post. He updated the ArgyllCMS beta files. wink.gif
post #62 of 1683
I tried my very hardest to get results with this with my ST30 using an i1D3 and DCG/Argyll, but I simply could not get results that weren't completely wrong. There would always be, what appeared to be, a misread on the dark patterns, and I'd end up with near-blacks that were whacky colors. I think the problem was that dispcalgui would speed through the testchart as fast as the i1d3 is able to read anything. As many options as Dispcalgui has, I couldn't find any that would slow the meter read time down. I suppose it could have been Ti3parser screwing things up, but I really don't know how I would tell that.

Has anyone else experienced this issue? I remember searching high and low and couldn't seem to find an answer.
post #63 of 1683
Quote:
Originally Posted by gwgill View Post

I've updated http://www.argyllcms.com/Win32_collink_3dlut.zip with the latest fixes for BT.1886 processing. The black point shouldn't be lifted as much when the display black is not neutral, and the gamma curve is now effective gamma by default, making the reproduction much less dependent on the black point being measured or profiled with perfect accuracy. Note that the syntax has changed if you want to alter the default effective gamma, it now looks like "-I b:2.2". The default effective gamma is 2.2, since this is close to what you get with a power of 2.4 and and some sort of black point offset.

I just noticed that the 5/9/2013 [CRC: 66A544A9] binary which I download yesterday from Doom9 had documentation dated 5/8/2013, which you've now updated to 5/10/2013 docs with the same [CRC: 66A544A9] binary. That collink binary still refers to the -Ib -Ix.x syntax in its printed help, and didn't complain when -Ib -Ix.x syntax was used. The 5/9/2013 [CRC: 66A544A9] binary rejects -IB as well.

@gwgill
It seems you may have included the wrong binary in the zip again?

[Edit 5/10/2013 11:59PM PDT: It seems the Win32_collink_3dlut.zip was just updated to remove the \link\ folder, but the \bin\ folder still has outdated collink.exe supporting only the old syntax.]

[Edit 5/11/2013 12:23AM PDT: Win32_collink_3dlut.zip was updated again and now contains the correct version of collink.exe (5/11/2013 CRC: BE98B91A), supporting the new syntax]

Also I'm a bit unclear about these changes. According to the new docs and your description it would seem:

-IB:x.x (new syntax) == -Ib -Ix.x (old syntax) == dispcal -Gx.x -f0 ???

-Ib:x.x (new syntax) == dispcal -gx.x -f0 ???


As for defaults, without gamma override specified:

-IB (new syntax) == -IB:2.4 (new syntax) == -Ib (old syntax) == -Ib -I2.4 (old syntax) ???

-Ib (new syntax) == -Ib:2.2 (new syntax) ???


Is that correct?
Edited by cyberbeing - 5/11/13 at 12:26am
post #64 of 1683
Quote:
14. After the process finishes, do NOT install the profile

I understand from this point, no .icm profile sould be installed on windows during dispcalGUI profiling nor during playing madVR. The profile is only used to generate the 3dLut file and we must asure before starting the process of profiling no other .icm profile is installed in windows

Is that correct?
post #65 of 1683
Quote:
Originally Posted by ttnuagmada View Post

I suppose it could have been Ti3parser screwing things up, but I really don't know how I would tell that.
If you are using "Ti3parser" http://forum.doom9.org/showthread.php?t=162285, then you are on completely the wrong track. This thread is about using the native ArgyllCMS MadVR 3dLut support.
post #66 of 1683
Quote:
Originally Posted by gwgill View Post

If you are using "Ti3parser" http://forum.doom9.org/showthread.php?t=162285, then you are on completely the wrong track. This thread is about using the native ArgyllCMS MadVR 3dLut support.

Well, I was speaking in past tense. Ti3parser was the only way to do it at the time to my knowledge.
post #67 of 1683
Quote:
Originally Posted by N3W813 View Post

I just tested -Ib:2.2 through 2.4 and I'm getting really weird gamma curves. 2.2 target ending up closer to 2.6 avg gamma. I will do more testing and post the readings.
I' not seeing that - in my testing, it was working as expected. But it is normal for the technical gamma to be higher than the effective gamma when making allowance for a the black point matching, but I'd expect a log/log plot to show the curve going right through the effective gamma value at 50%.
Quote:
FYI, the option -IB:g.g is not working.
"Diagnostic: Intent modifier (-I) argument 'B:2.2' not recognized"

Without x.x
"Diagnostic: Intent modifier (-I) argument 'B' not recognized"

Hmm. I'm unable reproduce this problem. The following syntax's work on my copy:

-Ib:2.2
-I b:2.2
-IB:2.2
-I B:2.2

It's possible you are not using the latest version ?
Edited by gwgill - 5/11/13 at 12:06am
post #68 of 1683
See my post above. As of this post, the zip archive on your server still only has binaries supporting the old syntax in the \bin\ folder.
post #69 of 1683
Quote:
Originally Posted by alamagar View Post

Quote:
14. After the process finishes, do NOT install the profile

I understand from this point, no .icm profile sould be installed on windows during dispcalGUI profiling nor during playing madVR. The profile is only used to generate the 3dLut file and we must asure before starting the process of profiling no other .icm profile is installed in windows

Is that correct?
It's up to you. You can choose to install it if you want to. The important thing is to keep track of what is going to use the per channel display calibration curves (.cal file).

They either have to:

1) end up loaded into the Graphics card VideoLUTs with the video being displayed through them and the calibration curves not being part of the 3dlut,

2) or the Graphic card VideoLUTs need to be linear or the Video needs to be displayed not through the them and the calibration curves need to be part of the 3dlut.

To put it another way, if display calibration was created and used for profiling, then the video must end up running though the calibration curves exactly once.
post #70 of 1683
Quote:
Originally Posted by cyberbeing View Post

See my post above. As of this post, the zip archive on your server still only has binaries supporting the old syntax in the \bin\ folder.
Sorry about that, try downloading it agin. [ I'm using a manual built for it, so it's easy to miss something ].
post #71 of 1683
Thanks. As of this post, Win32_collink_3dlut.zip now contains collink.exe dated 5/11/2013 [CRC: BE98B91A] supporting the new syntax.
post #72 of 1683
post #73 of 1683
Quote:
Originally Posted by gwgill View Post

Quote:
Originally Posted by alamagar View Post

Quote:
14. After the process finishes, do NOT install the profile
I understand from this point, no .icm profile sould be installed on windows during dispcalGUI profiling nor during playing madVR. The profile is only used to generate the 3dLut file and we must asure before starting the process of profiling no other .icm profile is installed in windows
Is that correct?

It's up to you. You can choose to install it if you want to. The important thing is to keep track of what is going to use the per channel display calibration curves (.cal file).

They either have to:

1) end up loaded into the Graphics card VideoLUTs with the video being displayed through them and the calibration curves not being part of the 3dlut,

2) or the Graphic card VideoLUTs need to be linear or the Video needs to be displayed not through the them and the calibration curves need to be part of the 3dlut.

To put it another way, if display calibration was created and used for profiling, then the video must end up running though the calibration curves exactly once.

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?
post #74 of 1683
Something is strange with the latest collink build.

@Graeme Gill

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?


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)

__________
[Edit]

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

the above is now also equivalent creating nearly byte-identical 3DLUTs to:

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


Overall, if this is intended behavior, I think it would make more sense if you kept -Ib:x.x as specifying x.x Technical Gamma with automatic black point compensation (Effective Gamma) similar to the 5/9/2013 build, while leaving -IB:x.x as-is specifying x.x Technical Gamma without black point compensation, but maybe I'm misunderstanding something?
__________

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

The behavior I noted above, must have been a bug in the Collink 5/9/2013 [CRC: 66A544A9] build.

_________
Edited by cyberbeing - 5/11/13 at 2:24pm
post #75 of 1683
I have tried with latest collink version. The yellowish tint is gone ...

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)

Viewing a white clipping pattern (flashing steps from 230-240)

**********************************

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

Viewing a white clipping pattern (flashing steps from 230-234)

**********************************

Viewing a color clipping pattern (flashing steps from 219-243) "R, G and B" in both cases. Both patterns are from AVS HD 709 - Blu-ray & MP4 Calibration

**********************************

Before ArgyllCMS Viewing a white clipping pattern (flashing steps from 230-234)
Before ArgyllCMS Viewing a color clipping pattern (flashing steps from 219-233)

SYS
WIN7 x64
ATI HD 4850 (full range)
Latest madVR version (0-255)
TV full range

I really hope you can explain what's going on ...

I would just add that the difference between ArgyllCMS and yCMS is striking. I'm seriously impressed ... both in terms of "what I see" and what I measure in ColorHCFR
Edited by MSL_DK - 5/12/13 at 12:08am
post #76 of 1683
Quote:
Originally Posted by N3W813 View Post


For displays that only allows 16-235 limited range output
  1. Use same options as above but enter below options before starting the calibration/profile
  2. Select Options in the toolbar then Set addtional commandline arguments...
  3. Enter '-E' for dispcal (case sensitive)
  4. Enter '-E' for dispread (case sensitive)
.

Quick question about limited range (16-235) TVs/Monitors.

There are 2 ways of going about setting these up:

Set the GPU drivers to output full range (0-255) and madVR to limited range (16-235)

Set the GPU drivers to limited range (16-235) and madVR to full range (0-255)


I've done the former in my setup (using the madVR tool to force the NVIDIA drivers to full range).

Is there any difference in the setup options for calibration for either of these two scenarios?

Cheers

SBR
post #77 of 1683
Quote:
Originally Posted by Sandy B Ridge View Post

Set the GPU drivers to limited range (16-235) and madVR to full range (0-255)

This setting is not recommended by madshi.
post #78 of 1683
Quote:
Originally Posted by MSL_DK View Post

This setting is not recommended by madshi.

Yes, I believe so.

I assume it is because madVR uses better computation to fit the values in the range 16-235. Also scaling the values up to 0-255 by madVR and then down again to 16-235 by the GPU drivers seems silly and can introduce banding?

This is why I have elected to go with the former:
Set GPU driver to 0-255 and MadVR to 16-235.

Cheers.

SBR
post #79 of 1683
Quote:
Originally Posted by Sandy B Ridge View Post

Also scaling the values up to 0-255 by madVR and then down again to 16-235 by the GPU drivers seems silly and can introduce banding?

That is correct ...
Quote:
Set GPU driver to 0-255 and MadVR to 16-235.

Good idea wink.gif
post #80 of 1683
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)?

Confused...

Ta

SBR
post #81 of 1683
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.

Problem #2: Color temperature issues wherever the 3DLUT lowers gamma

Positive: The 3DLUT does a good job setting the intended luminance for all points of these custom CIECAM02 scaled REC709 gamma curves.


Measurements of my GDM-F520 CRT without 3DLUT & linear VideoLUT:

Native Gamut

Native Color Temp

Native RGB Levels

Native Gamma <- ~2.44 average



Measurements of my GDM-F520 CRT with REC709 CIECAM02 3DLUT & linear VideoLUT:

CIECAM02 3DLUT Gamut <- bad

CIECAM02 3DLUT Color Temp <- very bad

CIECAM02 3DLUT RGB Levels <- very bad

CIECAM02 3DLUT Gamma <- good



Measurements of my GDM-F520 CRT with -Ib:2.4 BT.1886 3DLUT & linear VideoLUT:

-Ib:2.4 BT.1886 3DLUT Gamut <- decent

-Ib:2.4 BT.1886 3DLUT Color Temp <- bad

-Ib:2.4 BT.1886 3DLUT RGB Levels <- bad

-Ib:2.4 BT.1886 3DLUT Gamma <- good


@Graeme Gill

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]
_
Edited by cyberbeing - 5/11/13 at 4:08pm
post #82 of 1683
@cyberbeing, thanks for the tip about using HCFR 3.0.0.0 with the argyll drivers from the 1.5.0/1.5.1 package. My previous calibration using my Colormunki Photo (spectro) and the latest 3.0.4.2 version with it's built in driver package wasn't that far off. (in fact the grayscale measurements were nearly perfect, just had to adjust the cms a tiny bit.) So now when/if I get around to use argyllcms to build a 3dlut for MadVR, hopefully the readings aren't wildly off, since now both HCFR and argyll are using the same exact driver. tongue.gif

Before when I had created a 3dlut just using the profile option, my grayscale de's went through the roof when I compared the results in HCFR.
post #83 of 1683
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
post #84 of 1683
Thread Starter 
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)?

Confused...

Ta

SBR

The patches will be displayed as you windows desktop levels. It is best if you can output 0-255 for desktop and do not use the "-E" parameter for dispcal/dispread.
post #85 of 1683
Thread Starter 
2013-05-11 - ArgyllCMS beta binaries updated. Graeme fixed issue with elevated black point, therefore, Black Point Compensation option is no longer needed in DispcalGUI. (step B10)
post #86 of 1683
Quote:
Originally Posted by N3W813 View Post

2013-05-11 - ArgyllCMS beta binaries updated. Graeme fixed issue with elevated black point, therefore, Black Point Compensation option is no longer needed in DispcalGUI. (step B10)

Can you point out that with the current ArgyllCMS beta update for madVR 3DLUT it is not possible to select "Correction" due to this change
post #87 of 1683
Thread Starter 
Quote:
Originally Posted by MSL_DK View Post

Can you point out that with the current ArgyllCMS beta update for madVR 3DLUT it is not possible to select "Correction" due to this change

I am not sure which 'correction' you are speaking about.
post #88 of 1683
It is ArgyllCMS who have an "error" try to download ArgyllCMS http://www.argyllcms.com/downloadwin.html and look in "Argyll_V1.5.1/doc/instruments.html#i1d3"

When I press the "Start measurement" I get the message "display type is 'n'" and nothing happens.
post #89 of 1683
Thread Starter 
Quote:
Originally Posted by MSL_DK View Post

It is ArgyllCMS who have an "error" try to download ArgyllCMS http://www.argyllcms.com/downloadwin.html and look in "Argyll_V1.5.1/doc/instruments.html#i1d3"

When I press the "Start measurement" I get the message "display type is 'n'" and nothing happens.

Are you applying the latest ArgyllCMS beta update? (download in post #1)
post #90 of 1683
Quote:
Originally Posted by N3W813 View Post

Are you applying the latest ArgyllCMS beta update? (download in post #1)

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?
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Display Calibration
AVS › AVS Forum › Display Devices › Display Calibration › MadVR - ArgyllCMS