DCamProf - a new camera profiling tool

[torger]

CIECAM02 has significant practical issues with colors near to or beyond the spectrum locus, particularly near blue. I think that the basic nature of CIECAM02 makes any elegant solution impossible. (I get passable results with a number of hacks to it). A "nice" solution would involve re-formulating the equations used to accommodate extrapolation, and then re-fitting them to the original data CIECAM02 data sets.

Timo Kunkel and Erik Reinhard's simplified and improved model inspired by CIECAM02 might be a place to start.

Thanks, very interesting paper! At some point I'd like to revisit color modeling and standard observers etc. I think however that the problems I have today with extreme values can be solved with an "inelegant hack", blending over to some other type of approximation. One likely way I'll end up is that before CIECAM even starts getting used the gamut values are compressed into a range it understands.

Close to the locus I don't expect good accuracy anyway, and good accuracy and avoiding clipping are conflicting goals. Camera SSF and Observer CMF are different enough that a good translation can only be had in normal range colors. For extreme colors, as demonstrated by the artificial light some posts back, the matching problem becomes impossible. In that range it's more important to just output some color and have smooth gradients.

I'm battling with how to achieve that goal. I've almost completed a new matrix optimizer that fits the matrix withing ProPhotoRGB to avoid DNG pipeline clipping (that matrix has good hue match, but is strongly desaturated). That matrix will be used for DNG profiles with LUTs. It can be used as input to DCamProf's native LUT too, and what then happens is that the LUT will stretch like crazy to match chroma in the normal range colors, and then compress strongly towards the edge of the "gamut triangle". It achieves the goal of a good match in normal range colors while not clipping in the extreme range. However I think there's a better way to do it, which I'm investigating.

I'd like to use the "good match" matrix as input to DCamProf's native LUT, and somehow transition into an extreme value handling. I'm a bit worried about using a compressing matrix for DCamProf's native LUT as the LUT then has to stretch long distances within the normal range, and I'm not sure the special "LUT space (chromaticity + lightness)" is suited for that, ie inbetween colors might drift in hue. Having an input matrix that requires as low stretching as possible in the LUT seems more healthy, and it makes weighting/relaxing much easier to work with. If I change to a compressing matrix the behavior of weighting will change to a major extent and I'd like to avoid that if possible. Having to rework the tutorial docs etc would not be fun.

(DCamProf's native LUT does not need to work with the same input matrix as the DNG profile LUT, as it's only about encoding)

[torger]

A note to those sending me PMs about the software; I'll likely be a bit slow replying for a while, I'd very much like to sort out this extreme value issue so I'll see where the software ends up first, and it's a challenging problem. I don't want to sacrifice performance in the normal range, then I rather have it work a bit worse than say Adobe in the extreme range, but it must become better than it is today.

[torger]

Experiments are continuing, rejecting idea after idea.

There is a risk that the problem is "unsolvable". We can see that for example Adobe's profiles for A7r-II and Pentax 645z are unrealistically desaturated and have a very light blue. This makes it possible to render smooth gradients with ever-increasing intensity all the way to the extreme values.

If you instead render realistic saturation and blue in the normal range, you get a very difficult transition into the extreme values.

If the problem proves unsolvable there's very uncomfortable changes that needs to be made, namely that the base profile should not be colorimetric, that is you should not try to match the target, but instead be "inspired" by the target but let the camera hardware take the upper hand. Hues can still be matched, but saturation and lightness would be up to the hardware. I don't want to end up there, as then the "look" will be quite random and hardware-specific.

I'm not out of ideas yet though, more things to try...

[torger]

To structure the thoughs a bit; here's the current challenges:

