Contrast EQ is already a much better version of sharpening, no need to wait.
Yes I always use contrast eq first. Only use sharpen module for particularly blurry images that contrast eq doesn’t handle on its own.
I think that few understand how they would apply the output mask settings and so it doesn’t get used…you can create a mask to try to select a group of pixels but you can’t always predict the exact outcome of the module or fix that by altering that input selection…if your module pushes say one hue or some part of your image selection too far but say it works as intended for most of it then you can fine tune it by restricting things using the output…a good example of this arose in this discussion sQsA Darktable - short question _ short answer - darktable - discuss.pixls.us.pdf (2.7 MB) So is it a matter of something that is not useful or that it is something that people don’t know really how it could be used to additionally fine tune the results of a module…in the end if nobody uses it then I guess there won’t be support
1 Like
@wpferguson I think your explanation is the primary intended use of the output as a fine tuning of the effects applied based on the current selection. Setting the values the same as @Soupy has done will in one case apply the sharpening to that range creating an output that can fall outside those bounds whereas the output version will limit the effect of the sharpening to values in that range…the nuance is shown well in this example I think… sQsA Darktable - short question _ short answer - darktable - discuss.pixls.us.pdf (2.7 MB)
2 Likes
Hm, imo it should stay. I also think people aren’t using it b/c they don’t know the difference between input and output sliders.
Let’s say you add a lot of contrast to some area you isolated in the input and in some parts you get pure black and pure white. You might wanna soften it up a bit by excluding or gradating the effect on the L extremes in the output mask.
It seems to me that output was made for a purpose and it’s better to have it and not need it then needing it but not having it.
3 Likes
And that purpose is currently being reevaluated.
You can do just as well with input. Or better, tweak your contrast curve directly to make it softer in highlights. Using output, you will need to redo the mask anytime you touch the contrast. Using input, you only rely on previous modules (which is already annoying enough).
I have never used it, so I won’t miss it.
It will be nice too (if it’s possible and make sense), select the mode RGB (scene) as the default one in the case that scene-referred is selected in preferences (auto-apply pixel workflow defaults)
I have never found a use case for it, and wouldn’t miss it.
I also have not used it and would be in favor of removing it
I haven’t needed it in the 10 months I’ve been using darktable. Maybe it has a use, so perhaps make it an option in the preferences settings.
If you really think there is absolutely no real use case for the output slider then remove it and I’ll trust your decision. I didn’t use it much to begin with.
Used it very rarely in the past, in my opinion it could be removed.
Not scope of this thread but in connection with setting parametric masks I want to point to a bug report (affects input and output slider) from june again (Bug : parametric mask, picking GUI color from image, chroma channel). The behaviour described is still present at version 3.3.0+1284~g665fc4d2f, Ubuntu 20.04, OpenCl enabled or disabled.
The best place for darktable related Bug reports is: https://github.com/darktable-org/darktable/issues/new?assignees=&labels=&template=bug_report.md&title=
Usually developers doesn’t search in discussion boards for old issue reports …
1 Like
Unfortunately, pehar does not want to create a github account.
I also didn’t use the output masking sliders. Maybe used it in older edits when I didn’t bother about what input or output masking could mean. But no need to keep it, in my opinion.
Here’s an idea on Masks relevant to the input/output question, possibly a little radical -
You could have a new Mask object and insert instances into the pipeline where you choose. Modules would no longer have mask functionality. New mask instances (hereafter just “masks”) could be inserted, amended and deleted.
The create and amend function would basically be the same as at present, however I don’t think the idea of input and output is needed - the mask would be be working on the output of the previous module, and its effect would be the input to the next module in the pipeline.
Perhaps masks could also be turned off, like modules.
A mask could be re-used by a later mask like now via the “raster” option, although this could maybe be re-named to somethng like “re-use previous mask” to be more intuitive.
A mask would always be calculated, unlike at present where it no longer exists if the module is turned off. At present this can catch you out if you re-use an earlier module-mask via the raster option.
I say “always calculated” but I suppose it would only need evaluating if something earlier in the pipeline changed.
I think that’s it.
You can do this today by using a ‘no-op’ module. For example you could insert instances of the exposure module where the module itself does nothing (module controls all set to zero) except generate a mask to be used as a raster mask by another module. No need for any new development.
You can name those exposure modules, to easily distinguish between them for later use.
1 Like
What did he say?
I think maybe you don’t quite understand how masks work in darktable:
https://elstoc.github.io/dtdocs/darkroom/processing-modules-and-pixelpipe/the-anatomy-of-a-module/
Never used it, but for curiosity.