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.
I was thinking they might come with a file like this…
sc24_ref.txt (12.6 KB)
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?
1 Like
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.
2 Likes
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.
1 Like
Thank you for your reply.
For example, Darktable does not compress in the input profile, but clips negative values in the “color calibration” module that follows, right? Maybe…
1 Like
I enjoyed reading your wonderful articles, thank you. I am very much an amateur so I will do my best to learn English and PHOTOGRAPHY.
Thanks! I admire your tenacity, as my English isn’t so good at times… 
2 Likes