• DCamProf builds on the idea that you have an accurate colorimetric base profile, which you apply tone reproduction (tone curve) and gamut compression on top
• Problem is that colorimetric base profile is only well-defined within the target range (typically CC24) and some distance outside that, for extreme saturation it's not well defined and will typically clip. You can recover clipped data when gamut compression is applied afterwards.
• Some of the recent Sony sensor models like those in 645z and A7r-II have a high sensitivity blue which accentuates this effect
• The obvious solution to pre-compress the gamut already in the colorimetric stage to avoid clipping is hard to make good looking, especially for the Sonys as you need to compress a lot in a short range, or do like Adobe and desaturate the whole profile (ie sacrifice color realism also in the normal range)
• A related but different issue is that maybe accurate deep blues (well-represented by the deep blue CC24 patch) is not what people want, as better tonality is had if you lighten it. Currently DCamProf has no controls for this type of strong subjective adjustment already in the colorimetric stage, it may be a huge effort to implement support for this.
• Clipping issues in the tone reproduction operator by pushing CIECAM02 too hard, but some of it may be solved by itself if some sort of pre-compression is made, so I've saved those issues to later

I'm not particular fond of the idea and do like Adobe, always prioritize robustness over nice colors as robustness is more commercially important for the mass market, so if the problem turns out "unsolvable", I'll clip "nicely" as a first stage (current 0.9.13 clips ugly sometimes with color shifts, sometimes to black), and in the longer term make it possible to make a desaturated profile particularly targeted at rendering extreme range colors without clipping. Interesting enough it's probably only certain cameras that are going to benefit from that, such as the Sonys, while I think my Canon and Hassy would be fine without as it doesn't have that kind of blue sensitivity.

I'm perfectly aware of that artifacts in the extreme range will give me more "support tickets" than having less-than-excellent color in the broad normal range, as the first is easily seen (in scenes where it's triggered), the other is just a matter of taste, so I'm not surprised Adobe's profile is the way it is.

[Frederic_H]

All I can say is good luck with it, the results achieved in the normal range were certainly promising.

[BradSmith]

Keep going guys.  You're almost at 1,000 replies.

[torger]

By the way I tried implementing that alternate CAM presented in the paper "A neurophysiology-inspired steady-state color appearance model" by Kunkel and Reinhard.

I did not analyze it or anything just a quick copy paste from the paper and see what numbers I got compared to CIECAM02. I was hoping that perhaps it could handle the extreme range better, but actually it's the opposite. That model works in a smaller gamut so for my uses there's no obvious advantage over CIECAM02.

I'm thinking about making a special-case CAM which is a blend between CIECAM02, CIELAB and/or home-made RGB. For the extreme range one need to be pragmatic, no colorimetric model will yield "correct" results, we just need something that looks good.

The main use for these color appearance models in DCamProf is to have a coordinate system that can scale chroma in a decently uniform way while keeping hue and lightness constant. CIECAM02's JCh has less color shift issues than CIELab, but Lab is more robust for extreme values. Some have munsell corrected Lab (RawTherapee have that) or Bruce Lindbloom's UPLab which is the same thing - non-linear correction of the Lab coordinate system to provide better uniformity and less colorshift. These spaces are probably even better than CIECAM02 concerning uniformity, I don't know how they perform in the extreme range though.

I haven't find any strong need to further improve the uniformity of CIECAM02 for its use in DCamProf, but I can't really use it for say gamut-compressing ProPhoto to AdobeRGB, as it can't represent all colors in ProPhoto (which indeed has a blue corner outside the locus). There's another issue which is that for extreme range of blue the lightness drops to near zero (same would be for red too, but due to common RGB gamut orientations we never get there). So if we say have an extreme blue with ~0 lightness and then just compress chroma axis the lightness is still ~0. For this reason I'm considering a model where you stop doing normal colorimetric model for the extreme range but instead just pretends it's some RGB space (with brighter blue, probably sRGB-bright), and then do some suitable transition between them both. It will be a very application specific space, specifically made for general purpose camera profile making.

[GWGill]

By the way I tried implementing that alternate CAM presented in the paper "A neurophysiology-inspired steady-state color appearance model" by Kunkel and Reinhard.

I did not analyze it or anything just a quick copy paste from the paper and see what numbers I got compared to CIECAM02. I was hoping that perhaps it could handle the extreme range better, but actually it's the opposite. That model works in a smaller gamut so for my uses there's no obvious advantage over CIECAM02.

Interesting result.  It might be easier to straighten out though, since I think it is a bit simpler (one less matrix transform ?).

