So, in the ICC transform, there are two steps: camera → PCS, then PCS ->destination. If the camera profile converts to Lab, then the destination profile needs a matrix/LUT that converts from Lab. I don’t have any; I use Elle Stone’s ‘well-behaved’ profiles for most of my destinations, and those are all XYZ anchored.
Unless I’m missing something about the process, which is likely…
Not likely , I really just wondered if there there was a technical reason and I had remembered a tid bit that lab was preferred for lut creation…I went to check on the color charts…listed as sold out…
When you stick 2 profiles together to make a colour transform, the CMM* will perform conversions between XYZ and Lab PCS encodings as necessary. So (unless you are writing your own colour management software) you don’t need to worry about it.
Sooo… if I create a camera profile with dcamprof and the lablut parameter, if I use this profile in a transform to, say, Elle Stone’s v4 g22 sRGB profile (which has XYZ round trip matrices), LittleCMS will do camera → Lab, Lab → XYZ, and finally XYZ → sRGB? Never got that from the docs, although my reading was mainly "how does cmsTransform() work?, to do rawproc coding…
I think we do too much slinging of the pixels raw processing, so adding more transforms, especially one that departs, then returns to RGB coordinates, is not appealing…
With more patches, It’ll probably better-inform a LUT profile out of dcamprof; the 24-patch ColorChecker can really only well-inform a matrix profile. Make sure it comes with a .ti3 reference file, or something you can easily massage to that for dcamprof…
Perhaps. My only experience has been with the ColorChecker, for which both Argyll and dcamprof supply the data file, and the Wolf Faust IT8, same deal.
The reason for doing this on input is to prevent the math from breaking early in the pipeline. Specifically, if this is not done, in many cases the matrix that has the closest compromise fit leads to bogus negative luminance values in XYZ space when the camera is seeing a strong blue input (such as a blue LED).
The gamut compression is effectively undone using the 2.5D LUT in such a way as to not wind up with a negative luminance in XYZ space, which is why it is done as part of the input profile.
Interesting question. Me, I’m a fan of linear TRC camera profiles, with any conscious departure from the camera space to be done in a deliberate operation.
That said, I’ve come to rely on the LUT dcamprof creates from my SSF data to tame the conversion of extreme colors. This was arrived at by “try and see what happens” iterations, with absolutely no attention to the -k parameter. Reading the documentation for -k and @Entropy512’s response, I think I have some study to perform. For anyone else reading, here’s the dcamprof doc on -k:
-k <LUT compress factor>, decides over how long range the out-of-gamut linear matrix values should be compressed at the raw level before being handled by the LUT. If set to 0 no compression will take place. The value represents the uncompressed range compared to the gamut limit (which is the intersection between the locus and ProPhoto RGB). If it’s 0.7 it means that 70% of the range is uncompressed and in the remaining 30% the full range up to raw clipping is compressed to fit within DCamProf’s maximum gamut. The default value is 0.7, and there’s normally no reason to change it.