Would it be possible to include this feature as a standard module or preference in DT? It does indeed seem brilliant.
Well if you run the script you have it… essentially as a module… its really a compilation of settings of modules but with the ability to fire off some auto pickers… I need to learn so lua to fix and tweak it But is now seems broken by the recent changes in the master… it should work find in 4.2
There are a whole range of scripts you can run… the RLoutput sharpening actually does a nice job
I am using the latest weekly build 4.3.0.287 on Windows and I no longer can see the script manager. It used to be bottom left corner of one of the views. Any idea what might explain this?
Mine had disappeared, too. What I did was first confirmed the scripts were still there in the %localappdata%\darktable\lua directory. The with darktable not running, I changed this line in %localappdata%\darktable\darktablerc
from:
lua/_scripts_install/initialized=TRUE
to:
lua/_scripts_install/initialized=FALSE
…I think that’s the correct line! 
Then restart darktable and the script manager will show up, assuming you’ve not disabled it in preferences.
1 Like
I agree, and I wonder how well this change has been thought through. I think a proposed change like this could benefit from an airing here in the forum before actually making it. However @Terry , I’m just curious how much time you allow for an edit! - I mean it doesn’t take long to go into WB and set “as shot” in two clicks.
It’s not practical to have these discussions on two separate forums (github is the place for discussing such things), though it’s great to have so many people testing master. The more people using master the better the chance of spotting issues before new versions are released.
Edit: Of course there’s nothing really stopping new feature proposals from being discussed here, but if you want to be sure the developers will participate, github is the place.
Did you see the post where I realised (thanks @priort ) that you can set the new workflow options to “none”, which seems to bring back legacy WB, then create a style or auto-applied preset to turn on filmic or sigmoid? As pointed out to me, one does lose out on the exposure +0.7 default and the filmic auto-adjust but for me it works fine as I always adjust all these anyway.
I will give this a try. I am just a little surprised that we have had an option taken away from us and I have not yet understood why that had to be done. If it is a maintenance or coding issue fair enough, but what I like about DT is that usually the user is given the freedom to choose what suits them and this change has restricted that for a reason I don’t understand. I will just have to modify my workflow a little.
Considering I edit hundreds or even thousands of photos the extra clicks begin to add up and creating a style will not solve the problem. I would much rather the two extra clicks be the few occasions that I want to use the CC module. It just seems that we have lost the freedom of choice and gained nothing that wasn’t already there.
3 Likes
I think its time to let it go…set the workflow to none…You get legacy WB with the camera data …ie as shot. If you want sigmoid or filmic just create an auto preset to apply it… its rare that nobody touches it. Same for sigmoid if that is the choice and finally you could make a style that toggles sigmoid and filmic or the reverse depending on which one you start with… The same for exposure… if you want the default 0.7 EV or whatever auto preset that too…Do it once and then no extra clicks… I don’t think it was a hugely necessary change but so be it… if setting it to none wouldn’t give you legacy wb then that would be a pain…
I will definitely let it go if it gets implemented in the stable release and find a new workflow that works for me. I just grumble a little so the developers can realise not everyone likes the change and then hopefully they will consider if the change is needed. The current scene referred workflow was always there in 4.2 by default, but now it is being forced onto me in its totality. I will try your suggestion and put up with what ever change happens.
1 Like
Works fine.
Just a remark, the issue for this change was opened by me on Nov 15th:
The implementation merged on Jan 2nd.
So 1.5 month of discussion possible. The developers take decision on what is discussed, no magic.
1 Like
A lot of users - non devs - learn about those changes after they have been merged. So some kind of ‘what?!’ reaction is to be expected .
I encounter images quiet often where the modern setting just doesn’t work. Now i recognize it and i can set and adjust my defaults , so no problem for me.
But it does increase the amount of ‘default rendering’ images where less-technical users would go “what is DT doing ?!”
I was under the impression that the first impression was important to the devs (that’s why the modern flow had ro be chosen before , and the ‘clipped’ HLR method was the default for a long time ).
But i haven’t read the discussion, nor do I care enough to make a big deal about it now :). I do expect a lot of newer users (with Sony cameras / sensors ) going to ask what’s wrong with skin tones of the image was shot with ‘indoor’ lighting (or something just very far removed from the daylight reference ).
Those must be told to fix the white balance 'to be more correct ’ in the WB module , and then reset CC to as shot and ignore the warnings about double white balance the modules then give.
What i dont understand , is that the cam16 code in rawtherapee expects 'a more of less correct white balance ’ and recommends setting the WB to temperature-correlation auto mode first.
While DT sets it to a fixed (D65?) White balance
Pascal, there are two kinds of changes:
- deeply technical, where users have no chance of contributing to the discussion; may not even be directly visible to users (like refactoring and optimisation);
- changes directly visible for / impacting users (even if it’s a technical change).
I think if you want to make a change to make the tool easier to use for users, discussing it only on GitHub is not the right choice, as most users are not there. Discussing the technical details can and should take place there
I think the way sigmoid 1 2 or color calibration was discussed here, even when things went into the details, was very useful. I understand that it’s a pain to have separate discussion threads running.
2 Likes
This idea that merging is somehow an irrevocable process is problematic for me and it’s not the first time it’s been suggested or implied. I am a regular github user (a “dev” for want of a better term). I monitor the issues and the pull requests on a fairly regular basis. I don’t always have time to examine and consider the implications of every change. Sometimes the impact of a change isn’t felt until it’s used or some “aha” moment is encountered. Sometimes I think of something but I don’t have time to discuss/test and sometimes I don’t even have time to read beyond the first paragraph. Ideas that seem good at first glance don’t necessarily pass muster after serious consideration.
There is no length of time after which mistakes can no longer be reverted.
Nothing irrevocable, we can adjust when needed and this has already been done numerous time. We had comments about simplifying the workflow setting, this has been done. There is corner cases not foreseen, no problem we can adjust when we we’ll have a clear idea of the blocking problem. Reading latest comment I’m still not sure we have blocking issues, especially with:
But sure I already said it, I’m not for reverting except when it is plain wrong. We need to move forward.
2 Likes
Sometimes moving forward means realising that we have not improved things and that reverting to a previous state is the best (least bad) approach. It feels like you are saying that only major bugs should cause us to reconsider a decision already made. Anyway we’ve had this discussion before about other things so I’ll leave it there.
1 Like
@Terry I posted this on this thread. If the change had a negative impact, start an Issue on GitHub. Explain your case with details. There is no need provide a solution (eg Revert!). But grumbling (your words) here is not an effective way to provide feedback and start a change. There is plenty of time before 4.4, so plenty of time to address issues.
I searched on GitHub and I don’t see an Issue for this.
1 Like
That looks good! Assuming the WB module responds to initialization by reverting to as shot, that would solve any remaining issues for me. Great 