Extending on it a bit; what we see as red / salmon is the shadow of the small green leaves (I don’t know what they’re called) just in the back of the petals. They may well be attenuating some of the wavelengths that would otherwise make the petals seem more yellow. That part of the flower seems to be mainly lit by the backlight coming from outside (compared to the other parts which show no issues), so this would make sense to me.
Indeed. I just built RawTherapee from latest git revision to play with it and get a feel of how it behaves.
This was 3 clicks in DT… 2 Tone eq presets and dehaze…using auto exposure as the starting point …it still needs more work but comparing to the LR workflow at least in this case and ease to get to your starting point as shown above it was just as easy in this case in DT… I think really much of the fiddling around happens in conjunction with the decision to use filmic and then perhaps handling any side effects of that …There is only one small blown area really in this image so there is not absolute need to use filmic… but if it gets used then the user just needs to know its moves The interactions it can have with norms and WB can at times be tricky
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.
