Sounds good! I have used the prototype for testing purpose on my side and loved it!
That looks very promising. Perhaps you can improve the GUI and use some kind of curve. (I’m not sure if it would be really useful.)
Maybe devs could listen to seasoned professional photographers sometimes.
For me it always feels strange when you criticise “the devs”, as you are the second most active darktable dev of the last year.
But you are right, the dev should listen to the users. I have this issues open for a very long time now, could you please fix them?
10927 Feature Add GPS Exif.GPSInfo.GPSImgDirection to the image information panel and the Lua API 21.02.2016
10363 Feature Add a Lua Event that the image in the slideshow has changed 10.03.2015
10362 Feature Add Lua fuctions to improve the Map view 10.03.2015
10361 Feature Set set/get colors with a colorpicker in the preferences with LUA 10.03.2015
10250 Feature Export map as image in a higher resolution than the screen 26.12.2014
9902 Feature New LUA event/funktion: to open/close panels 12.04.2014
9901 Feature New LUA event: selecting/deselecting an image in lighttable mode 12.04.2014
9840 Feature Automatically rearrange the interface for smaller screen sizes 08.07.2015
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.
Thank you for your work Aurelien! A simple “shadows slider” like in lightroom would be a killer feature. Can’t wait to test this when I get back home.
The anxious layman question: when does this feature arrive at http://download.opensuse.org/repositories/graphics:/darktable:/master/xUbuntu_18.04/?
@aurelienpierre 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)
Trying to answer myself: when his changes will be merged into darktable-org:master? Is that it?
@aurelienpierre 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 @aurelienpierre 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 @aurelienpierre.
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.
@aurelienpierre, 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.
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?
Please, annoy me.
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.
Aye-aye, sir! There’s a starting point now: https://github.com/darktable-org/darktable/issues/1970. More may follow.