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

eeColor processor - ArgyllCMS - Page 3

post #61 of 170
Quote:
Originally Posted by <^..^>Smokey Joe View Post

Graeme, looks interesting.

I have the D model i1pro, once I clear the decks of crud i'Il get to task trying to work out how to use your drivers.
btw I found your 64x exe still has a hissy fit, both with MSE and nod32 from my work security system.

I'm afraid bugs in MS software are out of my control. The fact that a .zip seems to crash MSE is probably a big security hole - a crash usually means there is a means of triggering arbitrary code execution, and hijacking MSE would be a plumb prize....
Quote:

I could download the 32 bit stuff though, will this still run on a win7 64x rig?
I think it should work, but you need the 64 bit libusb0-win32.sys driver installed.
Quote:

I think those errors would grow towards low detection where noise ratio gets to high.
I was planning on repeating what you have there , but add 10% luminance step ramps for each aswell.The 10 readings per each point is probably enough, although that might depend on display.
By all means. I have to move on to other things, but I would not expect the noise performance between normal and hi-res to be distinguishable from the CIE values.
post #62 of 170
Quote:
Originally Posted by zoyd View Post

The question was not about the absolute accuracy of either device, it was can you improve the relative accuracy of the i1pro against a higher resolution spectrograph using 3.3 nm sampled spectra. The answer is a convincing yes, although the improvement is small and may not hold under all measurement conditions, particularly if the display spectral gradients line up with bumps in the undersampled 10nm calibration caused by the grating.

It is what I expected as a conclusion, however in this case display noise is still part of the sample data. With enough sample data you can remove a reasonble confidence level of noise. Might need 100~1000 per sample though.
I'm running an experiment at the moment where I'm removing environmental noise from data, taken 63000 data points per point and roughly 1.5million total points to just create a calculation.
Removing the noise raises the confendence level, one way or another.

Even though the display for the first test was CCFL, using a flourescent light fitting which has very narrow peaks could show limits coming into play better. I'm waiting for our head technician to come back from a trip, as he might know if we have a monochromatic light source floating about. Universities are hoarders of useful stuff, used once then gets locked away in closets.
post #63 of 170
Quote:
Originally Posted by <^..^>Smokey Joe View Post

I'm running an experiment at the moment where I'm removing environmental noise from data, taken 63000 data points per point and roughly 1.5million total points to just create a calculation.
Removing the noise raises the confendence level, one way or another.

Unless the source is very stable, I'm not sure it will prove anything. Even though I had the displays I used sitting there for a long time in the same conditions, longer term changes in the display output threatened to equal or exceed what I was trying to measure, unless I made all the measurements quite close together. A conventional fluerescent lamp fixture output is quite variable with power supply, and particularly temperature.
post #64 of 170
Thread Starter 
Tried a couple more runs and have settled on a 2500 OFPS patch set which includes 50 neutral patches. I also compared the performance of the internal CMS to the final LUTed performance. The 2500 patch set gives a very symmetric residual error centered near 0.5 dE (blue filled area below) and also cleaned up a few outliers compared to the 1500 OFPS result, but visually the two are identical. The plots below show both the improvement relative to a "bad" display (native color) and one in which the internal CMS is very good (the samsung CMS is top notch for a 6 point LUT).








Edited by zoyd - 4/14/13 at 8:10am
post #65 of 170
I've created a first cut of MadVR .3dlut support using ArgyllCMS tools.

I've packaged up a Win32 bit version of collink, together with other resources such as source profiles (Rec709, EBU3213, SMPTE_RP145) and updated documentation for collink and expanded the guide information at the bottom of Scenarios.html. It is still a bit sketchy, and certainly hasn't been fully tested yet.

http://www.argyllcms.com/Win32_collink_3dlut.zip

I'm a bit suspicious that MadVR may not work very well, as it seems to have taken on a lot of the color management tasks internally (YCbCr conversions, VIdeo to PC RGB conversion), and the change log hint that there is some attempt at automatic PAL/NTSC/Rec709 switching, and if this is done in front of the 3DLut, it will wreck proper color management using display profiles.

