DCamProf - a new camera profiling tool

[rubencarmona]

I opted for spydercheckr with 24 patches. It's not that expensive or complicated and good enough for my purposes:
https://www.youtube.com/watch?v=rAG7pyA0V_8

[torger]

PS: I was told (by IBorg) that if errors are noticeable (say more than 2dE-whatever) it is more fair to use dE94, not dE2000... dE2000 makes your results better than they are (numbers-wise)

Thanks for testing.

Concerning Delta E the idea of it is that color difference should be "perceptually uniform", that is DE 5 should *to the eye* look equally large difference between two yellows as between two reds. Today CIEDE2000 (dE2000) is the current best concerning perceptual uniformity, meaning that it sometimes produces larger numbers than older standards and sometimes smaller. That dE94 would be more "fair" because it produces larger numbers for larger errors is a strange thing to say, DE is not about fairness, it's about perceptual uniformity. If de94 exaggerates the error then de2000 is more correct.

dE2000 is like any color standard not perfect though, but I haven't read/heard anything about that dE94 would in some ranges produce more perceptually uniform numbers than dE2000.

This is the reason why DCamProf exclusively use dE2000 when optimizing. You can adjust the k-weights with the -w parameter though, so you can for example say that you're more interested in hue accuracy than in lightness.

[torger]

I opted for spydercheckr with 24 patches. It's not that expensive or complicated and good enough for my purposes:
https://www.youtube.com/watch?v=rAG7pyA0V_8

Those are fine easy-to-use products. Although you could use it like that, DCamProf is not intended to be a replacement for those, it's a much more advanced tool aimed at users with special interest or need in camera profiling. It's not easy to use and it doesn't hurt to know a bit color science before digging in.

That said the basic workflow using a macbeth colorchecker 24 and just defaults is relatively easy to get through.

The main reason I made the tool is because there where so many unanswered questions about profiling and camera performance that the available software could not provide answers to. Without being able to process SSFs a lot of things remain unknown, how accurate is a matrix profile, how good is cc24-based profiles, what is the limits of camera color separation etc. Using DCamProf all those questions can get an answer. I haven't really had time to get that far though, but at some point I'm probably going to write an article on camera profiling and camera color that answers a few of those questions I have myself.

That and because the profiles the commercial tools I've tested seemed to have issues with smoothness and did not allow me to control tradeoff between smoothness and accuracy (haven't tested spydrchecker though). With DCamProf you can control the smoothness/accuracy tradeoff, and you can also do things like saying you're more interested in hue accuracy than lightness accuracy, and that way gain more smoothness.

[Alexey.Danilchenko]

But what happens if you change to a custom profile, such as one generated by DCamProf? If I remember correctly the temp/tint will stay the same in Lightroom, which means that it derives those numbers from builtin matrices rather than from the profile. Most likely though if the custom profile is dual illuminant it uses those matrices to get the temperature which is used for matrix/LUT mixing but it doesn't show it in the GUI, so the temp/tint shown in the GUI is just for informational purposes, and I guess Adobe think those cannot be improved upon.

In the actual low level pipeline the white balance end up being multipliers for raw RGB channels, the temp/tint is just a transform using the CM(s)and the precision is of course limited as the camera doesn't measure the full spectrum. It becomes even more approximate if the illuminant used during profiling doesn't exactly match D50 or D65 or whatever the profile is tagged with. Most likely Adobe uses SSFs to derive the CMs, in that case the illuminants can be made exact and CMs will be better at predicting actual temperature.

It is even worse - the only white balance that stays the same across various DCP profiles is "As Shot" one. This is where it goes from multipliers to colour temperature/tint (and that will be different for different profiles). For all other presets or direct changes of colour temperature/tint in Lightroom/ACR - the path is backwards, from temperature to the multipliers (or more precisely mapping from XYZ to camera unbalanced to get white levels for that colour temperature/tint using CM or its approximation from the two given ones). And it is the colour temperature/tint that is considered primary in Lightroom/ACR so this is the parameter that is preserved with raw development - not the chosen corresponding white level in raw (which would be more correct and work across profile changes).

The wb does not have to match D50 - it is chromatically adapted to that (by white balancing and applying the forward matrix). As far as the DCP is concerned the matter is in whitebalancing the scene. The idea with two matrixes for different illuminants was that the right colour temperature is determined from the WB of the scene (and considered to be a scene illuminant), then the approximated matrixes are calculated for the scene illuminant (proportionally being between illuminants of two matrixes in the profile) and that the forward matrix obtained that way will be chromatically adapted to D50 XYZ (with WB of the raw when applied will have 1,1,1 mapped to D50 with the FM obtained this way). I am yet to be convinced that this is any better than ICC profiles which are effectively a single FM without D50 XYZ limitation (if we consider only matrix with shapers type of ICC for the moment). RPP uses (in most cases) matrix shaper ICC profiles without any problems.

