New Sigmoid Scene to Display mapping

Software darktable
388

i think we all should be doing more rock climbing :slight_smile:

sorry i lost context over the length of this thread… just to be sure, you’re only applying this in the context of a curve, right? not for other local contrast/tone manipulating things?

and the first step is always to map the rgb channels naively through the curve separately? did you also experiment with mapping some luminance first and reconstruct rgb by ratio?

more specifically i’m thinking about lifting shadows with the local laplacian pyramids. there the whole operation first runs on luminance only, so you don’t really want to map it through each channel separately first. but also it can cause quite nasty colour shifts and oversaturated blacks.

389

I think the last one is both a lovely image and a beautiful edit. Beautiful subtle greens and gradations in the shadows. There’s moooood.

Other than that I’m not sure what you’re up to (I’m not a programmer). :slight_smile:

390

The edits are nice but if you had included the original images to compare it would have demonstrated the module better.

I am also not a mathematician like @mikae1 so can appreciate the effects and effort.

391

did you see this? seems very similar in spirit, only that it employs the derivative of the curve. seems to me that it would always result in smooth transitions?

1 Like
392

No, I haven’t! Thanks for sharing.

Similar in spirit but still a bit different, interesting! I have been considering this approach but didn’t like it as there was no way to formulate it as robustly as I liked it to be. It looks pretty nice though. I think the biggest difference is how all dots desaturate at the same time in this while it desaturates from the middle and out for a per channel approach (uncomment line 129 to see that).

He also has a nice little soft clip, on rows 133 - 135, comment those out and uncomment 139 to see where clipping happens.

I need to see if Björn wants to hang out for a chat, fun to see what other Swedes are up to!

About that climbing session of yours @hanatos, absolutely up for that! Would be a joy to do some :smiley: Any particular place you had liked to go?

About your questions from before Christmas that I still haven’t answered to.
I apply this correction on the per-channel mapped values, or I use the per-channel tone map as a guide for luminance and saturation. Whatever way you want to view it.

I have experimented with RGB ratios in similar ways to the link you shared and haven’t been happy with it so far. I still do not know how to guarantee the mapped values to stay within the display gamut and I thus discarded it for now.

You could use a similar approach to hue preservation when doing local laplacians as long as colors already are mapped to within that working gamut. You could actually relax the constraints a bit even, I force the out values to be smaller than the max per-channel mapped and larger than the smallest per-channel mapped. Employing a correction like this in scene space could drop that requirement.
That loser requirement makes it fine to use a gradient-based method as Björn does though as we do not have to worry about clipping bright values. I guess trying both and seeing how it behaves is the proper way to approach that larger topic.

@mikae1 and @Rajkhand thanks for the nice comments about the pictures. I do understand that it might be hard to judge the technical aspect of it. I will come back with some practical examples once I polished and pushed the latest code I worked on.

3 Likes
393

I would like to see this module in the mainstream, as a user choice alternative to filmic.

I am sure filmic can do lots of things and solve most of my use cases where the results don’t seem so good, but it is not easy to master.

For many things, in a correctly exposed image and when the main subject is in midtone, filmic is great.

But it compresses the higlights (it has to do it) and shadows, and then you have to fight against it trying to expand shadows and lights, and I cannot get sometimes natural looks.
When you have clipped channels in the highlights things get worse, it gets quite difficult to recover them and give them a natural look.

I have tried this sigmoid module and in this cases it gives me better (more easy to get) results, it seems more similar to the way we worked in LR or other software.

But having to use two DT installations with separate databases is not an option, it is good for trying and testing, but not for a dayly basis, to use it in photos you may need it in your collection.

So is there a proposal to add it that we can vote for?

May you add it as an optional module or user installable module to DT?

I have seen in github some request in the same sense, but I am not sure if there is a “oficial” proposal where general users could vote.

3 Likes
394

An example image that demonstrates this would help focus the discussion.

395

Well, may be this is not the place to discuss whether sigmoid is better for some cases than filmic or not.

