i1 profiler vs DisplayCAL. Colorimeter and display calibration software. - Page 2 - AVS Forum | Home Theater Discussions And Reviews
Forum Jump: 
 15Likes
Reply
 
Thread Tools
post #31 of 43 Old 01-11-2020, 07:53 PM
AVS Forum Special Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 1,136
Mentioned: 30 Post(s)
Tagged: 0 Thread(s)
Quoted: 382 Post(s)
Liked: 272
Quote:
Originally Posted by Davide Perini View Post
automatic display calibration uses the monitor's DDC feature, on most monitors can automatically calibrate the screen brightness to the desired one,
on latest monitors it can automatically adjust both brightness and RGB gains.
I think that this feature is a must have, it does in few seconds what I can do manually with 10 mintues and most often it does it a lot better than me.
That's great if you have a large company backing you, and can make deals with all the display manufacturers to tell you about their proprietary communication protocols, and have a budget and team to buy displays and test them all. Too bad if you'd like any sort of choice of which profiling software you use, or would like to see a modicum of competition to push display calibration and profiling forward.
VBB likes this.

Author of ArgyllCMS and ArgyllPRO ColorMeter
gwgill is offline  
Sponsored Links
Advertisement
 
post #32 of 43 Old 01-12-2020, 11:09 PM
AVS Forum Special Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 1,136
Mentioned: 30 Post(s)
Tagged: 0 Thread(s)
Quoted: 382 Post(s)
Liked: 272
So I took a look into X-Rite driver vs. ArgyllCMS driver in emissive mode, and found that under a particular set of circumstances, yes, there is a slight difference between the X-Rite driver measurements and the current ArgyllCMS driver measurements with the i1Pro2 instrument. This amounts to about a 1 delta E difference in the a* value at white (i.e. just visible under worst case circumstances). It turns out to be a result of 3 factors coming together:

1) X-Rites wavelength calibration data in the instrument is inconsistent between the i1Pro1 legacy data, and the i1Pro2 data. This is the underlying source of the 1 delta E difference. I don't know why this difference exists. Best guess would be that they changed their metrology in the i1Pro2 production process, but wanted to any make legacy applications see no differences. As soon as applications upgraded their driver though, there would be a difference.

2) The ArgyllCMS driver has a bug where it doesn't restore calibrated state completely for the i1Pro2 instrument when the -N flag is used. While it restores the wavelength calibration value and all the other calibration values, it fails to recompute the raw CCD to wavelength resampling filters, and instead falls back on the default legacy filters. This bug doesn't crop up if the ArgyllCMS utilities are used normally, where they ask for a calibration before proceeding to do measurements. (If you run the ArgyllCMS driver in i1Pro1 legacy mode, this difference will be visible again.)

3) DisplayCAL makes use of the -N functionality to avoid multiple calibrations when it is stringing different measurements together.

Version 2.1.2 of ArgyllCMS will correct the ArgyllCMS bug, thereby fixing DisplayCAL's usage, and concealing the X-Rite discrepancy.

Note that this has no effect on the relative accuracy of calibration or profiling, just absolute settings such as white point value.
There is no effect on reflective measurements.

Attached is the white spectrum of my display for the X-Rite driver vs. (fixed) ArgyllCMS driver. Yes, there is a red line underneath the black one :-)
Attached Thumbnails
Click image for larger version

Name:	XriteVsArgyllEmis1.jpg
Views:	16
Size:	34.0 KB
ID:	2669090  
stama, Dominic Chan and omarank like this.

Author of ArgyllCMS and ArgyllPRO ColorMeter
gwgill is offline  
post #33 of 43 Old 01-13-2020, 01:50 PM
Member
 
Join Date: Nov 2018
Posts: 38
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 25 Post(s)
Liked: 2
Quote:
Originally Posted by gwgill View Post
That's great if you have a large company backing you, and can make deals with all the display manufacturers to tell you about their proprietary communication protocols, and have a budget and team to buy displays and test them all. Too bad if you'd like any sort of choice of which profiling software you use, or would like to see a modicum of competition to push display calibration and profiling forward.

Quote:
Originally Posted by gwgill View Post
So I took a look into X-Rite driver vs. ArgyllCMS driver in emissive mode, and found that under a particular set of circumstances, yes, there is a slight difference between the X-Rite driver measurements and the current ArgyllCMS driver measurements with the i1Pro2 instrument. This amounts to about a 1 delta E difference in the a* value at white (i.e. just visible under worst case circumstances). It turns out to be a result of 3 factors coming together:

1) X-Rites wavelength calibration data in the instrument is inconsistent between the i1Pro1 legacy data, and the i1Pro2 data. This is the underlying source of the 1 delta E difference. I don't know why this difference exists. Best guess would be that they changed their metrology in the i1Pro2 production process, but wanted to any make legacy applications see no differences. As soon as applications upgraded their driver though, there would be a difference.

2) The ArgyllCMS driver has a bug where it doesn't restore calibrated state completely for the i1Pro2 instrument when the -N flag is used. While it restores the wavelength calibration value and all the other calibration values, it fails to recompute the raw CCD to wavelength resampling filters, and instead falls back on the default legacy filters. This bug doesn't crop up if the ArgyllCMS utilities are used normally, where they ask for a calibration before proceeding to do measurements. (If you run the ArgyllCMS driver in i1Pro1 legacy mode, this difference will be visible again.)

3) DisplayCAL makes use of the -N functionality to avoid multiple calibrations when it is stringing different measurements together.

Version 2.1.2 of ArgyllCMS will correct the ArgyllCMS bug, thereby fixing DisplayCAL's usage, and concealing the X-Rite discrepancy.

Note that this has no effect on the relative accuracy of calibration or profiling, just absolute settings such as white point value.
There is no effect on reflective measurements.

Attached is the white spectrum of my display for the X-Rite driver vs. (fixed) ArgyllCMS driver. Yes, there is a red line underneath the black one :-)

Mr Gill, there is a public SDK for your display from Dell (Win/macos). Current version 2.0.

https://www.dell.com/support/home/us...driverid=jfhnp

It allows you to load and download lut-matrix-lut calibration data to CAL-i slots.
Do you plan to guve some support using ArgyllCMS? At least for native gamut with custom white point and a true neutral grey (which Dell sftware cannot provide in all units if uncalibrated have very bad grey range).
prelut = default 2.2 gamma
matrix = identity
post-lut = reencode 2.2 gamma + multiplication item by item (interpolated if needed to match vector size) with an ArgyllCMS GPU LUT grey & white correction.


It would be cool to have such kind of functionality. HP has that kind of public SDK too for their widegamut series, same 16bit x 1024 lut-matrix-lut.
Vicent is offline  
Sponsored Links
Advertisement
 
post #34 of 43 Old 01-14-2020, 04:51 AM
Member
 
stama's Avatar
 
Join Date: Feb 2013
Posts: 117
Mentioned: 7 Post(s)
Tagged: 0 Thread(s)
Quoted: 106 Post(s)
Liked: 58
Graeme, thanks for looking into this!

I do use the "-N" flag, but I was already using the 2.1.2 beta, as I built it myself from the source code package available on your website. I don't know if it had the "-N" correction or not, though. And I am using spotread for these kind of test measurements.

I see that you posted a new source code package, with changes to how the instrument calibration data is used, I will build this one and try again. Thank you!

Despite the fact that I posted only one measurement, I took several and during different period of times, and always saw the same result. I would have not posted that remark otherwise. I'm too old to fall for drawing conclusions after just one occurrence of some unexpected result.

I also have a couple of fixes for compilation with VisualStudio with recent (well, everything after Vista) Windows sdks. Should I post it here, or what is the better approach for that?

Last edited by stama; 01-14-2020 at 04:59 AM.
stama is offline  
post #35 of 43 Old 01-14-2020, 07:09 PM
AVS Forum Special Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 1,136
Mentioned: 30 Post(s)
Tagged: 0 Thread(s)
Quoted: 382 Post(s)
Liked: 272
Quote:
Originally Posted by Vicent View Post
Mr Gill, there is a public SDK for your display from Dell (Win/macos). Current version 2.0.

https://www.dell.com/support/home/us...driverid=jfhnp

It allows you to load and download lut-matrix-lut calibration data to CAL-i slots.
Well, no it doesn't. (Yes I've taken a look at it). It just allows programmatic control over the same things that the on screen controls.

