Yes. The skin tone editor color selector in C1 works the way it does due to the lack of tool-level parametric masking, basically folding two different “concepts” into one.
The DaVinci Resolve Color/Chroma Warper is next on my list, but that’s much more complicated under the hood. Color Variance is mostly just basic arithmetic applied pixel-wise.
It’s a finishing tool. That is, you do your grade and then add a final touch. So between Color Balance RGB and the tone mapper. It can be used for much more drastic edits as well, in which case it might make sense to move it.
I’ve been meaning to have a closer look at Resolve, but it’s my impression that darktable is mostly competitive.
Not related just to color, but take a look at the Film Look Creator in Resolve. If there’s anything I’m lusting for right now, it’s something like that. Bloom, halation and proper color film grain is nowhere to be seen in popular raw converters for stills. There’s Dehancer, but it doesn’t work on raw data.
Also, have a look at Baselight (which is actually Linux based) for inspiration. It has now been released for macOS too.
I’ve not read this thread, But we really need to generalize our design otherwise adding new module code by AI will soon kill Darktable. Remember one thing that is often said about Darktable is that it contains too many modules…
A module for skin tone, one for color harmony… then one for blue sky, one for deep/black sky… etc. At then end just for color harmony I’m sure we can get 10 modules easily.
As a testing bed, fine but when an idea is really filling some missing feature we need to rethink integration and see if the new feature cannot be added into an existing module.
For the case at hand, the 2 recent proposals Color Harmonizer and Skin Tone Editor we probably want a single module.
If these two modules could be a single module I feel that would be best. However, I like the idea of the term skin appearing in a module’s name if it can be used by portrait photographers. Maybe Skintone & Color Harmonizer would be a suitable name. I don’t see this as much different to when a module was renamed Astrophoto Denoise to indicate a specific use scenario, but that doesn’t limit its use to many other denoising requirements.
I feel it’s also a concern that there are too many ways to do things. (See: Perl.) For example, I’ve seen some of Boris’ videos where he adjusts contrast with color balance rgb, color calibration (multiply with a greyscale channel), and DorS.
It’s also possible with tone equalizer, local contrast, contrast equalizer, the tone mappers, and maybe Christian’s proposed contrast module. As a user of a few months, I’m concerned I’m picking the wrong method and leaving value on the table.
Where different operations achieve artistically different effects, it’s useful that they all be available. But when they don’t, too much choice is not good.
My point regarding these modules is that unifying the operations (if possible) is even better than making a new tab in an existing module. Can a preset remove the need for a new tab? (Setting some options that are only useful for skin, which color harmonizer otherwise wouldn’t need.)
That said, I’m not experienced with portraits so I’m deferring to the people that are.
Use one of the tone mappers for global contrast of entire dynamic range.
Use tone eq for adjusting brightness of specific ranges.
Use one of DoS, local contrast, contrast eq, or Christians module for local contrast. (Color calibration in multiply mode probably belongs in this category as well, at least how I’ve used it).
Use one of DoS or contrast eq for sharpening.
Use color calibration for adjusting brightness of a specific colour channel.
I’m not sure the use case for color balance rgb contrast.
If you just want to use the more recent scene referred modules, you can cross contrast eq and local contrast off the list. Or if you don’t have a good gpu you can probably cross DoS off the list.
Please be very careful with any language that suggests people’s natural skin is imperfect or implies that natural variation is ugly or incorrect. Enough people have body issues already. I’m not saying don’t do the module, just be careful as to the implications of the language. Get a sensitive native speaker to help if required.
Totally agree with you. I’ve just came here with this AI generated module to better illustrate why it could be useful to have a tool that deals with color uniformity, in my case, for editing skin tones in portrait. I thought it was a better and funnier idea than simply coming here and tell some talented developers : hey ! do what I want, please !
Obviously, I was wrong ! It seems that just the evocation of skin tones leads to fighting here, without talking of presenting an AI-generated module to illustrate a point. I don’t want to enter in endless debates - je suis bien mieux au bistrot pour ça -
I don’t say this module goal is to be integrated in DT ! Just the concept of it : color uniformity for a given range of colors, with a precise selection of source.
@Donatzsky said is already working on a solution, and it’s a great news !
And that’s a fact : a new user is lost when facing all those modules, with a lot of them doing the same thing. Understanding how the the DT pipeline works is needed before activating your modules, even if the pipeline is simpler than node editing in Resolve, for example…
That would be an ideal solution ! But we have to wait @Donatzsky proposition not to create (again) overlapping modules.
The only thing I care, in my egoist world, is to have the ability to achieve a goal : in this case, uniformity of skin tones, but it could be whatever tone, with visual and scope control.
I can adapt to the place of this functionality will be as long as I can do the job in a quick way (a thing that this skin tone editor lacks !)
But for a “general-user” DT workflow that’s another debate : should it be fulfilled with specialized tools easiest to understand or use, or generic ones that you have to learn to fulfill your particular needs ?
I can’t pretend I know what’s best for everyone, and it’s not to me to have an answer on this subject
I care because I like things done in a principled way. Two modules each doing one thing well, easily and clearly make sense, and are a good addition. One module that does both and has another generic name like “hue equalizer” is not, and I would not like to be associated with it.
If to have a module merged I need to turn it into a Frankenstein module, then I prefer not to merge it at all.
Maybe it could be usefull to have the distinction in DT between specialized modules and more generic modules ? A core base well defined where you can stack specialized modules on ?
I don’t know… It’s up to the DT devs to have the final word
I agree with @Masterpiga that combining them would result in an unmanageable mess of a module. Yes, there seems to be a fair amount of overlap in what they can do (I haven’t tried Color Harmonizer yet, so not sure exactly), but they are also fairly different in terms of what they aim to achieve and how. Color Variance (what I’m working on) has no notion of harmonies, opting instead for simply increasing or decreasing perceptual distance (variance) in several dimensions (hue, chroma, saturation and luminance), while giving a great deal of control over the “shape” of the adjustment.
Color Harmonizer does seem like it will be the more generally useful module, while Color Variance is likely to be a more technical and niche tool for those that want that kind of control. Time will tell. I’m making it as much as an intellectual exercise as anything, however, so I won’t cry if it doesn’t get merged, but I of course hope it will prove its worth.