If you are here is because you have liked sigmoid and want to give it a try.

I have said that probably the problem with filmic is in my own, not being proficient enough in using it.
Anyway if the OP wants me to try to upload some image with sigmoid and filmic, I can seek for some.

Its not only me who is having problems with higlights using filmic, I can provide a link to other spanish forum where many of us have tried to get a natural look and could not (with filmic)
The image is not mine, so I will just put the link to the topic where there is a link to download.

But perhaps it is better to open a separate thread with a similar images and see what we can get with filmic and what we can get with sigmoid, isn’t it?
Quitar el cielo morado - Darktable en general - darktable en español

If you think it would be of help, I can seek for my own example and create a thread for it.
It will take me a bit to seek for a good example and compare filmic and sigmoid (I have to upgrade sigmoid install too).

But it does not matter if it is due to my inexperience with filmic or sigmoid being really superior to some images.
The fact is that there is people that likes it and finds it useful to some kind of images and easier to use than filmic.

So if it can be added to the mainstream it would be great to have options, in the same way we have options for other tasks.

It has been argued that it can create confusion, but DT has a lot of confusing modules some of them obsolete, others repetitive… having options is great.
Just don’t activate it for all users or don’t put it in general scene referred modules collection, but in alternative modules or something like that.

Even if other modules work better with filmic (color calibration or other modern modules that were developed by Aurelien and are great) it is the user option to see if it does not one to use them or accepts the results obtained.

Sigmoid is adapted to the new scene workflow: converts from an unconstrained “linear” RGB scene referred space to the constrained non linear RGB screen output, son there is no reason to discriminate it, it adapts to the new path in DT.
The reason is just a matter of taste and jugding results and that is the work of the end user.

396

I am now in Darktable 3.8.

Sigmoid executable seems to be 3.6 (at least for windows).
But the link on github in @jandren place does not work.
Any chance of being upgraded soon?

I had it installed but unistalled when upgrading to 3.8.

I don’t remember where I get the executable for windows fro, I cannot find it anywhere now.

(I know, I could compile it myself, but no I can’t as I don’t know how and doing it for windows requires quite a lot tools I don’t have and do not master).

397

Looks like it has not been worked on in a year at least from the link in original post…so I wouldn’t hold my breath. Also I don’t think there has been any recent discussion about it being merged.

image
image1668×349 23.6 KB

1 Like
398

IIRC this touches many aspects of dt infrastructure. Should there be one module housing all display-transforms or many modules? What qualifies or disqualifies a specific disp-trans? Should look-transforms and display-transforms be seperate (most likely yes) but linked in terms of place in the pipeline (also most likely yes, but how)?
I don’t think this is up to Jakob.

399

Addinng more info to @priort’s answer:

@TurboGit Sorry didn’t keep a close eye on this branch during the fall as I tried to hunt down a solution to merge elsewhere and then took a break for other things. I had preferred to not integrate it in filmic as filmic is making several assumptions about white and black points which aren’t needed in this module as it is defined for infinity. So it’s essentially not compatible with filmic.

Link: [WIP] sigmoid tone mapping module by jandren · Pull Request #7820 · darktable-org/darktable · GitHub

@ariznaf Anyway, there are works in parallel going on about recovering clipped highlights, check this thread: Guiding laplacians to restore clipped highlights - #70 by Juha_Lintula
(it starts with a Aurelien’s new method and Jens-Hanno presents another method that he was working at the same time).

Jens-Hanno’s PR: [WIP] Segmentation based highlights recovery for bayer sensors by jenshannoschwalm · Pull Request #10716 · darktable-org/darktable · GitHub
Aurelien’s PR: Highlights reconstruction : introduce new method by aurelienpierre · Pull Request #10711 · darktable-org/darktable · GitHub

1 Like
400

Why just one for display transform specifically?
We have lots for sharpening for example or to do BN conversions…
some people prefer one others prefer other module, even if it is technically superior.

Aurelien has recently provided the diffuse and sharpen module, with sharpening profiles, and we have equalizer from it too used for sharpening.

