Here is the thing : I do not give a flying shit about workflows that consist in nervously pushing all the buttons of an ill-designed color changing tool in which you may develop hacky shortcuts, which will feel intuitive if you keep practicing them enough, or if they resemble some other bullshit coming from an unrelated app.
I will not consider such workflows for they are nonsensical and mostly masochistic.
The “working” or “non working” property of a method or to an algorithm is to be asserted against a well defined goal. “Looking good” is not a well-defined goal. “Looking good” can be achieved from a canned look, called a LUT. Pushing saturation at constant brightness is a well-defined goal. Preserving hue through a tonemapping operator is a well-defined goal. Those goals imply controlling one parameter at a time without affecting the other.
We use photo editing software because digital photography exist as digital data, and software is how we interact with data. Interaction is about being to able to enforce a desired look in the least painful way. Fact is, a skilled retoucher will get good results out of any software, no matter how shitty it is. The difference between quality and shit software is the time spent and the number of steps required to go to the result.
Most users will take this problem the other way around, since they have no a priori target look: they look for a rewarding software that will give them “good looking” out of the box, or with very few steps, where the “good looking” metric is vendor-based and mostly rigid. The concept of vendor-based “good looking” is outright ridiculous in a FLOSS ecosystem where no budget can be allocated to research what good looking is on statistically significant samples.
To these users, explaining the limits of their tools is impossible since they don’t use them as tools but as toys, and simply don’t shake them enough to see how brittle they are. Yet they are. But they don’t want control, they want instant gratification. Until they see some really unwanted artifact, being out-of-gamut colors, fringes, huge hue shifts… Suddenly they become intolerant with all the shortcuts, cut corners and trade-offs that led to their very ugly outcome on which there seems to be no solution.
Whenever you find yourself resorting to “perceptual” color spaces, what you really want is to provide users a way to control the content of the image in a framework that provides psychological connections between sliders and the way we perceive color.
What I have shown here is that “perceptual” color spaces will not magically give you that, because they are riddled with flaws, design trade-offs and limitations that FLOSS developers simply overlook because they see “perceptual” written on the can.
I have shown here that this is not only conceptually wrong, but also problems start showing even in short-gamut spaces like sRGB, with examples to support it.
Now, don’t start trying to convince me that it’s still ok to push nails with a screwdriver, because if you don’t see the holes you poked in the drywall when missing the nail twice, I do. If this demonstration is not enough for you, then you are a believer, so please keep reproducing with your sister on your own highland and don’t seek respect from me.
For all of you who only seek “good looking”, fucking use pre-built LUTs and cut your expenses on software meant for control.