All three images in the OP are rendered with dcamprof profiles. Look in the colorspace parameters, bottom-left, and the profile filenames confirm it (I had to go look, couldn’t remember… 
)
Glen going back in the post…why the xyzlut vs one of the other types??
If I understand the question…
xyzlut was the only LUT option available in dcamprof for ICC profiles. (??)
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…
1 Like
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…