You need to compile the code in the pull request.
Too much C code for that.
You need to compile the code in the pull request.
Too much C code for that.
Mica I was going to try it but I am not that skilled at Git. I am set up to build the main dt git and I understand how to checkout a branch but this is posted on a personal dt git repo I believe…Would I clone that and create a separate install or is there a quicker way to work with the proposed code…any tips appreciated. Thanks in advance
Would this help?
Way beyond my scope. Will wait for 4.0.0
I started to read something like that…I just wanted to be sure what I did was local and did not mess up my current files…thanks for the reference… Can’t seem to get the syntax right for the first step…
$ git fetch origin pull/7820/head:thiscanbeaynthingyouwant should do the trick. The
BRANCHNAME is a local thing.
The entire build procedure should be something like this
$ git clone git://github.com/darktable-org/darktable darktable-sigmoid # Folder name is optional $ cd darktable-sigmoid $ git fetch origin pull/7820/head:sigmoid $ git checkout sigmoid $ mkdir build && cd build $ cmake -DCMAKE_BUILD_TYPE=Release .. # For Unix like $ cmake -G "MSYS Makefiles" -DCMAKE_BUILD_TYPE=Release .. # For Windows $ make -j4 install # Or whatever number of threads you want to use
My very first impressions after getting to know and playing with sigmoid for about an hour and not knowing if this module comes with a certain required workflow:
The above comments are based on very basic edits (wb + exposure only) and then comparing sigmoid with the filmic rgb and the tone curve. I do not use the base curve so I skipped checking against that one.
Just from my point of view I would most likely not be using this module. Not because it isn’t any good (which my above “tests” will not really show if that would be the case), but because I like/need the finer control that the other modules offer. People that want quick edits/results might be rather happy with this one, though.
Images I used for this session (all found here at Pixls):
I did some very limited testing as well and would agree. Decent results for very little effort. For me I notice the sensitive aspect as well. Also for me it seems to really crush the blacks I had to add exposure and black compensation. I just tried it on a couple of shots. For a first attempt not too bad. With some finer control without adding too much complexity it might have its audience…
If you install github’s command-line tool (GitHub - cli/cli: GitHub’s official command line tool), it’s even easier:
gh pr checkout 7820
Welcome to the forum!
May I ask what the reasoning is for using a sigmoid function? Is it S-curve enough to just try how it looks?
The results you show look good. What are the differences between log-logistic and weibull? Does it work in a component color-model, if so which one?
Nice idea and prototype, I like the out-of-the box thinking here Definitely going to give a try! Also love the images in this post.
Thank you @PhotoPhysicsGuy!
I wrote a more detailed motivation for the use of these sigmoids over at Github, see the first post. But in short, they model at least the base curve presets surprisingly well and offer a straight forward parameterization that does pretty much exactly what you would expect.
Both work on the separate RGB components of the chosen working profile. The difference is in their shape which is easiest spotted in highlights where Weibull gives more punch. I recommend going back and forth on an image where you expect some highlights to hit pure white.
@Jade_NL and @priort I’m aware of the sensitivity, I left out the soft bounds on purpose, for now, to make it clear how wide range it handles without breaking down. Softbounds will improve the step size and make it less sensitive. I have also been thinking about defining the slope at 0.18 instead of the exponent/base, might give a different feeling to the how sensitive it is.
About black point and crushing shadows, could you post an example? My gut feeling is that you should work some more with the tone equalizer, graduated filter, or masked exposure changes to get that to work
And those are some nice test images, especially the Noctilucent clouds proved challenging!
sigmoid, log-logistic, contrast = 1.61
graduated density (for lifting the lower part of the image)
tone equalizer, custom
denoise (profiled), chroma only
white balance, 5413 K, bluer!
[Play Raw] Amulree Kirk
sigmoid, contrast = 2.65
Kingfisher: Softproof failure
sigmoid, contrast = 2.44
The last picture seems to have input color issues with the blue channel, those issues remain sadly so no point in posting the result from that.
Just for the record, RawTherapee also uses a contrast-based sigmoid function for dual-demosaic and CaptureSharpening to blend between the two demosaicers and the before/after of CaptureSharpening…
@jandren: I’m about to go off-line for the day but I do have one request: Can you post your sidecars for the Noctilucent clouds, Amulree Kirk and Kingfisher edit?
I’m curious about what else, besides the sigmoid changes, needed to be done to your edits to get the above results. A quick look at the Kingfisher for example makes me wonder why I immediately noticed a (too) saturated background (the reds) when upping the sigmoid slider somewhat, which I do not see in yours.
Anyway, I’m off for now. Thanks for taking the time and effort to put this forward!
Thanks my initial problem was I thought origin was a place holder not the name of the command…thanks for your info…I managed in the end to stumble through it although I should have done it a bit differently I did manage to get it done…
@priort Glad you got it working. We could tell you what to do exactly, but the best learning is done by trial and error. That and I have an unreliable memory.
I agree. Sidecars are a good learning tool. It is good practice to include them.
Yes! Thank you and exactly what I was looking for. The ensuing discussion with aurelien as well. Sorry for not immediately checking out that link.
Per-channel math will lead to color shifts as the ratios of primary colors will get messed up…but that is being adressed in the github discussion as well.
There truly is a discussion to be had about the differences of a output look transform, a tone mapping operation (plus a seperate gamut mapping operation) and what control a user might want to have in which case and, more importantly, where in the pipeline. I think/hope that filmic is rather future proof with regards to upcoming (but when?) HDR10 output look-transforms.
Up until then your edits look fantastic on a calibrated sRGB monitor, so there is hope that these curves might somehow find their way into an appropriate module…even if it’s called ‘SDR-output transforms’.
I am looking forward to the ensuing discussions, also with regards to whether a pipeline should be more clear about where scence-referred ends and display referred starts and where certain creative decisions should and can live. (i.e. does one create prints from scene-referred data or from display referred?! both?)
I am sure this will be a hot topic!
IDEA: this module acts as initial guess for the filmic module. If the polynomial in filmic is a more general and more flexible tool but can replicate the sigmoid from here… Why not start with a sigmoid, transfer parameters to filmic and open that one up for fine tuning and separation of rendering intent and scene referred adjustment?
Really like it from a first test ! To be honest i lost a little bit of enthusiasm with filmic and Color calibration etc in the latest versions. I know they are very good technically, but when the defaults don’t work it feels like work to make the image I want.
This module gives this nice simple feeling to start with. It’s good to know that there are all possibilities to fine tune an image, but your module brought back the fun that was lost with dt 3.2 onwards.
You know ART ? It’s probably better suited for you.
And don’t get offended by Aurélien’s proposal. We (the devs) have made a lot of efforts those last years to propose easier and more polished modules and UI. The introduction of a “basic module” and in 3.6 you’ll have a basic group where the simple controls for most dev work will be present. The layout of the modules have been simplified and come with ready-to-use presets. All this is documented of course and many hints have been added. If filmic & co are too complex for you we’ve kept the old base curve and dartkable propose a workflows based on it.
But darktable won’t go the route of one button to do the job. I’m not saying that’s bad goal, I’m just saying that it is not darktable. And so, if you’re looking for something very simple, just some buttons and happy with playing with modules with almost no control and where the rendering/algorithm is hard coded then you don’t want to use darktable.