Don’t take me wrong.
I appreciate Aurelien’s work a lot, and apprecite filmic.

I like the aspect it provides to many photographs when important subject are midtones and the lights are not clipped.

I know it can be used to recover lights and even it has some thing to do with noise but could not get it to good work, my fault, I am sure.

Sigmoid does a good job (I don’t know if better or worse than filmic or in which cases it does it well or not) with a quite simple interface and controls.

I agree with @jandren that for the end user concentrating in one aspect of the photo at a time is much easier: do just one thing and do it well.

Even if there are collateral effects, may be easier to solve them later than fighting against all in one point.

I know there are technical reasons that Aurelien has explained and that many aspects are related, ando that is why he put many things in one place, as technically it is a superior solution.

But sometimes perfection and convenience don’t let you walk the same path.

I prefer to keep it simple and something that I can manage and understand to some extend.

401

I think one answer is that many of the modules are now designed to work together with assumptions or actions that take into account the properties of each. So its not a simple as just adding in another module that is not designed for that ecosystem. That might actually impair the performance of the other modules. If it was simply an equation implemented the same way as filmic I don’t think there would be an issue but from what @jandren explained it is not like this.

402

May be official modules work together best, but that is not the unique path or the unique criteria to take into account.

In order to keep modules working all modules should adjust to the current workflow, using floating point RGB, linear, nonbounded model for the editing modulles, and a final conversion to screen.

May be some modules are technically superior and work better with each other.

But a final conversion to screen with other curve won’t hurt or make the workflow invalid, as can be seen with the results given in this thread.

If everybody uses the same modules and the same tools every body is going to have the same look.

Having options (even if they are not of the taste of many) is not bad, as long as that option is consistent and provides good results.

With LR you have few options, you have to develope the photo in the way Adobe thinks it should be done.
That is why people need to do a preliminary work in LR and then go to PS (whre you have many options from many vendors and users) to get the look they want in their photos.

2 Likes
403

I find the 3.8 filmic much easier to use with its new default settings. Have you tried it?

2 Likes
404

Contrary to diffuse/sharpen for example, you apply the transform to display space once per rendering intent whereas diffuse/sharpen you can put it at different places in the pipe with multiple instances either in scene-referred space and/or display-referred (I think).
If you mean why one should be bundling display-transforms (plural) into one module: maintenance and backwards compatibility were the reasons if I recall, please someone correct me if I am wrong.

I wholeheartedly agree. I would exchange your curve with concept though, but I agree.

I also 100% agree with this but feel that this is a different argument. IMHO There is a difference between:
“I think Filmic isn’t nice to handle - Oh, now it’s better!”
and
“I want a display-transform that does yada-yada - Ah, Filmic was never designed to do this like that!”

1 Like
405

Yes it is, and I have tried. It keeps giving very good results in most of my photos.
But that is not the question.
It keeps being difficult (at least for me and I am not the only one) to have good results in highlights when you want to dramitize sky, for example.

There is an alternative that is easier to grasp and a programmer that has provided an alternative.

It would be great to be able to opt for one path or the other.

But if @jandren has abandoned the project there is no point in continue talking about integrating it in DT mainstream.

I understand the precautions main developers have about integrating other modules that have great impact.

May be there is a way to add the modules as external plugins (that would be great) and thus is the user who decides.

And if there is no easy plugin mechanism, alternative modules like this could be provided in a separate tab named alternatives or third party.

So it would be clear that that modules are not completly endorsed by the main developers and be the responsability of the author and the user that wants to try them.

It would be enough to test that that modules keep up to a minimum standard and do not break completlly the workflow.

It would be a way to attract new developers that would begin to develope alternative modules that can be tried by people easily.

406

I was meaning alternate scene to display conversion algorithms, not meaning that you could use several modules of that class.
Of course you have to opt for filmic or sigmoid in a given photo.

Sorry for my english, I don not practice it enough to keep it fluent.

1 Like
407

Nono, my bad!

That would brake the saved status of an image if you do not have the plugin.