[affu933]

thanks bro

[torger]

It is even worse

Thanks for the info, very interesting. Dual-illuminant profiles are really only a user convenience feature, so you don't need to switch  between appropriate single illuminant profiles. I'm also doubtful that they actually provide any meaningful extra accuracy in the range between StdA and D65 which is the typical pair used. With DCamProf and SSF simulations you can answer that question though, you can render a dual-illuminant profile and then a single-illuminant for inbetweener and compare their performance. This is one of the experiments I intend to do in the coming weeks.

I'd like to add ICC support too, but it's quite massive work so it will probably be a while. The boring thing with ICC is that preprocessing is not standardized so Capture One ICCs, RT ICCs, Leaf ICCs, Phocus ICCs and I guess RPP ICCs are not really compatible with eachother, so I would have to add some "pre-processing specification" to support ICC. Argyll have some problem generating ICCs for say Capture One as Argyll expects linear input and when it gets curve-distorted inputs it makes less than ideal optimizations. For linearly preprocessed pipeline, like RT for example, I guess Argyll makes a really good job already, but it's optimization engine seems more targeted towards the scanner use case than the camera.

[torger]

RPP uses (in most cases) matrix shaper ICC profiles without any problems.

From the limited experiments I've done so far it seems like matrix-only profiles for modern cameras are generally quite good performers for the colorcheckers. There's even a standardized measure for that, the Sensitivity Metamerism Index that DxOMark includes, the higher the number the better matrix-only match is possible. When it comes to high saturation colors outside the typical test target it seems though like a LUT can improve things significantly.

If the preprocessing step before ICC is applied is linear the shaper (ie linearization curves) step should not really add anything as far as I can see. Cameras today are linear, and I don't think shaper curves can do anything LUT-like, but maybe I'm wrong? For preprocessing like Capture One does shaping is required, but it would probably be better to use a fixed linearization shaper than trying to optimize something without knowing how the preprocessing is made. At least it seems so from the brief tests I've made using Argyll on Capture One.

[Bart_van_der_Wolf]

I'd like to add ICC support too, but it's quite massive work so it will probably be a while.

Anders, that would be hugely appreciated, as is the current tour-de-force. I'm impressed with what you've already done so far, thanks.

The boring thing with ICC is that preprocessing is not standardized so Capture One ICCs, RT ICCs, Leaf ICCs, Phocus ICCs and I guess RPP ICCs are not really compatible with eachother, so I would have to add some "pre-processing specification" to support ICC.

Yes, but then DCamProf would immediately become the best solution for camera profiling, and fill a huge gap left by other 'solutions'. I've noticed some brightness shift issues in Capture One Pro with the Argyll based wrapper (MakeInputICC) that Iliah Borg made available, when I select a linear tone curve (the default ICC profile for my camera has gamma 1.9-ish TLCs, but not pure gamma). So being able to adjust for that in the profile creation stage would be fabulous.

Cheers,
Bart

[Alexey.Danilchenko]

Thanks for the info, very interesting. Dual-illuminant profiles are really only a user convenience feature, so you don't need to switch  between appropriate single illuminant profiles. I'm also doubtful that they actually provide any meaningful extra accuracy in the range between StdA and D65 which is the typical pair used. With DCamProf and SSF simulations you can answer that question though, you can render a dual-illuminant profile and then a single-illuminant for inbetweener and compare their performance. This is one of the experiments I intend to do in the coming weeks.

Eventually perhaps - I am trying to get my own monochromator setup (not quite there yet) to obtain spectrum for my Kodak cameras/backs. Then I'll do the experimanting. For now single matrix profiles perform just as good.

I'd like to add ICC support too, but it's quite massive work so it will probably be a while.

You are already using lcms2 and it has capabilities to create profile from scratch and write it out to the file. The dcp2icc tool uses it like that.

The boring thing with ICC is that preprocessing is not standardized so Capture One ICCs, RT ICCs, Leaf ICCs, Phocus ICCs and I guess RPP ICCs are not really compatible with eachother, so I would have to add some "pre-processing specification" to support ICC. Argyll have some problem generating ICCs for say Capture One as Argyll expects linear input and when it gets curve-distorted inputs it makes less than ideal optimizations. For linearly preprocessed pipeline, like RT for example, I guess Argyll makes a really good job already, but it's optimization engine seems more targeted towards the scanner use case than the camera.

