- This topic has 30 replies, 7 voices, and was last updated 6 years, 9 months ago by
.
-
Posts
-
Does DisplayCAL strip away the currently installed ICC profile before starting the profiling process?
Any currently active calibration is disabled during calibration and profiling.
Thank you, I understand. I suppose it’s not very proper to perform profiling atop another active profile. By the way, when interactive calibration is disabled, and all targets are set to “as measured”, DisplayCAL gives the user the option to use linear curves or not. If the user unchecks the said option, what calibration gets embedded in the ICC profile? Is it copied from the currently installed calibration?
If so, does that mean there is no way I can get the sRGB coverage of “Spectraview-calibrated NEC PA271W + ICC profile”?
If the monitor is hardware-calibrated to sRGB via internal 3D LUT, then SpectraView should install an sRGB profile, so sRGB coverage of that profile would of course be 100% when going purely by numbers.
I checked the monitor, SpectraView II and MultiProfiler’s manuals and it turns out that while there is indeed a 14-bit 3D LUT hardware inside the monitor, SpectraView II (as opposed to the European SpectraView Profiler) only applies 1D correction curves into the hardware LUT. Furthermore, from NEC Display’s SpectraView II’s website:
After calibration, the display is automatically profiled and highly accurate ICC/ColorSync color profiles are generated and automatically registered with the Color Management System. These profiles use the Bradford Chromaticity Adaptation matrix.
So it means that the 3D LUT’s are not being used. Worse, even the correction matrix isn’t stored in the monitor; full color correction still depends on the ICC profile being registered to the operating system. Will check later the contents of the ICC profile generated by SpectraView.
If I indeed see a 3×3 transformation matrix, does it mean that proper evaluation of SpectraView II’s calibration accuracy requires the ICC profile it generated to be loaded, and therefore, I will not be able to assess its sRGB coverage through DisplayCAL’s profiling tool?
Interestingly, NEC’s Multiprofiler sofware is capable of programming the 3D LUT, however, it only accepts printer profiles, which I currently don’t know how (or why) to use.
If I may, for future reference regarding DisplayCAL’s vcgt options while profiling a display calibrated by a different program:
http://www.color.org/groups/medical/displays/controllingVCGT.pdf
If I indeed see a 3×3 transformation matrix, does it mean that proper evaluation of SpectraView II’s calibration accuracy requires the ICC profile it generated to be loaded, and therefore, I will not be able to assess its sRGB coverage through DisplayCAL’s profiling tool?
Both of this can be done. You already checked the sRGB coverage.
If I indeed see a 3×3 transformation matrix, does it mean that proper evaluation of SpectraView II’s calibration accuracy requires the ICC profile it generated to be loaded, and therefore, I will not be able to assess its sRGB coverage through DisplayCAL’s profiling tool?
Both of this can be done. You already checked the sRGB coverage.
How is sRGB coverage calculated in DisplayCAL/ArgyllCMS? Is it dependent solely on the R, G and B primaries (measured during profiling and embedded in the ICC profile)?
I just find it hard to accept that my low-end US$100 monitor could get 99% sRGB coverage when calibrated and profiled using DisplayCAL, while my Spectraview-calibrated NEC PA271W can only emulate 96.3% of sRGB.
If I indeed see a 3×3 transformation matrix, does it mean that proper evaluation of SpectraView II’s calibration accuracy requires the ICC profile it generated to be loaded, and therefore, I will not be able to assess its sRGB coverage through DisplayCAL’s profiling tool?
Both of this can be done. You already checked the sRGB coverage.
I just reflected on this a bit, and realized, I just understood now. Thanks for the explanations.
So, 96.3% sRGB coverage is a bit bad. (And I don’t really want to use the monitor’s Native mode since it results in an oversaturated Windows GUI/desktop)
How is sRGB coverage calculated in DisplayCAL/ArgyllCMS? Is it dependent solely on the R, G and B primaries (measured during profiling and embedded in the ICC profile)?
No, it’s true 3D volume (in L*a*b* space) calculated from the profile (which in turn is based on the measured points).
I just find it hard to accept that my low-end US$100 monitor could get 99% sRGB coverage when calibrated and profiled using DisplayCAL, while my Spectraview-calibrated NEC PA271W can only emulate 96.3% of sRGB.
The low-end monitor likely has a gamut that is slightly larger than sRGB. If you would profile the NEC PA271W in native gamut mode, the coverage would likely rise. 96.3% is not a bad figure though and not worth the concern imo.
Dear Florian,
can’t get a “report on uncalibrated display” with version 3.3.
3 patches appear, 17 grey patches appear, when doing raw measurements ->> displaycal loops.
09:22:23,128 Unkalibriertes Anzeigegerät messen (Kurzreport)
09:22:24,019 ——————————————————————————–
09:22:24,020 Befehlszeile:
09:22:24,020 dispcal.exe
09:22:24,023 -v2
09:22:24,023 -d1
09:22:24,025 -c1
09:22:24,025 -ye
09:22:24,026 “-P0.5,0.5,1.49865229111”
09:22:24,026 -Ib
09:22:24,028 -R
09:22:24,028
09:22:24,549 DisplayCAL: Starting interaction with subprocess
09:22:24,552 Setting up the instrument
09:22:26,644 Instrument Type: Datacolor Spyder4
09:22:26,645 Serial Number: 03115157
09:22:26,647 Hardware version: 0x070f
09:22:26,926 Place instrument on test window.
09:22:26,927 DisplayCAL: Waiting for send buffer
09:22:28,430 DisplayCAL: Skipping place instrument on screen message…
09:22:28,440 DisplayCAL: Sending buffer: ‘ ‘
09:22:28,447 Hit Esc or Q to give up, any other key to continue:
09:23:14,098 Patch 3 of 3
09:23:14,098
09:24:01,170 Patch 17 of 17
09:24:01,171
09:24:01,171 raw measurements:
09:56:36,539 DisplayCAL: Pausing…
09:56:40,661 DisplayCAL: Trying to end subprocess gracefully…
09:57:00,681 DisplayCAL: Trying to terminate subprocess…
09:57:00,782 …subprocess terminated.
09:57:00,786 DisplayCAL: Reached EOF (OK)
09:57:00,786 …abgebrochen.regards – tg
3 patches appear, 17 grey patches appear, when doing raw measurements ->> displaycal loops.
Which version of Argyll CMS are you using? Try the devel snapshot (sticky topic in this forum).
using argyll 1.9.4. beta
Have you tried using stable 1.9.2 instead?
b t w: the 17 patches measured looked for me identical (medium gray)
Yes, it’s trying to determine the videoLUT bit depth. This can take a long time, especially when the instrument is struggling (and the nature of this test challenges the instrument precision and repeatability).
no problems when pointing to argyll 1.9.2 directory.
result:
16:34:18,181 Unkalibriertes Anzeigegerät messen (Kurzreport)
16:34:19,009 ——————————————————————————–
16:34:19,009 Befehlszeile:
16:34:19,009 dispcal.exe
16:34:19,012 -v2
16:34:19,012 -d1
16:34:19,013 -c1
16:34:19,013 -ye
16:34:19,013 “-P0.5,0.5,1.49865229111”
16:34:19,015 -Ib
16:34:19,016 -R
16:34:19,016
16:34:19,427 DisplayCAL: Starting interaction with subprocess
16:34:19,433 Setting up the instrument
16:34:21,517 Instrument Type: Datacolor Spyder4
16:34:21,517 Serial Number: 03115157
16:34:21,519 Hardware version: 0x070f
16:34:21,798 Place instrument on test window.
16:34:21,805 DisplayCAL: Waiting for send buffer
16:34:23,305 DisplayCAL: Skipping place instrument on screen message…
16:34:23,322 DisplayCAL: Sending buffer: ‘ ‘
16:34:23,331 Hit Esc or Q to give up, any other key to continue:
16:35:07,723 Patch 3 of 3
16:35:07,723
16:35:51,709 Patch 17 of 17
16:35:51,710
16:35:51,710 Uncalibrated response:
16:35:51,711 Black level = 0.2402 cd/m^2
16:35:51,713 50% level = 27.90 cd/m^2
16:35:51,714 White level = 124.90 cd/m^2
16:35:51,716 Aprox. gamma = 2.16
16:35:51,717 Contrast ratio = 520:1
16:35:51,717 White chromaticity coordinates 0.3142, 0.3315
16:35:51,719 White Correlated Color Temperature = 6407K, DE 2K to locus = 5.3
16:35:51,726 White Correlated Daylight Temperature = 6409K, DE 2K to locus = 0.8
16:35:51,726 White Visual Color Temperature = 6224K, DE 2K to locus = 5.1
16:35:51,726 White Visual Daylight Temperature = 6384K, DE 2K to locus = 0.8
16:35:51,726 Effective Video LUT entry depth seems to be 8 bits
16:35:51,726 Black drift was -1.#IND00 DE
16:35:51,727 The instrument can be removed from the screen.
16:35:51,834 DisplayCAL: Reached EOF (OK)How is sRGB coverage calculated in DisplayCAL/ArgyllCMS? Is it dependent solely on the R, G and B primaries (measured during profiling and embedded in the ICC profile)?
No, it’s true 3D volume (in L*a*b* space) calculated from the profile (which in turn is based on the measured points).
I just find it hard to accept that my low-end US$100 monitor could get 99% sRGB coverage when calibrated and profiled using DisplayCAL, while my Spectraview-calibrated NEC PA271W can only emulate 96.3% of sRGB.
The low-end monitor likely has a gamut that is slightly larger than sRGB. If you would profile the NEC PA271W in native gamut mode, the coverage would likely rise. 96.3% is not a bad figure though and not worth the concern imo.
Yes, you are right, checking the low-end monitor’s ICC profile shows well-tuned primaries lying just a bit beyond the sRGB region.
I’ve tried profiling the PA271W in its native mode before, which resulted in 99.9% sRGB and 97.1% AdobeRGB coverage, as promised in its specs. But I just don’t want to use the native mode since the Windows desktop/GUI isn’t color-managed.
Anyway, it appears that SpectraView allows the target primaries to be customized. Will just nudge them a little bit and see how it goes. Thanks!
Hi.
Is there a workaround for creating reports on display w. latest Argyll-snapshot?
I switched over to 1.9.4 because the calibration results are pretty good.
replaced spyder express v. 4 by v. 5; spyder 4 measurements were inconsistent. i feared my monitor has changed colors heavily within a few months – but sensor has getting old.
If I indeed see a 3×3 transformation matrix, does it mean that proper evaluation of SpectraView II’s calibration accuracy requires the ICC profile it generated to be loaded, and therefore, I will not be able to assess its sRGB coverage through DisplayCAL’s profiling tool?
Both of this can be done. You already checked the sRGB coverage.
How is sRGB coverage calculated in DisplayCAL/ArgyllCMS? Is it dependent solely on the R, G and B primaries (measured during profiling and embedded in the ICC profile)?
I just find it hard to accept that my low-end US$100 monitor could get 99% sRGB coverage when calibrated and profiled using DisplayCAL, while my Spectraview-calibrated NEC PA271W can only emulate 96.3% of sRGB.
The reason why the coverage is only 96.3% is that Spectraview does not calibrate the primaries. Instead, one can either choose to use a) factory measurements (true sRGB primaries in ICC profile, but the monitor’s have actually drifted already over time) or b) calibration sensor measurements (primaries not exact, but at least reflected faithfully in ICC profile).
Source: https://www.dpreview.com/forums/thread/3024764