Corrections, suggestions, experiences and feedback welcome.
post #66 of 170
On further reflection, probably "dispread -k TV.cal" rather than dispread -K TV.cal" should be used when measuring the display, if a calibration file is being used. A similar consideration applies when actually playing the video via the PC :- if the calibration curves are incorporated in the 3dLut and the video playback is affected by the Graphic Card VideoLUTs, then linear VideoLuts would need to be loaded (ie. dispwin -c). Alternatively, the calibration curves could be omitted from the 3Dlut by removing the "-a TV.cal" parameter from the collink command line, and instead installing as the VideoLut curves using "dispwin TV.icm".
post #67 of 170
I now suspect that I have wasted my time adding MadVR support, although it is hard to be 100% sure, since there seems no definitive information on how the current version actually works and how it uses 3DLuts - information seems to scattered across thousands of posts to the Doom9 forums. This post in particular http://forum.doom9.org/showthread.php?p=1510462#post1510462 seems to indicate that MadVR has now twisted the 3DLut from a device link doing video encoding color space to output display colorspace conversion (as it seemed to do in early releases), into a pseudo-device profile, taking some "standardized" RGB display space and then doing very little with it. It appears that it is assuming that the display device behavior is completely captured by the primary locations and response curves, and that color management begins and ends at relative colorimetric gamut clipping. :-( :-( :-(
post #68 of 170
Quote:
Originally Posted by gwgill View Post

On further reflection, probably "dispread -k TV.cal" rather than dispread -K TV.cal" should be used when measuring the display, if a calibration file is being used. A similar consideration applies when actually playing the video via the PC :- if the calibration curves are incorporated in the 3dLut and the video playback is affected by the Graphic Card VideoLUTs, then linear VideoLuts would need to be loaded (ie. dispwin -c). Alternatively, the calibration curves could be omitted from the 3Dlut by removing the "-a TV.cal" parameter from the collink command line, and instead installing as the VideoLut curves using "dispwin TV.icm".

Graeme,
Thanks for you work on this. smile.gif

When using MadVR's calibration settings, there is an option to enable/disable 'GPU gamma ramps'.

post #69 of 170
Quote:
Originally Posted by gwgill View Post

I now suspect that I have wasted my time adding MadVR support, although it is hard to be 100% sure, since there seems no definitive information on how the current version actually works and how it uses 3DLuts - information seems to scattered across thousands of posts to the Doom9 forums. This post in particular http://forum.doom9.org/showthread.php?p=1510462#post1510462 seems to indicate that MadVR has now twisted the 3DLut from a device link doing video encoding color space to output display colorspace conversion (as it seemed to do in early releases), into a pseudo-device profile, taking some "standardized" RGB display space and then doing very little with it. It appears that it is assuming that the display device behavior is completely captured by the primary locations and response curves, and that color management begins and ends at relative colorimetric gamut clipping. :-( :-( :-(

Say what?? In layman terms please? tongue.gif

I will try a calibration on my laptop later today and post back the charts/results.

In my past tests with ArgyllCMS/Ti3parser, after incorporating the 3dlut in MadVR, points within the gamut were adjusted closer to their targets in terms of xy, but Y values were way off.
post #70 of 170
Quote:
Originally Posted by N3W813 View Post


Say what?? In layman terms please? tongue.gif

That is layman's terms :-)

OK, as a summary rather than an explanation: It seems like the latest version of MadVR takes on so much of the color management, that there is no scope for ArgyllCMS to provide any input. If your display is perfectly additive (ie. can be perfectly characterized by the primaries + white + response curves), then this is probably OK. If your display lives more in the real world, this may not be the best that can be done.
Quote:

I will try a calibration on my laptop later today and post back the charts/results.

In my past tests with ArgyllCMS/Ti3parser, after incorporating the 3dlut in MadVR, points within the gamut were adjusted closer to their targets in terms of xy, but Y values were way off.

TI3parser (the program, not the whole suite of tools) is really an abomination - parsing the .ti3 file to extract the rudimentary display characteristics, when the whole point of the .ti3 file is to create an ICC device profile that represents the display characteristics. ie. the correct approach is to make a profile using ArgyllCMS, and then use the profile for what it is intended!

I suspect that collink may be useable with MadVR V0.61:

http://forum.doom9.org/showthread.php?p=1402013#post1402013

collink -v -3 m -e 7 -E n -I b -G -i r -a TV.cal Rec709.icm TV.icm "hd - pc.icm"
collink -v -3 m -e 7 -E t -I b -G -i r -a TV.cal Rec709.icm TV.icm "hd - video.icm"
collink -v -3 m -e 6 -E n -I b -G -i r -a TV.cal EBU3213_PAL.icm TV.icm "sd - pc.icm"
collink -v -3 m -e 6 -E t -I b -G -i r -a TV.cal EBU3213_PAL.icm TV.icm "sd - video.icm"

Substitute SMPTE_RP145_NTSC.icm for EBU3213_PAL.icm if you are in an NTSC region. (The -3 m flag creates .3dluts as well as the Device Link.)
post #71 of 170
Quote:
Originally Posted by N3W813 View Post


