I did this on purpose because my lens tends to have a slight red cast at the edges of the photo. That’s why I selected the darken option under correction mode in the CA module. This is how it looks with standard mode:
Colors are not changed there.
1 Like
so you don’t think it’s too green? and that’s the version you would use?
EDIT: really strange but on the last photo under the text " If you then additionally switch on and adjust the chromatic abberation module , the problem is completely solved:) " the unzoomed version looks greenish but when i zoom into 100% it doesn’t and shifts to something ‘normal’ ?! so s long as it tooks ok to at full res then it’s probably fine 
I can’t elaborate much because I’m on the phone but if you’re on FB, this is about the original issue I had with the preserve chrominance toggle in 3.6: Redirecting...
In short, the CA of my favourite Sigma Contemporary 30 mm f/1.4 is quite hard to compensate. I haven’t tried to go back to this with DT 3.8 but the old defringe module definitely couldn’t handle it.
This is what a finished photo looks like. CA Module with standard…
…und hier darken option:
Note that the tree branches on the upper left corner do not look so reddish.
If the photo was too greenish, it could be corrected afterwards without any problems.
If you could give a sample photo, we could see what could be done.
3 Likes
@s7habo Ok, shame on me but I’m no longer able to achieve the same effect with my current workflow, even with preserve chrominance set to the default RGB power norm. Still… If I get back to the original photo developed using an older version of DT 3.x and a very different workflow, I can replicate the glitch. But it’s no longer relevant.
If you still happen to be interested in an example of the Sigma’s TCA, I can provide one. I just think it’s a bit off this topic.
When your problem is solved, it is no longer necessary. I’m glad it works with the newer version. 
If you have not watched this I would recommend it…
To summarize it…
1 Try to tweak TCA in lens correction first to see what can be achieved
2 Use the CA module…set strength to max and then adjust the radius and then back off the strength
3 Setting chrom preservation to MaxRGB in flimic is suggested as something that might improve the module results
4 Use a parametric mask and use the details threshold at a strong setting to select only the edges and minimize color loss
5 Try multiple instances one in darken only and one in lighten only and so you can use different settings for both
6 change the guide channel to the sharpest one for your image …may be red green or blue but it will impact the results…
Those were my take away points…
@priort I’ll watch it. But I’d like to emphasize that I don’t really struggle with sharp edges. It’s the bokeh what bothers me.
To be clear the sharp edges are for CA correction…not sharpening?? Or are you referring to CA…Longitudinal CA as opposed to TCA??
@priort Ok, now you caught me unprepared… What I mean is purple fringing in areas that are out of focus. Maybe I’m just mixing up terms here.
No I think I was initially misunderstanding you…I think you have issues with axial or longitudinal CA…and more focus has been on TCA… as defined here… I suspect
2 Likes
Thank you. Just a hypothesis, I suspect given the nature of axial CA that the choice of chrom pres used might have a pretty strong impact + or - on it…beyond your control is the lens. I guess that is why some lens are so expensive is that they have optics to reduce this…
I am sure someone here can comment from an informed position rather than my speculation.
No worries. This looks very nice. 
2 Likes
Filmic’s defaults don’t render the output desaturated, they actually preserve the original saturation 1:1 and the original hue.
If you remove the chroma preservation, then saturation and hue are not preserved and the shadows get resaturated by an amount that is decided by the contrast setting. But a contrast setting should not change saturation, let alone shift hues: the label says it affects the lightness distribution.
Your problem here is about your expectations, not about what the software does.
4 Likes
Its possible to quite easily visualize what Aurelien is talking about by being a bit systematic with your settings!
I made these with my Sigmoid branch as that module makes it very easy to adjust the contrast that he is talking about.
- Per Channel = chroma preservation set to none
- RGB ratio = any of the other preserve chroma settings.
Note that this WIP module corrects for hue shifts so that shouldn’t be a problem in the same way as vanilla per-channel processing gives.
The saturation does go up with increase contrast as stated. The setting contrast = 1.25 will give pretty much untouched shadows and only smoothly desaturates the highlights.
What I find interesting is that preserving stimulus color (the emitted spectrum distribution from a pixel) does not mean that the perceived image saturation is preserved. It actually seems to decrease as the contrast is increased.
So yeah, rgb ratio (filmics preserve color) is your problem. My gut feeling is that the true actual correct proper method is somewhere between these two method. I would thus take Aureliens statements about should and shouldn’t happen in a display transform with a grain of salt.
2 Likes
I understand what has been said in the video and I think I can live with that. It was quite interesting too. On the other hand, I don’t quite care about what is “correct” in terms of color science but rather about the result to which I’d like to get as fast as possible. I’m therefore left with hacks such as disabling the color preservation. Of course, if I had the choice, I’d rather have a toggle saying “washed-out blacks” instead of some black point thingy left for me to figure out. But that’s just me.
This has nothing to do with scientific correctness or any other geeky obsession. Say you are happy with the amount of contrast at 2.0 but displeased with the amount of saturation… Then you are screwed because both come in a pack. So the idea is to let you control each of them separately, which may feel like it’s adding one more editing step, while it’s actually making both of these step a lot more reliable workflow-wise.
In engineering school, one of my teachers explained the difference between good and bad design like this:
The faucet above has a bad design because each of its knobs controls temperature AND the flow rate simultaneously. Say you are happy with the temperature but wants faster flow, you need to turn both and find a new hot/cold balance that matches your desired temperature at desired flow.
The last faucet has good design because temperature is controlled by the angle of the lever around the base, and the flow rate is controlled by the height (or the angle compared to horizon). So when you found the right temperature, you just have to pull the lever more or less vertically to set the right rate. That’s what we call “orthogonal axes”: setting the value on one axis does not mess up with the other.
And that’s the whole point here.
9 Likes
It’s important though to consider which axes should be orthogonal and which should be connected. This depends on use case and goals. I’m not arguing against the decoupling of saturation and contrast, yet, but people have different goals.
When all you want is a believable “correct” photo and your adjustments are small there may be arguments for coupled controls. Anyone who has used lab contrast knows that it creates very unnatural results unless you follow with chroma. (Actually it looks a bit like the RGB ratio examples by @jandren above) I’m guessing here but experience tells me there is a contrast saturation relationship that looks believable and that will be optimal in the vast majority of cases when a natural or believable look is sought. I know this is based on memory and expectations but that’s inherent and the main tool in all art and photography.
When a photograph is seen as a blank slate for grading like a film the orthogonal knobs become more important.
So what I’m saying is that the choice of which controls to make orthogonal are dependent on workflow, use case and goals. In these discussions this seems to be forgotten, the arguments about technical correctness are completely moot unless they fit into someones workflow, use case and goals. Stick shift vs automatic transmission comes to mind.
I think the assumptions about use case aren’t articulated and result in confusion amongst those with different use case and workflow. The scope of a free software project also means that the research about actual use cases is minimal or non existent.
2 Likes