True - but then from prospective of getting the accuare colour none of that would not matter. This only start becoming a problem when profile adds some nonlinearity (as in LUT type of corrections which could be dependent on exposure corrections and so on).

From the limited experiments I've done so far it seems like matrix-only profiles for modern cameras are generally quite good performers for the colorcheckers. There's even a standardized measure for that, the Sensitivity Metamerism Index that DxOMark includes, the higher the number the better matrix-only match is possible. When it comes to high saturation colors outside the typical test target it seems though like a LUT can improve things significantly.

If the preprocessing step before ICC is applied is linear the shaper (ie linearization curves) step should not really add anything as far as I can see. Cameras today are linear, and I don't think shaper curves can do anything LUT-like, but maybe I'm wrong? For preprocessing like Capture One does shaping is required, but it would probably be better to use a fixed linearization shaper than trying to optimize something without knowing how the preprocessing is made. At least it seems so from the brief tests I've made using Argyll on Capture One.

My understanding is that LUT based profiles can introduce non linearity and as such result in colour shift (and transformation noise), matrix preserves linearity and is essentially better (though possibly less precise).

[Alexey.Danilchenko]

I've noticed some brightness shift issues in Capture One Pro with the Argyll based wrapper (MakeInputICC) that Iliah Borg made available, when I select a linear tone curve (the default ICC profile for my camera has gamma 1.9-ish TLCs, but not pure gamma). So being able to adjust for that in the profile creation stage would be fabulous.

MakeInputICC will calculate the gamma from the meaurements. So if you are using RawDigger to get the target measurement, it will be close to the one you select there when saving the samples grid (at least that was my experience).

[torger]

My understanding is that LUT based profiles can introduce non linearity and as such result in colour shift (and transformation noise), matrix preserves linearity and is essentially better (though possibly less precise).

Yes for things like HDR merging a matrix-only profile is preferable thanks to the linearity, but if merging takes place on the raw level (like Lumariver HDR can do) it doesn't matter. Otherwise my personal opinion is that matrix profiles is not preferable, the linearity is a sort of mathematical beauty but I find that improved accuracy especially for high saturation colors is preferable. LUTs have a bit bad reputation though as software before has used them to correct without thinking about smoothness, and is often used to create "looks" which one may not agree with. I hope DCamProf can improve this reputation later on.

I have some ICC code since before, I'll see if I'll use lcms2 or not for parsing/writing, lcms2 supports the whole large ICC standard and DCamProf will use only a small subset, it may be less work sourcing in my old code than "dumbing down" lcms2. That part is anyway only say 20% of what needs to be done to get full support.

[AlterEgo]

Thanks for testing.

Concerning Delta E the idea of it is that color difference should be "perceptually uniform", that is DE 5 should *to the eye* look equally large difference between two yellows as between two reds. Today CIEDE2000 (dE2000) is the current best concerning perceptual uniformity, meaning that it sometimes produces larger numbers than older standards and sometimes smaller. That dE94 would be more "fair" because it produces larger numbers for larger errors is a strange thing to say, DE is not about fairness, it's about perceptual uniformity. If de94 exaggerates the error then de2000 is more correct.

dE2000 is like any color standard not perfect though, but I haven't read/heard anything about that dE94 would in some ranges produce more perceptually uniform numbers than dE2000.

This is the reason why DCamProf exclusively use dE2000 when optimizing. You can adjust the k-weights with the -w parameter though, so you can for example say that you're more interested in hue accuracy than in lightness.

well, you shall be better off asking him directly, here is what he said not so long ago, about why dE94 is better when we evaluate the output using custom profiles vs simulations using .cie (with BabelColor Patchtool) :

> why dE94 is better ?

Because dE2000 by design is intended for evaluation of smaller differences. dE94 is a good middle ground.

[Alexey.Danilchenko]

Yes for things like HDR merging a matrix-only profile is preferable thanks to the linearity, but if merging takes place on the raw level (like Lumariver HDR can do) it doesn't matter. Otherwise my personal opinion is that matrix profiles is not preferable, the linearity is a sort of mathematical beauty but I find that improved accuracy especially for high saturation colors is preferable. LUTs have a bit bad reputation though as software before has used them to correct without thinking about smoothness, and is often used to create "looks" which one may not agree with. I hope DCamProf can improve this reputation later on.

My understanding is that the accuracy will be better with matrix simply because the linearity is preserved. LUT profiles will introduce colour shifts because they can introduce non linearity and hue shifts

[Bart_van_der_Wolf]