The main use for these color appearance models in DCamProf is to have a coordinate system that can scale chroma in a decently uniform way while keeping hue and lightness constant. CIECAM02's JCh has less color shift issues than CIELab, but Lab is more robust for extreme values. Some have munsell corrected Lab (RawTherapee have that) or Bruce Lindbloom's UPLab which is the same thing - non-linear correction of the Lab coordinate system to provide better uniformity and less colorshift. These spaces are probably even better than CIECAM02 concerning uniformity, I don't know how they perform in the extreme range though.

A much simpler space with good hue linearity that has been used as an alternative to L*a*b* and CIECAM is IPT space:

F. Ebner and M.D. Fairchild, “Development and testing of a color space (IPT) with improved hue uniformity”, Proc.6th IS&T/SID Color Imaging Conference, 8-13 (1998).

I think that iCAM also uses IPT as its underlying appearance space.

It is missing the chromatic adaptation machinery though, so needs a little adaptation to be practical.

Email me if you want more details about it.

[torger]

IPT looks really interesting at least for the gamut mapping task.

The problem with many of the color appearance models in the extreme value range is that they're not designed to handle situations where you get negative value output in the various matrix conversions (for example in XYZ->LMS). Looking at the IPT equations I see that have special case handling for negative values, which should mean that it will work in the extreme value range. I'll try to implement it.

I'm thinking that I could use IPT to always do a little gamut mapping to get within CIECAM02 range in the tone reproduction operator / look design engine.

IPT is locked to the D65 whitepoint (I'm assuming the reason is because you get straighter hue lines with that white point). DCamProf works with D50 whitepoint as that's the whitepoint for both ICC and DNG camera profiles, but I think a CAT (probably Bradford CAT as CAT02 also has extreme range issues) D65<->D50 will yield satisfactory results.

[jrp]

How does Photoshop implement Lab->RGB out-of-gamut conversion? 

[torger]

I don't know how Photoshop does such things.

I've done some more experiments and at last I'm feeling that things are moving a little bit forward rather than around in circles. There will be gamut mapping in several stages, and they will be of different type.

In the first stage it's in the colorimetric native profile, where the issue is the linear matrix that push extreme values to negative ones that get clipped, which is no good. Here I've experimented with compression using lots of techniques and color spaces, like IPT, and what I seem to end up with in this stage is RGB-HSL(!). That is compression is done of the raw camera values before conversion on the Saturation axis of HSL. This is by no means a "perceptually uniform" space, but as it's on the raw values hue stability seems to be quite good and as it's HSL it transitions nice and smooth (smooth gradients) to the clipping end of the extreme range. Any colorspace based on some sort of conversion has issues with meeting up smoothly with clipping.

In later stage compressions there will be other techniques used.

[torger]

Although the project may seem stalled, I am working on it. I expect to be able to deliver the next release in two weeks or so.

When programming on spare hours here and there sometimes the entire day's programming may be spent on some silly thing, like yesterday when the convex hull algorithm I've got off the 'net turned out to be buggy.

Anyway I'm overall seeing steady progress now and the next release will have some news, the weighting is remade, gamut compression is remade, it will be possible to manually tune also the colorimetric base profile, and various minor updates.

[Dmitry B]

Hi,

"Invalid JSON data" error is returned when "dcamprof-0.9.13/data-examples/spectrum.json" is fed to make-target:

$ dcamprof make-target -p cc24 -i spectrum.json target.ti3
Invalid JSON data in file "spectrum.json"
$

Changing line 13 from '"scale:"' to '"scale":' (mind the colon) makes make-target accept the spectrum data file.

Another issue is that having 'scale' set to 100 (which is the default for provided sample file) or 1.0 results in XYZ values not being recalculated in ti3. Removing 'scale' from spectrum data file entirely (along with providing properly scaled data of course) makes make-target recalculate XYZ values as expected.

Is this a [known] bug?

[torger]

Is this a [known] bug?

It's a bug, it was unknown to me, thanks for reporting. Will fix to next release.

[torger]

A progress report; I've come as far as I'm rewriting the docs affected by the new behavior. Usually one discovers issues when testing the workflows though so it may still be a while.

Gamut compression which now happens in several places seems to work well, and the new weighting and target adjustment functionality gives better control of the colorimetric base profile result than before.

Tone reproduction look remains largely the same, with a liiiittle lighter blues per default (the new weighting allows making Adobe/C1 style light blues if one likes that, but being plain wrong per default is too much even for me ). Clipping behavior of bright colors (with in-gamut chromaticity) has changed to the better.

I'm still working on a very difficult problem though. I've got an excellent test file which is a sunset in haze, producing a loooong smoooth gradient from reds to yellows and into clipping at the sun center. ACR profiles renders this quite well although they "cheat" a bit by letting many neighboring colors become yellow and lighten them a fair bit which hides gradient issues. The file does look like a "fried egg" without a curve like sunsets do so a 100% perfect rendering with no visible bands in the gradient is not possible, and ACR doesn't do it either but it's as good as it can be.

The bands are not "posterizing", but simply that one channel starts changing a fair bit slower, so there's mathematically nothing wrong with the gradient, but the eye sees the flattening as a band. These bands often occur as well when one channel reaches clipping and the other continues to grow. You can't solve these issues 100% with a profile, but the profile can reduce or increase the effects.

With DCamProf I have quite clearly the "fried egg" issue with sunsets with such bands.

The source of the problem seems to be that models of luminance are not precise enough when translated to RGB. As soon as you do anything with some other color model than RGB (like JCh, IPT etc), gradient issues are likely to occur especially when you have a transition in hue at the same time as the luminance increases, like in a sunset. The eye is extremely sensitive when it comes to detect gradient issues, sub DE 1 for sure. I'm looking at how to improve the situation, without falling back to an RGB-oriented model like I think both Adobe and C1 has. An RGB-oriented model is better at handling extreme ranges, clipping and gradients, but it's worse when it comes to the general look of colors.

DCamProf is already today a hybrid, using more RGB models in the extreme ranges and clipping, but it still doesn't work as well as I'd like.

Evalutation is a bit tricky though as it's affected a bit by the screen, color management can mess up gradients too.

[AreBee]

torger,

I've got an excellent test file which is a sunset in haze, producing a loooong smoooth gradient from reds to yellows...

What additional test-file phenomena, if any, would help you?

[torger]

torger,

What additional test-file phenomena, if any, would help you?

Test files that fails usually give me lots of work so I like it when they come far in-between :-)

