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
@priort I really didn’t know there were two types of CA. 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.
A bit late to the party, but …
P1210174.RW2.xmp (9.9 KB)
No worries. This looks very nice.
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.
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.
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.
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.
There is no color model so far that tells how much saturation should be applied for the amount of contrast added such that perceptual expectations are met. The closest we have is iCAM06 and it really doesn’t like night scenes : https://www.sciencedirect.com/science/article/abs/pii/S1047320307000533
To cut down on the cargo of bullshit above, I would like to remind people that filmic has a non-chroma-preserving mode with independent RGB channels handling for people who like to undo their color-grading before going to display. Just because IT IS NOT the default setting doesn’t mean that you can’t use it, build presets with it, and so on.
I also have made a video explaining why natural colors are not the preferred colors, especially regarding skin tones, so any attempt at making your “good looking” reference pass for natural is automatically nullified:
Today I was developing some images from last summer and I had the DT set up for the autumn set of photos (like the ones above). I developed some of the images and then went to compare it with the original JPEGs. Guess what – my own results were complete mess. I therefore got back to the suggested defaults + highlight color reconstruction and suddenly the photos started to look very close to the JPEGs most of the time. And I was happy with it.
Originally I went with the color preservation set to none because of some nasty artifacts the other values introduce to out-of-focus edges with CA. This issue is still there as I’ve learned today.
Now… I’d love everybody to calm down. I believe Aurelien knows perfectly well what he’s doing with the Filmic RGB module and it’s still very well possible for all of us to go back to the pre-filmic era with pretty and unrealistic colors.
That’s for the CA module to correct earlier. Color preservation preserves invalid colors too…
I’m acutely aware vision is mainly a brain thing. It’s also a social thing. This understanding is the background to most of my comments and the reason I said “natural or believable”. It’s there to emphasize that a natural look is a social thing.
Just as in previous art discussions the fact that something is social doesn’t mean it’s arbitrary. It just means you need different processes, knowledge and skills to arrive at the solutions.
I don’t question the idea of producing a “neutral” base onto which further edits are made. The issue is that I and many others see some odd colour behaviour thats clearly tricky to control. That specific pastelly look (not solved by color balance rgb colorfulness preset) . See above. There’s also a difficulty in managing shadows. I can’t imagine these are impossible obstacles.
I was bored so I made this using Filmic v6
and config file if you want
P1200988.RW2.xmp (17.8 KB)
It seems like this and several other threads are turning quite hostile. This doesn’t really help anyone. It also doesn’t seem fair to the devs to somehow pit sigmoid vs filmic, particularly when it starts to feel like personal attacks. These are tools, people, some of which have been in development for quite a while and work really well. No more and no less. I’m all for hearing the arguments in favor of one or the other, but I (and probably many other bystanders) couldn’t care less for the drama. I feel like @anon41087856 has been quite thorough in his explanations both here and on his youtube channel, and his approach makes a lot of sense: to separate each variable so that it can be independently controlled. It seems like the complaints haven’t been quite as thorough, though. In the end the devs are the ones putting in the work to build free (as in freedom) tools for all of us to enjoy.
That doesn’t mean that we can’t give any feedback. I think however, that the more specific we can be about it, the easier it would be to take actionable steps towards implementing said feedback, or to discard the suggestion after some discussion based on its merits/difficulty to implement/etc… Something like: When I do X I get Y, but I’d like to get Z instead. Or X would be easier/better/faster if we did Y. Vague feedback derail conversations and tends to frustrate devs. For example @nosle what do you mean by “that specific pastelly look (not solved by color balance rgb colorfulness preset)”? Can you show examples of the pastelly look, and of what you would like to achieve? Even if it’s from other software, so we all understand.
Then perhaps you could code up the solutions