- This topic has 10 replies, 5 voices, and was last updated 3 years, 11 months ago by
.
-
Posts
-
Thank you for your response.
It is proposed that V4 offers these benefits over V2:
“Benefits that users will see with v4 are:”
“More consistent and accurate colorimetric intent transforms resulting from a fully-defined media white point and more consistent handling of black points
More consistent and higher quality perceptual intent transforms because there is now a fully-defined perceptual reference medium dynamic range and gamut
Smaller and more accurate profiles that make use of new efficient transform structures
Generally improved consistency between different profiles and CMMs as a result of improvements to the specification throughout
Better support for re-purposing and proofing of images rendered with the perceptual and colorimetric intents through more accurate inverse transforms.”Among many others…
Are these not valuable improvements?
Thanks.
More consistent and accurate colorimetric intent transforms resulting from a fully-defined media white point and more consistent handling of black points
How the media white point tag for display profiles should be encoded and handled in ICCv4 has changed from ICCv2, but there are different views on whether or not this was a good change. “More consistent handling of black points” is a vacuous statement – all the ICC have done here is remove the (somewhat superfluous) “bkpt” tag from the specification, and made clear that it shouldn’t be used for actual color transforms (which to my knowledge it never was anyway, this tag was basically only handled as metadata in ICCv2 as well, so nothing has really changed).
More consistent and higher quality perceptual intent transforms because there is now a fully-defined perceptual reference medium dynamic range and gamut
A good read are Graeme’s comments on ICCv4 and the PRMG (perceptual reference medium gamut). Also, while the PRMG specification does aid the claimed consistency somewhat, it does nothing to provide “higher quality perceptual intent transforms” because that is purely down to the respective profiler.
Smaller and more accurate profiles that make use of new efficient transform structures
Smaller, yes, but we are talking a mere few kilobytes here and there (at most, if even that!), and only as far as generic curves + matrix profiles are concerned (several well-defined curves like sRGB or L* can be expressed as a formula in ICCv4). More accurate? If you compare such a formula-based TRC to the ICCv2 16-bit encoded values based TRC, and transform input values through them, you may be able to make out miniscule differences in the transformed numbers but ultimately they don’t translate to anything even close to visually meaningful. It is useful for inversion, though, because the formulas can be inverted without introducing round-trip errors, while the encoded 16-bit values based TRCs cannot. But again, this is more of an academic improvement.
Generally improved consistency between different profiles and CMMs as a result of improvements to the specification throughout
The clearer specification may have made things easier for people implementing CMMs.
Better support for re-purposing and proofing of images rendered with the perceptual and colorimetric intents through more accurate inverse transforms.”
This isn’t specific to ICCv4 but purely dependent on the software that creates the profiles, i.e. the way profilers implement said transforms, which is in fact not part of the specification.
Are these not valuable improvements?
What they don’t tell you is that those can (and do) exist with ICCv2 as well, because they are purely implementation-specific (Argyll had most of those “improvements” from the very beginning). E.g. it is not a coincidence that profiling software that can create v4 profiles can often also optionally create v2, and in the instances I’ve looked at, the only meaningful difference between the profiles was the ICC version encoded in the profile header…
The real benefits of ICCv4 (imo) come into play (e.g.) when you need complex transform structures (e.g. a chain combination of several LUTs, matrices, and shaper curves in a single processing element), or through true floating-point encoding available for most processing elements (which again is a rather academic improvement, but if you need perfect round-tripping when inverting transforms it is useful, or for things like encoding log values, where quantization errors in ICCv2 would be unacceptable due the 16-bit encoding precision limit).
Thank you for explaining this Florian… I guess you’re right, there is no real benefit to using v4 .icc except in very specific cases, and even then the changes don’t appear to amount for much.
Count me in in thanking for good explanation. Before this I only found information on argyllcms website and I myself experienced numerous compatibility problems with V4 display profiles.
In the end this is another case that supports paying attention on the facts and factual explanations, not what is “marketing friendly” said or stated.
Hi Florian, I know that what you are saying here (essentially no real befefits to v.4, but compatability problems) is what just about every competent colour management expert on the internet is saying as well. Yet, my personal experience has been that for some reason I seem to be getting much closer to the intended D65 white point with v. 4 than v.2. (with Dell Color Calibration Solution and Palette Master Element for hardware calibration of a Dell U2713H and a BenQ SW271 respectively). Any idea why that might be? I regret that this is pushing me towards v.4, not so much because of compatability concerns, but because I would like to be able to verify the resulting profiles with DisplayCAL.
You have to use the exact same measurement mode / colorimeter correction. See the respective FAQ entry.
Thanks, Florian, and sorry about the long delay in getting back to this (work went into overdrive due to lockdown crisis management). I think that may perhaps be slightly misunderstand the question, though. It’s not that I’m getting different results between DCCS/PME on the one hand and DisplayCal on the other. (Where I can use DisplayCal to verify the DCCS/PME profiles, i.e. for v.2., I am in fact getting matching reports thanks to using the same correction.) It’s that the v.4 profiles produced by both DCCS on the Dell and PME on the BenQ seem to get the white point significantly closer to the desired D65 than the v.2 profiles (also produced by DCCS/PME and as per their own verification reports). I would like to use v.2 profiles, so that I can run DisplayCal’s far superior verification reports afterwards, but the fact that for some reason I can’t get as good white point on v.2 gets in the way. This seems odd, since you and most other colour management experts are all saying that there should be no noticeable performance difference between v. 2 and v.4. Have you ever heard of v.4 getting closer to the white point target than v.4 before, or is this something to do with my system?
Profile type/version & your calibration results are not related at all. DisplayCAL(GPU) or DUCCS/PME(HW) first calibrate (HW in an oversimplified way for the QC these manufacturers can provide), then software measure calibrated display and make a profile.
If you get closer WP to D65 using DUCCS/PME with icc v4 vs ICC2, and I mean actual “WP measured” (measured vs assumed, not measured vs profile whitepoint) with DisplayCAL, it’s just statistical chance. Not related to calibration at all or profile type. Choosing profile type and their measurenent it’s done AFTER calibration when your WP is fixed.
