I have seen several requests to reproduce in darktable the tone equalization of ACDSee or the basic blacks/shadows/highlights/white cursors of Lightroom. These users have been disregarded because, apparently, users are stupid and devs know better. (It is FOSS : shut up unless you know how to compile).
It’s yet a very efficient and powerful way to control the lightness, and less cumbersome than the tone curves. Maybe devs could listen to seasoned professional photographers sometimes.
So the tone equalizer allows a better compression of the whites (see the light garland), but crushes less the midtones, and still allows more details recovery in very low-lights. See what happens when we push them both:
The shadows/highlights module turns the bush (right bottom corner) into redish (another gift of the Lab colorspace), and the gaussian masking adds this weird overbaked sharpness that looks very HDR-y, especially on a picture at 135 mm f/2.8. It also adds contrast, which is not what we asked him.
Here, you see it can be a bit damaging for local contrast (aka sharpness feeling) when the channels have harsh settings, so the next step is adapting the laplacian pyramid used in local contrast to apply the tone adjustments on low frequencies, and keep the details/high frequencies untouched.
But, the main advantage of this is you have absolutely no halos artifacts nor weird desaturations because… there is no masking.
Also, it works in scene-referred RGB because I have had enough of the crazy tonemapping Lab nonsense in my life.
I don’t have commit rights in darktable and I didn’t knew how to code in C 4 months ago, so yes, I pulled my fingers out of my a** and 4 months later, I’m the second most active contributor for the whole year. I finally learned C after I understood nobody cares about my feature requests on Redmine (and, as a matter of fact, very few people care about code pull requests as well, so if it weren’t for Pascal, I would have given up). Now, I feel bad for those who don’t have the ressources to do that.
Given that darktable is primarily an image processing software, I spend my time primarily on the color management, then the ergonomics, and finally on peripheric functionnalities. Sadly, I know nothing about Lua, let alone interfacing it with C…
Also, I criticize this habit of answering “my software is not that kind of software”, or “it is not intended to do that”, or just “move away I’m not interested” whenever people suggest something new, because it discourages both contributors and motivated users. It’s one thing to not have time, it’s another one to send people to hell and be defensive about new ideas. The most annoying users have been the most useful when I did filmic, and their feedback have helped me to improve the UI a lot. Nice satisfied users are nice, they give love but they don’t help improve. Annoying ones are better, and we should not disregard them.
@anon41087856 You forgot to add a third category in you user taxonomy: the nice loving user that adds nothing before or during development, but that’s eager to try new things and that, when they arrive, helps building momentum and new test cases with their obsessive use of the new toy (in which I humbly include myself - I guess)
@anon41087856 Thank you for your activity. Although I haven’t got yet time to familiarize myself with filmic and updated color balance I can see that they plus this new module may change my whole workflow.
Thus my question. Do you have a vision what the pipeline should look like in darktable? I have noticed that you have a strong opinions about Lab.
@Tobias, I’ll look at the Lua API changes. @Pascal_Obry has already merged a change to the API, so we’ll need to bump the API version, so we might as well add whatever API changes that are waiting (and that I can figure out how to code :-D) once I clear the lua-scripts PR backlog. If @anon41087856 hadn’t created filmic and modifed color balance I would have been done with the backlog a month ago. Instead I’ve spent way too much time learning to use those modules and achieve some really great results. Thanks @anon41087856.
The problem of “shadows” is how many EVs is that ?
I don’t have strong opinions, Lab just sucks. It was never intended to be a color working space, but only a color description space, used for example as a connexion space for ICC profiles. Do you see any other software using Lab as their default pixel pushing space ? That’s right, nobody does that. So I don’t know what the hype was with Lab at the early stages of dt (maybe it’s because it’s a very large space, or it looks cool to be able to adjust luminance separately from color, or maybe because 50% L means middle grey, when it’s 18% or so in linear spaces), and I guess it didn’t show big issues when cameras had about the same dynamic range as the 8 bits JPG output (so camera raw → JPEG was pretty much straightforward). But now, cameras have almost twice the dynamic range of JPEG, and so does film, thus you have to squeeze the pixels in there and tonemap like crazy, and Lab clearly shows its limits here.
So the pipeline in dt should look like RGB all along. Lab creates more problems than the ones it tries to solve. People tell me they get better results with filmic and color balance than they did before, and are now able to recover easily pictures condemned to garbage before… Well, both work in RGB space. That might be a clue. Also you see above the difference between Lab shadows/highlights and RGB tone equalizer when you push both far away: one behaves, the other fails.
Now, Lab works for things like equalizer and local contrast, although I wonder what XYZ would do there, but that’s about all.
When I’m happy with the algo We will try to not reproduce the mistake done with filmic (merge too soon), but also sort of try a rolling-release approach where new features are added when they have been tested enough, not just once a year (which puts too much pressure around the Christmas hollydays).
The LAB Tone Curve is probably my most used module in DT. I do like manipulation the luminance channel and I also use it for over all color saturation. I can’t tell you how good or bad it is from a technical stand point, but I like the results I get with it.
When you push the L channel hard, you will see weird greyish-blueish desaturation in low-lights. It’s fine for small adjustements, but you don’t assert the reliability of something by using it just slightly.
Thanks for saying this. It is quite common and gets in the way of progress or if anything good discussion. Normally, I try not to stir the pot but I find myself having to apologize to users in a PM for how they were treated to keep them interested and involved. In the end, people are people with all of the flaws.
dt is slowly becoming more accessible and sought after (given the forum activity). I had to wait a long time for a Windows version and I am glad that it exists now. With your help, we will be able to keep the momentum.
If there’s gonna be a poll, I vote Yes for a rolling-release.
I explain my vote.
When you were developing filmic, I started using the dev version (I still get confused with all that github naming), and haven’t noted any instability.
Such version was already workable.
@anon41087856, first, thanks for all the effort you put into that. It’s great to see further progress in darktable. However, I cannot leave the sentence
uncommented, because especially @houz, but others as well, did implement several features on my request/based on my ideas, and he and others discussed about other ideas from me in a positive way as well but unfortunately did not find the time/resources to implement these. Discussion was almost always very positive, and I have the impression that the limiting factor always was the resources.
(K, technically I count to these that are able to compile dt, but I never was able to learn programming in a way that goes beyond some very little lua contributions/fixes in darktable lua addons. I definitely count myself an annoying user, since I do post feature requests – btw, shall I port these from redmine to github?)
Hm, there’s at least Easter to consider, maybe also a Halloween release, and I am sure there are more release opportunities .
If, for some reasons, changes have to be made to the algorithm, the edits you made (and the parameters you set) will not have the same effect on the picture. So, “workable” is not enough, it should be stabilized.
Yes.
The discussion I linked was something that bothered me when I saw it, especially since the request is legitimate, and the implemented feature is an improvement (proof is made here). Devs have to remember that, sometimes, users can teach them how to use the tools they developped. Being a blacksmith does not make you a swordsman, and the other way around. And constantly referring to the documentation is not a solution.
Definitely very true, and I do not say it does not happen what you are describing, you even linked to some evidence (I did not yet read it entirely). It’s just that to me, the way you talk about “the darktable devs” sounds very negative and you are repeating it quite often. Maybe it’s a language thing, I am not a native English speaker, and if you and the other darktable devs are OK, there may not be an issue. It’s not about the facts, it’s only about how I observe your words.
Of course, if you and others can keep the pace, your approach can clearly lead to something really big (and maybe already did), I clearly see the benefits of your approach. I press all my thumbs (that’s what we do where I live to wish luck) that this will happen.
K, will do so in a while. Warning, that’s mainly not the fancy darkroom stuff about pixels and colors, but rather boring lighttable things about databases and asset management. And there are several that are not even in redmine but in my private notes that may be added. Annoying enough?
I’m a dev and the main integrator this year for the 2.6 cycle.
I’m also more leaning toward a rolling release or at least merging more quickly.
Fact is the core dev is small, very small, and earlier we merge better the features are tested. Please I’m not saying that dev should not test, but in the context of dt there is so many way to use a single module that it is quite difficult to be able to catch every little issues.
Also merging more often, reading GitHub PR and commenting makes contributors happy and keep them around as contributor. Of course there is also all those issues to fix and all the new features to implement. This takes time and more we are onboard better dt will aged.
I’m not a professional photographer, I do photography for my leisure but do it with lot of exigence. Then darktable is my tool, as it is yours, and I do think it needs to keep moving.
We will try to not reproduce the mistake done with filmic (merge too soon), but also sort of try a rolling-release approach where new features are added when they have been tested enough, not just once a year (which puts too much pressure around the Christmas hollydays).