When using MadVR's calibration settings, there is an option to enable/disable 'GPU gamma ramps'.

Sorry, I really don't know if "GPU gamma ramps" is anything to do with the video card VideoLUTs or not. If there was an explaination or help file detailing what this is it would help. Failing that, you are left with experimentation, or asking on the Doom9 forums.
post #72 of 170
Quote:
Originally Posted by gwgill View Post

Sorry, I really don't know if "GPU gamma ramps" is anything to do with the video card VideoLUTs or not. If there was an explaination or help file detailing what this is it would help. Failing that, you are left with experimentation, or asking on the Doom9 forums.

Yes, the "GPU gamma ramps" option is supposed to enable/disable the video card VideoLUTs. Regardless, I will take measurements with/without the setting for comparison.smile.gif
post #73 of 170
Quote:
Originally Posted by gwgill View Post

That is layman's terms :-)

OK, as a summary rather than an explanation: It seems like the latest version of MadVR takes on so much of the color management, that there is no scope for ArgyllCMS to provide any input. If your display is perfectly additive (ie. can be perfectly characterized by the primaries + white + response curves), then this is probably OK. If your display lives more in the real world, this may not be the best that can be done.
TI3parser (the program, not the whole suite of tools) is really an abomination - parsing the .ti3 file to extract the rudimentary display characteristics, when the whole point of the .ti3 file is to create an ICC device profile that represents the display characteristics. ie. the correct approach is to make a profile using ArgyllCMS, and then use the profile for what it is intended!

I suspect that collink may be useable with MadVR V0.61:

http://forum.doom9.org/showthread.php?p=1402013#post1402013

collink -v -3 m -e 7 -E n -I b -G -i r -a TV.cal Rec709.icm TV.icm "hd - pc.icm"
collink -v -3 m -e 7 -E t -I b -G -i r -a TV.cal Rec709.icm TV.icm "hd - video.icm"
collink -v -3 m -e 6 -E n -I b -G -i r -a TV.cal EBU3213_PAL.icm TV.icm "sd - pc.icm"
collink -v -3 m -e 6 -E t -I b -G -i r -a TV.cal EBU3213_PAL.icm TV.icm "sd - video.icm"

Substitute SMPTE_RP145_NTSC.icm for EBU3213_PAL.icm if you are in an NTSC region. (The -3 m flag creates .3dluts as well as the Device Link.)

Graeme,
I tried loading the 3dlut created by the collink you posted but I am getting a "This 3DLUT file does not match the input format required by MadVR".

Command I used:
collink -v -3 m -e 7 -E n -I b -G -i r -a TV.cal Rec709.icm TV.icm "hd - pc.icm" (TV.cal and TV.icm were created from a profile/calibration done in DispcalGUI using ArcgyllCMS 1.5.1)

Madshi explains how the 3dlut file should be formatted for 0.66+
http://forum.doom9.org/showpost.php?p=1510363&postcount=637
post #74 of 170
Quote:
Originally Posted by N3W813 View Post


I tried loading the 3dlut created by the collink you posted but I am getting a "This 3DLUT file does not match the input format required by MadVR".

Madshi explains how the 3dlut file should be formatted for 0.66+
http://forum.doom9.org/showpost.php?p=1510363&postcount=637

No surprise there - as I said in the previous post, there seems little point in trying to provide 3DLuts to MadVR 0.66+ if it works as various posts indicate - the suggestions I made are for MadVR 0.61, where a 3DLut may do some good.

The ArgyllCMS 3DLuts can be made to use RGB video input encoding using -et, but they won't contain "Input_Primaries", since such information should not be necessary or relevant if the Device Link/3DLut is being used for its purpose of transforming from one device space to another.
post #75 of 170
Quote:
Originally Posted by gwgill View Post

No surprise there - as I said in the previous post, there seems little point in trying to provide 3DLuts to MadVR 0.66+ if it works as various posts indicate - the suggestions I made are for MadVR 0.61, where a 3DLut may do some good.

The ArgyllCMS 3DLuts can be made to use RGB video input encoding using -et, but they won't contain "Input_Primaries", since such information should not be necessary or relevant if the Device Link/3DLut is being used for its purpose of transforming from one device space to another.

I've tried the generated 3dlut in version 0.61 of MadVR also, but it crashes MadVR as soon as I try to load the file. frown.gif

I think Madshi have posted at his Doom9 thread stating that he wants to implement a better CMS correction system with 3DLUT support in MadVR but not sure where that falls in his timeline. One can only hope it is soon. biggrin.gif

