DCamProf can make a pure matrix profile (with shaper curves if a transfer function is provided via the -t parameter), and a LUT profile with either camera RGB to XYZ conversion or camera RGB to Lab.
Quoted…
Also quoted…
DCamProf can make an RGB to XYZ or an RGB to Lab LUT, the latter is the default. Currently the XYZ LUT uses the forward matrix directly which means that extreme value handling is not as good as the Lab LUT, so I recommend using the default Lab LUT.
Oh, that’s right, forgot…
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…
The Mini - matte finish.
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.
* Colour Management Module - e.g. LittleCMS
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…
OK, I saw multiple references to matrix profiles, and assumed that your CC-derived profile was a basic matrix profile and not one with a HueSatMap
I don’t have the capability to use DCPs in rawproc; it’s all ICC for better or worse… 
Aha. Yeah, I exclusively use dcamprof for DCPs.
Wolf Faust is no longer selling his matte charts (they are listed as out of stock), but that mini matte target from CMP may be beneficial over a CC24.
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…
It says it comes with spectral data??
Not really correct, except maybe the inference that the numbers are measured with a spectrophotometer…
If they give a measured r, g, and b, I think you could build a .ti3 file from that. Or, they give you a .ti3 and you’re good to go…
xrite use a text file with nm values so perhaps they do as well there are cgat files with spec measurements so perhaps that is what they supply??
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.
Okay, includes both RGB/XYZ and the spectral band numbers. My Argyll-produced .ti3 just had RGB/XYZ…
dcamprof performs gamut compression for the ProPhoro gamut if the -k 0 option is not specified in the “make-profile” command, correct?
Wouldn’t it be preferable not to do this with the input profile, but to post-process it in some other way, e.g. OpenDRT?
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.