Currently I think I have a quite good set of files, but once in a while a user sends me a problem file which in some cases gets added to the ones I use for testing for specific problems.

I'll probably make some high saturation color test photos later, but I need to do them myself as I need to have a real-life reference that I can look at in that case.

Anyway after some work today I think I'm closing in on getting the hazy sunset to work satisfactory. I still think Adobe makes noticeably better result on it, but at the cost of other aspects (hue separation and accuracy) that I don't want to sacrifice. There's always a tradeoff. In this particular case noone can make it perfect (as the camera clips on the raw level) and it doesn't feel as bad to be 90% perfect when the best are only 95% perfect anyway .

To make it work I had to drop the old rolloff-to-whitepoint algorithm and replace it with a new (still sorting out details on the new). It's dangerous stuff, there's a risk I break the look of other stuff so I need to test thoroughly on some of the old reference images I have. I hope it will work out well as the new rolloff is simpler than the old.

[professorbalrog]

could anyone with better software chops than me post an osx executable of the latest version (0.9.13) pretty please?

[AlterEgo]

could anyone with better software chops than me post an osx executable of the latest version (0.9.13) pretty please?

I think somebody posted OSX binaries couple of pages earlier in this thread...

[StephK]

Torger a big THANK YOU for DCamProf.  I was very unhappy with/disagreed with C1's interpretation of colour for the new 5DSR.  My photo partner has tried other software to generate a custom ICC profile for our camera and C1 with limited success.  Unfortunately, the previous profile he attempted with other software disallowed the use of the color editor in C1. 

DCamProf though has given us what looks to be an excellent profile to work from with full functionality in C1.  We only created the profile yesterday and much of it is over my head but I've been reading through much of your text to better understand it all. 

Thank you for creating such a comprehensive resource in understanding and applying custom profiling and I look forward to working with my custom profile.