Oh well, thank you for your work anyway. smile.gif If you ever need someone to beta test for you, I'm 100% willing. wink.gif
post #76 of 170
Quote:
Originally Posted by N3W813 View Post


I've tried the generated 3dlut in version 0.61 of MadVR also, but it crashes MadVR as soon as I try to load the file. frown.gif

I tried using MadVR 0.61 in MPC_HC 1.6.7.7114, and it plays the main menu, and then MPC_HC stops responding. I guess it is not compatible with MadVR 0.61 anymore.

I loaded up a .3dlut I generated, and it is definitely working, because (per instructions) I created it with YCbCR encoded input, but it seems the channel order is not correct, or that it is not actually using YCbCr - certainly the MadVR .3dLut isn't marked as YCbCr input. It will take some effort to figure out what MadVR is actually expecting, and to make sure I haven't got a bug somewhere.
Quote:

I think Madshi have posted at his Doom9 thread stating that he wants to implement a better CMS correction system with 3DLUT support in MadVR but not sure where that falls in his timeline. One can only hope it is soon. biggrin.gif

It's pretty simple :- use ICC profiles. See http://voxelium.wordpress.com/2010/09/20/icc-color-management-in-media-player-classic-home-cinema/,
ie. MPC-HC is taking the right approach. For higher quality color, allow selection of an ICC device link for each type of media source (which then encompasses the whole linking process, and allows higher quality cLUT inversion + lots of other options using ArgyllCMS collink).
post #77 of 170
Quote:
Originally Posted by gwgill View Post


ie. MPC-HC is taking the right approach. For higher quality color, allow selection of an ICC device link for each type of media source (which then encompasses the whole linking process, and allows higher quality cLUT inversion + lots of other options using ArgyllCMS collink).

I can't believe I didn't know MPC-HC can link ICC profiles! eek.gif I tried a calibration this past weekend on my laptop and had excellent results. Although the ICC profile couldn't 'move' the 100% saturation points, all 25% saturation sweep points within the gamut had lower than 1 dE.

It's really too bad MadVR does not offer ICC linking for color correction. frown.gif I think I'll go post in the MadVR thread at Doom9 and see if this something Madshi can incorporate easily.

EDIT: Nevermind, looks like you are already engaging Madshi regarding 3dlut creation for MadVR in the Doom9 thread. biggrin.gif I'm sure you guys can figure this thing out!!!
Edited by N3W813 - 4/29/13 at 1:55pm
post #78 of 170
I'll give linking MPC-HC to an ICC profile a shot this weekend. I tried creating a 3DLUT for MadVR a while back and got similarly unacceptable results unfortunately. Thanks for the info guys.
post #79 of 170
Quote:
Originally Posted by N3W813 View Post


I can't believe I didn't know MPC-HC can link ICC profiles! eek.gif I tried a calibration this past weekend on my laptop and had excellent results. Although the ICC profile couldn't 'move' the 100% saturation points, all 25% saturation sweep points within the gamut had lower than 1 dE.

One caveat with the MPC-HC ICC profile use, is that it seems that the render that supports it, isn't rendering through the graphics card VideoLUT. Typically all profiling packages assumes that VideoLUT calibration (stored in the 'vcgt' tag in the display profile) will be used and is loaded into the graphics card. You can work around this, but it makes it somewhat messy and inconvenient if you normally run with a VideoLUT calibrated screen for the benefits of non-color managed applications.
post #80 of 170
Quote:
Originally Posted by gwgill View Post

One caveat with the MPC-HC ICC profile use, is that it seems that the render that supports it, isn't rendering through the graphics card VideoLUT. Typically all profiling packages assumes that VideoLUT calibration (stored in the 'vcgt' tag in the display profile) will be used and is loaded into the graphics card. You can work around this, but it makes it somewhat messy and inconvenient if you normally run with a VideoLUT calibrated screen for the benefits of non-color managed applications.

Not too big of a deal, I can perform grayscale and gamma calibration adjustments on all my displays (TVs) prior to a profile/calibration in ArgyllCMS for an ICC profile.
post #81 of 170
It turns out I was being too pessimistic about MadVR V 0.861, and after a lot of testing, tweaking and fixing bugs, the visual results seem quite promising.
To try it for yourself you need ArgyllCMS V1.5.2 from here http://www.argyllcms.com/downloadwin.html and then this set of extra & replacement files from here http://www.argyllcms.com/Win32_collink_3dlut.zip installed over the top of it, plus a color instrument and some patience.
The main guide is at the bottom of doc/Scenarios.html, & updated documentation for collink in doc/collink.html. Video colorspace profiles are in ref.