MakeInputICC will calculate the gamma from the meaurements. So if you are using RawDigger to get the target measurement, it will be close to the one you select there when saving the samples grid (at least that was my experience).

Hi Alexey,

Yes, but (besides the mostly linear RawDigger to CGATS) the LUT gamma is not a pure gamma, when I look at the CLUT slope of the default EOS-1Ds Mark III profile that comes with C1 , and try to fit a function. So if that's what C1 expects, then the profile should be more flexible than having a simple Matrix and/or gamma based CLUTs. I therefore see the difficulty that that poses for Anders, given that different assumptions are being used by different applications.

Cheers,
Bart

[AlterEgo]

My understanding is that the accuracy will be better with matrix simply because the linearity is preserved. LUT profiles will introduce colour shifts because they can introduce non linearity and hue shifts

LUT profiles also can be obtained from camera's SSFs, spectrum of illumination, etc... so while they can LUT is not a bad thing if done in a proper manner... guns do kill too, not that I am pro-NRA.

[AlterEgo]

Hi Alexey,

Yes, but (besides the mostly linear RawDigger to CGATS) the LUT gamma is not a pure gamma, when I look at the CLUT slope of the default EOS-1Ds Mark III profile that comes with C1 , and try to fit a function. So if that's what C1 expects, then the profile should be more flexible than having a simple Matrix and/or gamma based CLUTs. I therefore see the difficulty that that poses for Anders, given that different assumptions are being used by different applications.

Cheers,
Bart

well, you can always use C1 itself to make the tiff and take it from there, instead of using RD (or lobby for RD v2.0, long overdue, to include some more complex processing when generating cgats in addition to simple gamma)

PS: there is also linear scientific curve .fcrv that can be used instead of linear curve (just rename it) - for example the content of linear scientific curve .fcrv will switch off blown highligts correction in C1... try it

[Alexey.Danilchenko]

LUT profiles also can be obtained from camera's SSFs, spectrum of illumination, etc... so while they can LUT is not a bad thing if done in a proper manner... guns do kill too, not that I am pro-NRA.

You are missing the point - it does not matter how you build them and with what precision. LUT is a grid of space to space mapping in the nodes and between the nodes it gets linearly interpolated. This interpolation can add nonlinearities especially if LUT nodes are chosen to correct some of the colours camera cannot distinguish. In these cases we are in with the hue shifts when exposure correction is applied.

[AlterEgo]

You are missing the point - it does not matter how you build them and with what precision. LUT is a grid of space to space mapping in the nodes and between the nodes it gets linearly interpolated. This interpolation can add nonlinearities especially if LUT nodes are chosen to correct some of the colours camera cannot distinguish. In these cases we are in with the hue shifts when exposure correction is applied.

well, you can find out what "colours camera cannot distinguish" and then it is not going to be worse than with matrix in terms of what you do with camera RGB input there... why shifts if exposure correction is after color transform (not RPP) ?

[Alexey.Danilchenko]

well, you can find out what "colours camera cannot distinguish" and then it is not going to be worse than with matrix in terms of what you do with camera RGB input there

In what way it is not going to be worse? My understanding is that it will always be worse when your exposure is not spot on (at least it will increase the chances of those shifts).

[torger]

DCamProf uses a 2.5D LUT, this means that regardless of lightness the same correction is applied. This means that there is no exposure-dependent hue-shift in the profile. In very rigid copy-style setups with known objects to shoot a 3D LUT can be better (this is disussed in the docs), but in all other cases a 2.5D LUT is wiser. Adobe uses 3D LUT "LookTable" in most their profiles but that is to create a subjective Adobe-look(tm) which is a different thing.

There are other sources of non-linearities and hue shifts though, S-contrast curve, desaturation of highlights to mimic film behavior etc.

DCamProf's LUT nodes are the patches, after patches with (almost) the same chromaticity has been grouped together, and then depending on weighting those nodes can be relaxed towards neutral to minimize stretch/compression/bend. You can plot the LUT using gnuplot and adjust weights as desired.

By setting grouping distance to zero (-d 0) you can get the LUT correct each patch spot on, but that can lead to crazy bends, and as same color can be represented by different spectra (and will produce different errors) it does not really make sense to get spot on.

Any fairly recent camera has overlapping filters and is relatively good at color separation. There are still minimas where they don't separate too well, but if that happens to be in one of your patches I don't really see how that would be a problem. The LUT will then make an average correction for that general group of colors.

It is a problem if the LUT makes extreme stretches, but if that happens then something is generally very wrong, bad lighting of test target, bad reading of test target, bad reference file etc.