Yes that could be used to automate some of the manual adjustments, but unfortunately that only helps people with DELL displays. There appears to be no industry wide agreed standard for programmatic display adjustment, and certainly none for uploading display internals such a matrix & lut settings. In addition, various operating system support for DDC communication is primitive (MSWin & OS X) or non-existent (Linux). Often color profiling tool makers are having to implement their own system level and display card specific drivers to get access to DDC. (This is beyond my means. I don't have a couple of years to figure that out and implement it, never-mind maintain it). You may have noticed that the DELL SDK relies on the better supported PCI communications to the display to do its thing.

Bottom line is that a lack of standards that permit inter-operability has a cost in terms of technical progress and user choice. (It's probably not an accident that big companies drag their feet on creating such standards.).

Quote:
It would be cool to have such kind of functionality. HP has that kind of public SDK too for their widegamut series, same 16bit x 1024 lut-matrix-lut.
It's something I'm keeping an eye on, but it's a matter of being able to justify the development effort. Other projects are much more worthwhile to me currently, and automating screen controls is not essential :- it would be nice to be able to upload calibration Luts, but higher bit depth video negates the need for this to some degree, since this allows the existing video Lut hardware to operate at greater depth (as was the case for analog VGA interfaces). Uploading matrices to displays is only useful for narrow industries, where it is desirable for a display to emulate just one colorspace at a time. General color management is better if the display operates at maximum gamut (i.e. unit matrices), and the operating system/application color management converts each source image independently to take full advantage of the display.

Author of ArgyllCMS and ArgyllPRO ColorMeter

Last edited by gwgill; 01-14-2020 at 07:16 PM.
gwgill is offline  
post #36 of 43 Old 01-14-2020, 07:14 PM
AVS Forum Special Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 1,136
Mentioned: 30 Post(s)
Tagged: 0 Thread(s)
Quoted: 382 Post(s)
Liked: 272
Quote:
Originally Posted by stama View Post
I do use the "-N" flag, but I was already using the 2.1.2 beta, as I built it myself from the source code package available on your website. I don't know if it had the "-N" correction or not, though. And I am using spotread for these kind of test measurements.
The release V2.1.2 has an update not in the earlier snapshot.
Quote:

Despite the fact that I posted only one measurement, I took several and during different period of times, and always saw the same result. I would have not posted that remark otherwise. I'm too old to fall for drawing conclusions after just one occurrence of some unexpected result.
Thanks for bringing the problem to my attention.

The discrepancy in the X-Rite calibration data is something I had originally notices when adding support for the i1Pro2, but I assumed that it was as a result of something I was doing wrong. It's good to have verified using X-Rites own driver that it is actually their data that has the discrepancy, and to fix my driver to better conform to what they have done.

Quote:
I also have a couple of fixes for compilation with VisualStudio with recent (well, everything after Vista) Windows sdks. Should I post it here, or what is the better approach for that?
Email me directly. Email address in on the ArgyllCMS website.

Author of ArgyllCMS and ArgyllPRO ColorMeter
gwgill is offline  
post #37 of 43 Old 01-15-2020, 03:03 AM
Member
 
Join Date: Nov 2018
Posts: 38
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 25 Post(s)
Liked: 2
Quote:
Originally Posted by gwgill View Post
Well, no it doesn't. (Yes I've taken a look at it). It just allows programmatic control over the same things that the on screen controls.

Yes that could be used to automate some of the manual adjustments, but unfortunately that only helps people with DELL displays. There appears to be no industry wide agreed standard for programmatic display adjustment, and certainly none for uploading display internals such a matrix & lut settings. In addition, various operating system support for DDC communication is primitive (MSWin & OS X) or non-existent (Linux). Often color profiling tool makers are having to implement their own system level and display card specific drivers to get access to DDC. (This is beyond my means. I don't have a couple of years to figure that out and implement it, never-mind maintain it). You may have noticed that the DELL SDK relies on the better supported PCI communications to the display to do its thing.

Bottom line is that a lack of standards that permit inter-operability has a cost in terms of technical progress and user choice. (It's probably not an accident that big companies drag their feet on creating such standards.).



It's something I'm keeping an eye on, but it's a matter of being able to justify the development effort. Other projects are much more worthwhile to me currently, and automating screen controls is not essential :- it would be nice to be able to upload calibration Luts, but higher bit depth video negates the need for this to some degree, since this allows the existing video Lut hardware to operate at greater depth (as was the case for analog VGA interfaces). Uploading matrices to displays is only useful for narrow industries, where it is desirable for a display to emulate just one colorspace at a time. General color management is better if the display operates at maximum gamut (i.e. unit matrices), and the operating system/application color management converts each source image independently to take full advantage of the display.

Page 25:


SetLUT
Setup the LUT (Look Up Tables) for CAL1 or CAL2.
NOTE: Only works in Color Preset Color Space CAL1 or CAL2.
API
MONITOR_CODE SetLUT(UWORD16 arrPreGamma[3][1025],
UWORD16 arrPostGamma[3][1025],
UWORD16 arrColorMatrix[9])



SetLUT2
Setup the LUT (Look Up Tables) for CAL1 or CAL2.
NOTE: Only works in Color Preset Color Space CAL1 or CAL2.
API
MONITOR_CODE SetLUT2 (UWORD16 arrGammaLen,
UWORD16 *arrPreGamma,
UWORD16 *arrPostGamma,
UWORD16 arrColorMatrix[9])


AFIAK that is exactly what DUCCS HW calibration solution does, compute prelut, matrx and postlut, "pack it" and upload them to monitor. It seems that this SDK allows you to do the packing & uploading, same for HP SDK for Z27x



Sorry, I do not have on eof those displays to test it.



(PS. My fault, I thouhgt that there were some "get LUT data" function to "download" it)
Vicent is offline  
post #38 of 43 Old 01-15-2020, 06:04 PM
AVS Forum Special Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 1,136
Mentioned: 30 Post(s)
Tagged: 0 Thread(s)
Quoted: 382 Post(s)
Liked: 272
Quote:
Originally Posted by gwgill View Post
Well, no it doesn't. (Yes I've taken a look at it). It just allows programmatic control over the same things that the on screen controls.
I take that back. The SDK that Dell pointed me at for my display is SDK V 1.01r2 released in 2015 and didn't include any Lut or Matrix API's. But the version you point to is more recent V2.0.0 released in 2017, and does include API's for loading the Luts and Matrix. Which is good, because it reduces the amount of reverse engineering needed to figure it out...

Author of ArgyllCMS and ArgyllPRO ColorMeter

Last edited by gwgill; 01-15-2020 at 06:12 PM.
gwgill is offline  
post #39 of 43 Old 01-22-2020, 02:22 PM
Member
 
stama's Avatar
 
Join Date: Feb 2013
Posts: 117
Mentioned: 7 Post(s)
Tagged: 0 Thread(s)
Quoted: 106 Post(s)
Liked: 58
@gwgill , I lacked time these days to do new measurements. Just tried a bit argyll yesterday, and I used the -J flag with dispread to force a i1Pro2 calibration before taking measurements. The -J flag seems to request placing the i1Pro2 spectro on the calibration tile twice. Tried it several times, and every time the same happened. Is this as intended?
stama is offline  
post #40 of 43 Old 01-22-2020, 03:38 PM
AVS Forum Special Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 1,136
Mentioned: 30 Post(s)
Tagged: 0 Thread(s)
Quoted: 382 Post(s)
Liked: 272
Quote:
Originally Posted by stama View Post
@gwgill Just tried a bit argyll yesterday, and I used the -J flag with dispread to force a i1Pro2 calibration before taking measurements. The -J flag seems to request placing the i1Pro2 spectro on the calibration tile twice. Tried it several times, and every time the same happened. Is this as intended?
Yes, it's a result of you using the -J flag. -J forces a full set of non deferrable calibration operations, irrespective of whether it has automatically done a calibration. That's why in the usage the comment "used rarely" is there. It's there to trigger non routine types of calibrations that some instruments have. For instance, the DTP92 has two sensitivity levels, and there is a calibration operation to align the two sensitivity levels. It's explained in the documentation.

Author of ArgyllCMS and ArgyllPRO ColorMeter
gwgill is offline  
post #41 of 43 Old 01-22-2020, 04:32 PM
Member
 
stama's Avatar
 
Join Date: Feb 2013
Posts: 117
Mentioned: 7 Post(s)
Tagged: 0 Thread(s)
Quoted: 106 Post(s)
Liked: 58
Ok, thanks for your reply!
stama is offline  
post #42 of 43 Old 01-23-2020, 03:07 AM
Member
 
stama's Avatar
 
Join Date: Feb 2013
Posts: 117
Mentioned: 7 Post(s)
Tagged: 0 Thread(s)
Quoted: 106 Post(s)
Liked: 58
@gwgill , is there a way to ask the argyll tools to perform a recalibration of the i1Pro2 spectro, without using -J? Maybe deleting the .cal file is a way?

My understanding is that -J does more than it needs to do.
stama is offline  
post #43 of 43 Old 01-23-2020, 02:45 PM
AVS Forum Special Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 1,136
Mentioned: 30 Post(s)
Tagged: 0 Thread(s)
Quoted: 382 Post(s)
Liked: 272
Quote:
Originally Posted by stama View Post
@gwgill , is there a way to ask the argyll tools to perform a recalibration of the i1Pro2 spectro, without using -J? Maybe deleting the .cal file is a way?
By default, the i1pro2 gets calibrated every time you use it with an ArgyllCMS tool. The only time it doesn't get a calibration is if you use the -N flag. So I don't understand what you are looking for.

Author of ArgyllCMS and ArgyllPRO ColorMeter
gwgill is offline  
Sponsored Links
Advertisement
 
Reply Display Calibration

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