A lot of the fixes and changes apply to the eeColor 3DLut as well - it would be well worth re-creating any 3Dluts with the latest version of collink.
post #82 of 170
Thanks for adding this to MadVR. I will eventually try to figure this out and create a 3dlut for use with MadVR once I get some time. Hopefully the process involved is not too daunting a task for me. (never done anything calibration wise without a GUI) smile.gif
post #83 of 170
Thread Starter 
Quote:
Originally Posted by gwgill View Post

It turns out I was being too pessimistic about MadVR V 0.861, and after a lot of testing, tweaking and fixing bugs, the visual results seem quite promising.
To try it for yourself you need ArgyllCMS V1.5.2 from here http://www.argyllcms.com/downloadwin.html and then this set of extra & replacement files from here http://www.argyllcms.com/Win32_collink_3dlut.zip installed over the top of it, plus a color instrument and some patience.
The main guide is at the bottom of doc/Scenarios.html, & updated documentation for collink in doc/collink.html. Video colorspace profiles are in ref.

A lot of the fixes and changes apply to the eeColor 3DLut as well - it would be well worth re-creating any 3Dluts with the latest version of collink.

good news, thanks for sorting that out. The zip files for windows 32 and 64 bit still say 1.5.1 at that link, is there a 1.5.2 we should use?
post #84 of 170
Got good results from an initial test on my laptop display. Before and after 25% saturation sweeps below. Will try this on my Sharp Elite tonight. smile.gif



post #85 of 170
Quote:
Originally Posted by fairchild99 View Post

Thanks for adding this to MadVR. I will eventually try to figure this out and create a 3dlut for use with MadVR once I get some time. Hopefully the process involved is not too daunting a task for me. (never done anything calibration wise without a GUI) smile.gif
You can probably use DispcalGUI to create the display profile, since nothings changed about that, and just have to switch to the command line for the 3dLUT creation.

[BTW. I meant that you have to start with ArgyllCMS V1.5.1 of course - 1.5.2 is the beta code version.]
post #86 of 170
Preliminary results from a Sharp Elite with 3dlut... smile.gif Checks with my reference bluray scenes look fantastic! biggrin.gif

Before


After


This weekend, I will attempt to improve the overall quality by recalibrating the TV with different targets first and then applying a newly generated 3dlut.

*The 3DLUT was able to fix the cyan issue apparent in the Sharp Elites
post #87 of 170
Quote:
Originally Posted by gwgill View Post

You can probably use DispcalGUI to create the display profile, since nothings changed about that, and just have to switch to the command line for the 3dLUT creation.

[BTW. I meant that you have to start with ArgyllCMS V1.5.1 of course - 1.5.2 is the beta code version.]

I followed some instructions from another user on another forum, but I still either did the wrong thing or am missing something. I'll copy and paste and maybe someone can assist.

Ok after performing a calibration (which failed at the end and said profile not complete) using this guide, I am left with a bunch of files in a newly created directory in my dispcal folder: (followed up to here: Set dispcalGUI to video, profile type XYZ LUT + matrix. Click the advanced button to set gamut mapping options: check both boxes; select an Rec. 709 profile; set the intents to absolute colorimetric. Click on the Calibrate & Profile button. When finished install the ICM profile. Check that it is loaded as the default profile for your display in the color management control panel.)

Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX

But again, I am missing some files or am not understanding how I now create the actual 3dlut. Per the Scenarios.html readme, it says to use the following:

collink -v -3 m -e t -E t -I b -I 2.2 -G -i r Rec709.icm TV.icm HD.icm

I can copy and paste the Red709.icm easy enough to the directory where collink.exe is located, but I can't find TV.icm or HD.icm and I don't understand where all the files I just created after an hour long calibration/profile with dispcal factor in.

I have the following in the Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX folder:

Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX.all.cmd
Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX.cal
Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX.dispcal.cmd
Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX.dispread.cmd
Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX.ti1
Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX.ti3

Someone halp, if this should go to PM's then please advise.
post #88 of 170
post #89 of 170
Thanks Graeme, I attempted to follow your steps but I've continued to run into a brick wall. confused.gif
post #90 of 170
Zoyd, I hope you don't mind, but I've created a new thread dedicated to MadVR - ArgyllCMS since this thread is for the eecolor processor. smile.gif

http://www.avsforum.com/t/1471169/madvr-argyllcms
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Display Calibration
AVS › AVS Forum › Display Devices › Display Calibration › eeColor processor - ArgyllCMS