@g-man I’m hesitant to open an issue on Github for this, as @priort pointed out if the workflow preference is set to ‘none’ it defaults to legacy wb, then I can create a preset to auto apply sigmoid or filmic. The only issue is that this breaks filmic rgb’s normal auto-adjust function, but I usually readjust after adjusting exposure anyway. Besides, I prefer sigmoid most of the time, so it’s a non-issue for me really…
I could still go ahead with a Github issue though if anyone else feels it’s an issue.
You may still lose something from using filmic and exposure presets because the filmic workflow sets defaults for those modules using the exif exposure compensation value, and you won’t get that with presets. Probably more an issue for filmic than for exposure (which has the “compensate” checkbox).
I have just downloaded the latest weekly 4.3 build for Windows. I too would have to say that the new changes forcing the user to select an auto-apply pixel workflow default is going to have a negative impact on my standard workflow. I usually get good WB out of camera and have found the color calibration module unnecessary for most of my images. However, I liked the other scenic refer modules such as filmic. So having chromatic adaption separate to the rest of the pixel pipeline defaults would be beneficial to me. Since WB gives out scene-referred output I don’t understand why we need to be forced to use CC module if we want to use the scene-referred workflow.
I presume I will solve my problem by creating a picture style. I hope that will work for me.
I would agree with opening a Github issue as this change is a problem for my workflow. Also, creating a style does not work as it can not set the white balance to as shot in the camera. So this change is forcing extra work on me to achieve the results I automatically achieved before.
Just set it to none and add things other than wb with your style…
There is also another way around it but I think some of the recent changes may have broken this script. I did mention it to Ulrich who graciously shared it…
His initial workflow script was genius look at what you could set and control without styles…
And it would run autoexposure at whatever default % you set exposure. It would set the relative white and black in filmic and it would run the autopickers in the tone eq mask so it was ready to adjust without this step.
Also you could apply default chroma and saturation lens corrections and denoise and tweak what wb settings you wanted…
If he can figure out how the latest changes broke it and fix it … it can really help…its like having a module to set your preprocessing defaults…
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.
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.
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.
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
