Yes, I tried clean builds every time I changed the different options.
I’ll check github issues tomorrow. BTW I would say that I was compiling with gcc 16.x which is quite new, maybe it’s a bug 
1 Like
That was me. I just opened a proper issue on GitHub.
2 Likes
I compiled on Fedora 44 with gcc 16.1.1, no problems.
1 Like
the tooltip currently gives the following description for the module: enhance local contrast by boosting details while preserving edges.
Isn’t “preserving edges” inherent to increasing local contrast?
Alternate suggestion: increase or decrease local contrast at a chosen detail scale
1 Like
One more comment: higher values seem to relatively reduce saturation, similar to what happens with local contrast and contrast equalizer. It looks like the module primarily affects luminosity (?).
I’m not sure whether this is feasible to implement based on EIGF, but would it be possible to also affect color contrast? Either by it’s own slider (hello feature creep my old friend) or included in the “local contrast” slider?
1 Like
I took at look at the new weekly build for windows and didn’t see this new module mentioned so hopefully it will be in next weeks build for windows users. I know I could get it from Github but I am patient enough to wait for the weekly build. It sounds very promising and I really appreciate the effort developers put into keeping DT current an evolving.
Did you try also the Windows nightly build? It is there. 
1 Like
I hate to say it but we finally have Lightroom’s clarity slider in darktable. And it’s a premium version. Thanks!
I mentioned this in another thread, but color contrast is orthogonal to tonal contrast, so should be in a different module. I haven’t played with it yet, but Ansel has a new module just for that, which it would probably be worthwhile porting over to darktable.
1 Like
Did some quick tests and it appears to work well.
Created a drawn mask on the area cover mostly by the fog/mist and inverted it on the foreground. Applied 2 instances of the contrast and texture. Used negative settings on the foggy area and more detailed on the foreground.
3 Likes
Where can I find a user documentation for contrast & texture module? Thanks!
Where can I find a user documentation for contrast & texture module?
This was only merged to the code base a few days ago. Even so, user documentation has been drafted but not yet committed: Add documentation for contrast & texture by anoderay · Pull Request #1046 · darktable-org/dtdocs · GitHub
1 Like
@don51 I just made the first draft @phemisters just linked. Feel free to comment if you find room for improvement 
!
1 Like
Hi … why should color contrast be in a different module ?
For technical reason or why should this be not integrated ?
I do not get the point …
If technically possible to implement it , I would like to see it in .
But this might be just me ?!
Andreas
As tonal and color contrast are orthogonal, they can be influenced independently.
So individual tools make more sense (one tool per job, one job per tool), one tool combining them would give a more complex module for no real reason (the “feature creep” from @mino).
2 Likes
If processing of colour and tonal contrast are orthogonal that is saying they are independent of each each other - so they would in principle need two completely different sets of code and we might get a very bloated module.
I know it isn’t the dt way of doing things but it might be nice to have some co-ordination between modules in our architecture e.g. providing this module with a slider which was linked to a slider on another (not yet existing) colour contrast module. That would allow a more comprehensive contrast management here and if more complex colour contrast adjustment was needed you could just hop into that module.
While that may be true increased brightness leads to increased perception of saturation; I think because C&T mainly affects luminosity (as local contrast+contrast equalizer+DoS do) this leads to relative desaturation of brighter edges. At least that is what it feels like to me.
I think it would be convenient to address this similarily to how you can with the second tab of contrast equalizer.
That would make things a lot more complex in several ways:
- the module interface would change (either because all modules would have to expose all their parameters, or you get special cases, which are a maintenance nightmare;
- how do you handle presets/styles using one of the two modules (or both…)? Keep in mind that all parameters of a module are stored in a style. And I don’t think users are very happy with a preset for local contrast that changes color contrast, or with a preset that does not change one paramter (possibly even the same user at different times
). To be thorough: this is not at all the same case as leaving a parameter on “auto” (which is currently impossible).
That doesn’t follow, the implementation could possibly share a lot of code. But that’s not an argument to combine two functions in one tool, as such common code can be factored out.
2 Likes
That’s a different issue: you might want a local contrast module to correct for that.
But that’s not the same as allowing the user to modify color contrast in a module for tonal contrast.
2 Likes
I’ve now had a chance to test and compare the modules.
I find Christian Bouhon’s module much more practical and effective for achieving the results I’m looking for.
I also really like the global contrast parameter in Christian’s module. I think it’s very well designed, as it offers additional and different possibilities compared to the contrast parameter in the “Color Balance RGB” module.