Does that salmon tint go away if you lower the exposure? If it does, it’s not the light that hits it from the back.
that slightly underexposed starting point is looking very similar to the CAM16 results I posted up above (in the backlit petals!) without the salmon shift.
I tend to agree with that.
(Sorry If I keep coming up with this seemingly again and again. Since we have no good ground truth rendering to compare against, or synthetic test images, it’s the occasional rendering oddity that might show priciple flaws in a DRT approach. I’m not even claiming that CAM16 in rt is perfect, it isn’t, but maybe it serves as a quick sanity check with a markedly different approach to how per-channel plus hue-restore or rgb-ratio works. In that way we iterate towards a “ground truth” but, and thats the unfortunate part, there may never be a “ground truth”. Yet that salmon tint has shown up so many times, that I’m leaning towards “something iffy going on that is not supposed to happen”. Sorry if I come off as nitpicky in the wake of this.)
I threw the image into ART and used Adobe’s DCP just to have something sort of standard. There is definitely a fair bit of orange in this case in the inner circle of petal. It gets modified a bit by turning on the look component of the DCP but interestingly the most orange view might have been noticed when cycling through the tone curve options in ART. The curve version/option called film created this orange chiffon sort of look. Neutral removed it … Standard was a more saturated yellow etc …like DT you can get a very wide range of results when cycling these options as you do with the norms presented in DT under filmic.
I don’t think so. The highlights code tries to do exactly what it’s supposed to do, add some intensity to a clipped channel based on data in the other channels. (I guess we have a clipped green here) Thus filmic gets better data to work on…
Also note, if the regions discussed are very sml like just a few photosites, demosaic code would also be improved with restored data at borders
If the hue shift is (post-capture-) exposure invariant, it is in “the scene” or at least in the sensor data, thus “real” in the sense that any expected orange hue would be a hopeless expectation as the “real” data says “salmon-tint”.
If the hue shift is (post-capture-) exposure variant, it’s at least in the pipeline but potentially within the filmic module as it is responsible for mapping to display.
Okay, so my conclusion that CAM16 in rt doesn’t show this might be rooted in hightlight reconstruction and not the DRT itself. That would explain a lot, I’ll check my rt edit for this!
EDIT: highlights-reconstruction was checked in rt, but affects a region which is not the salmon-shift region I encircled in post 192, it’s right next to it in the petals which have sun backlight.
EDIT2: with highlight reconstruction turned off:
I was curious and looked through the whole edit and again here is the danger to assume its one thing or another in a series of sequentially processed modules. But likely the main thing has nothing to do with the HLR as you can turn it off with little effect… Bill did have it turned on at a crazy low clipping value of 0.28 or something but still disable the module and nothing in it really. He does have a CLUT module in there and also better yet he is using v5 filmic and not v6 and I think many would think that he is… if you take his edit and don’t change a single thing …just move the color science to v6…here is what happens to the flower… (NOTE HE IS USING no in preserve chroma)
You can get a little bit of salmon with RT’s CAM16 but you need to push luminance a lot and decrease saturation/chrominance (left), with normal saturation you don’t get it (increasing saturation seems to make the color converge).
Yes, I am trying not to jump to conclusions. After some playing in rt I do not see any blown channels, even without highlight-reconstruction.
I’ve been looking at channels in RT and the blue channel is almost zero in the critical region in the petals. I’ve tried to play with the blackpoints of all channels before debayer to force something to break, but I also get only very mild hints of salmon after a lot of trying things.
Question: is RT preventing negative values before debayer somehow and DT isn’t? From compositing I remember that carrying around negative channel values can cause headaches if not clamped to zero. Is DT carrying around negative blue channel values here which then could cause the salmon-shift or out-of-gamut-excursions?
Work through this edit. Turn various modules off and on. Set filmic to not use custom middle-gray. I don’t see the salmon coloring appear. IOW dt is handling the color w/o any problems, as I see it.
In your edit a big factor was that you used v5 of filmic and set CP to no… the difference between v5 and v6 set at this norm is quite substantial… I think the “salmon” issues are more prevalent in v6 also using latitude vs no latitude can alter the perception as well. I believe its 50% in DT right now… I think AP has proposed new defaults in his fork…using 0.7 EV hard shoulders and latitude set to zero so still more variation might appear in a “default” look if one was to adopt that… Actually using your edit I found the most pleasing combination to actually be changing your edit to v3 and no go figure…
I think that gamut mapping (chroma desaturation) looks good when dealing with really out of gamut colors aka the rgb pixel has at least one channel with negative values.
Desaturating in-gamut highlights (pixel with a channel >1 and no negative values ) could create a harsh look, in this case hue is correct but the saturation is not smooth
Would this not impact all versions of filmic unless there is a code change and there clearly is, so I think the answer lies the the filmic math in v6…
Edit here is switching that edit just to v3 and no… I really like also the way the color is on the vase… so if the data were messed up it should impact other edits as well one would think. I think the math in v6 is attempting to set things perfectly and constraining things to achieve accuracy but I think it can be undone by a camera setting or a WB in an image that is just not favorable with the math…
I really have no idea I just think under certain circumstances the v6 math might be prone to over runs…note my earlier reply I updated it with that v3 version of filmic…
v7 has hints of salmon although Yrg was changed to dtUCS.
Yrg has that hint of Salmon in there that neither Ok-Lab nor xyY have. But as far as I understand Yrg was used for filmic until v6, correct?
I’m a bit lost here. At this point I’d tentatively rule out that this salmon-hue is the “real world” hue though. My best guess is that a combination of very-low or negative blue channel values combined with Yrg AND something in v6 is not fully resolved in v7 with dtUCS. This behaviour can somehow be exaggerated or even found in other DRTs but then to a much lesser degree.
That’s how I would sum it up, feel free to interject and correct.
Yes and that must be done to fit the incoming colors in the gamut / primaries where you do the tone mapping (before the tone-mapping itself).
It depends. If you just clip the values to the upper bound (each channel must be 1 at most) then you’ll surely end up shifting the hue. In this case it would skew toward yellow which probably looks pleasant, but I don’t believe it’s desirable in general. What can be done is to choose the “direction” of gamut mapping to be something else than just along a horizontal line (i.e. at constant lightness, decreasing chroma), darkening the color a bit to get a higher chroma. Björn Ottosson has covered this nicely in his sRGB gamut clipping blog post.
No, it was introduced in v6 for gamut mapping.
In which space? In Rec.709 there are actually negative values there (without filmic or another DRT applied). While filmic does its tone mapping in the working space (usually linear Rec.2020, where the petals don’t get any negative blue values), at the output it maps the colors into the destination (export) gamut which is usually close to Rec.709. Some compression of chroma is necessary to get rid of the negative blue values there. I’m not familiar enough with the RawTherapee code to be able to resolve whether it makes an effort to fit the colors into the export gamut or if it clips the RGB channels to zero individually (which of course would distort the hue).
In darktable before debayer the image is expressed in the camera sensors primaries where there shouldn’t be any negative values by definition. There isn’t explicit handling of negative values when converting to working color space primaries (Rec. 2020) but at least for this image it doesn’t seem to be a problem – after the color calibration module (which does chromatic adaptation using linear transformations), the blue channel is non-negative except for a few spots (not in the problematic part we’re discussing here).
I can see a new a tab being introduced to filmic (or perhaps a new module after filmic?), Gamut Mapping! Drastically different results depending on the parameters set at that link, with not always the same method being most pleasing for each image.
Thanks for raising that. I’ve been thinking of it too. At this point I think it would make more sense to introduce a separate gamut mapping module that would be placed right before converting finally to the export / display color profile. That would be the right place to map the colors into the destination gamut, when also potential display-referred processing has been done.
And yes, there indeed are a few tunable options in gamut mapping that could be exposed. One is the direction / focal point control, another is an option to relax the gamut mapping a bit so that very slight deviations (probably only just noticeable or below) from the original hue would be allowed.
The hardest part would be hitting a sweet spot for sane defaults - as a regular user I wouldn’t like yet more knobs to tune when I would just like to get a set of photos done. The good news is that for ”easy”, regular images, those options won’t probably have such a drastic effect that would require tuning.
my guess is rec.709/sRGB but I’ll have to find out.
Sorry, my bad, I of course meant after debayer in the working space, such that WB is adjusted and blackpoints have been subtracted from raw values (and thus negative values could have been created).
okay, so the assumption that negative blue channel values in the working space break things can be ruled out most likely.
Which leaves this intersting thing:
but I think that this it at a stage (specific part of the pipe) where I could not try out things, even if I wanted to.
I like the idea! That would at least somewhat separate gamut-mapping from dynamic-range-mapping conceptually which are kind-of connected problems though. The ACES workgroup in their current candidates have some which use the “inbuilt” chroma compression of “ZCAM”(it’s not really ZCAM anymore) but also have DRTs which require a separate-from-the-DRT compression to manage out-of-chromaticity values.
Yes, indeed. I’m actually quite torn about this since the choices in both tone-mapping and gamut-mapping affect especially the convergence to white in the highlights, which is pretty important and likely has to be adjusted on a per-image basis. So it would even be a bit ugly if there were two separate mandatory-ish modules that control the same thing from different points-of-view. Another thing is how to abstract these things into a somewhat understandable GUI for a layperson to use. But cramming more stuff into filmic isn’t probably a very good option either.
Either way, gamut mapping probably has to be offloaded to a separate module to have it in the right place in the pipeline. It’s probably good to start with a GUI exposed, but if desired, the module could probably be hidden and the controls moved to filmic GUI if that makes things more cohesive.
Thank you everyone for this exchange. At least I’ve learnt a lot and I’m pretty sure there are improvements that can be made and I hope to make some progress in the limited spare time in my hands. Ideally this would be something that could be proposed for the next DT version but probably a lot of experimentation is required.
Another topic of experimentation for me is the choice of primaries for tone-mapping. When doing per-channel RGB tone-mapping, moving the working space primaries closer to or further away from the white point (xy chromaticities) has a profound effect on how bright colors are mapped. For instance, that simple trick can make a huge difference on how blue LED lights are mapped (converging towards white or presented as a rather dark with a ”clipped” artificial look which doesn’t look that plausible). I have seen some people in the ACESCentral forums experiment with similar tricks and it has turned out quite effective. More on that later…
go figure…
