Going back to this, I think it might be useful to paint a grayscale picture of both max(RGB) and min(RGB) from the state of the pipeline where the offset has just been applied (and outset has not been applied yet). If one sees anything strange going on with the min and max when pushing the offset slider, there might be the reason… I’m not sure if this is what happens here, but it is worth investigating.
I think the errors like shown above might be caused by applying a different offset for each pixel based on the luma. This does not directly explain anything as such but might where the errors arise.
An idea for limiting the effect of offset for the higher values would be replacing the offset with a curve that looks something like this:
I’m not certain this would work or produce the desired result, but at least I have often done something like this in the rgb curve module to get a matte look or just lift the shadows a bit. And I believe this wouldn’t cause similar issues as above. Results depend largely on the kind of function used.
I’ll be off the keyboard for the weekend, so just dumping my brain here… Following the thread with interest, love to see the results people have been getting here. @kofa I love to see the experiments and the learning, this was just one important thing I had to point out, as I believe it is important to watch out for. Absolutely no offence intended here.
I found old scripts for fitting the sigmoid params to a given curve. Noticed the same thing that the middle grey shifts a bit. I feel I have still a bug hiding somewhere in the script, so I will get back with closely matching sigmoid params next week hopefully.
An exact match won’t be possible, though, but it’s still interesting to test.
It’s pretty evident from the math that AgX will not preserve middle gray as an invariant: slope has 0.0 as the invariant point, offset has 1.0.
The approach of AgX is mathematically completely different from filmic/sigmoid:
in AgX you set the parameters of the tone curve;
in filmic/sigmoid you set constraints to which a tone curve is fitted (and the invariance of middle gray is one of those constraints).
So that will require adjustments in the whole workflow (as stated in @kofa 's posts, you have to limit the dynamic range of the image before AgX, and you get shifts in middle gray).
Given that, is it worth-while to modify the behaviour of offset (with the complications it causes)?
And is it useful to keep the saturation adjustment in AgX?
I still remember the impact filmic had on the workflow, it took some time to adapt to its properties. Sigmoid caused less of a shock, as the basic workflow did not need to change compared to using filmic.
Not really. It’s even much simpler.
You can adapt the tone mapper more precisely to the given scene.
You also have to do this with filmic or Sigmoid, I don’t see any difference between these two and AgX in this respect.
With regard to the visual adjustment of the photo, medium gray is only a rough orientation of where the main subject of the scene should be because the contrasts should be most pleasant there. This can vary depending on the interpretation of the scene. Sometimes you have to increase the contrasts in general to be able to better assess where you actually need them.
After processing some photos, I noticed that the saturation provides a nice additional contrast.
AgX is not making any major changes that will alter the workflow.
Besides, nobody has to be forced to use it. Filmic and Sigmoid will still be there.
I didn’t mean to imply that, nor that AgX would not be a good addition. I was more thinking of the optimal use of AgX in the whole workflow, and not using it as just a drop-in replacement for filmic/sigmoid.
That’s also why I noted the need to adjust dynamic range to a specific range. In filmic, you set the range inside the module, and I use tone equaliser more to control contrast in certain zones, but I don’t have to do that. Case in point: I’m playing with microphotos at the moment, and there the dynamic range is very low. So low that I have to use tone equaliser to expand the dynamic range even with filmic set the the minimum range (sigmoid is similar in that respect).
As for saturation: if you have to tinker with it in e.g. colour balance RGB anyway, does the saturation control in AgX add something to that? If not, the simpler the tool, the better.
Well, the way it behaves with neutral gray will have an impact on workflow, in the way I think about the editing. It may not change the modules used in combination with it, but that’s a minor point compared to the mental process.
That doesn’t mean the workflow will be better (or worse) , just different.
you might run it with an in-memory library via terminal: /Volumes/darktable/darktable.app/Contents/MacOS/darktable --library :memory:
or use a separate config directory: /Volumes/darktable/darktable.app/Contents/MacOS/darktable --configdir ~/.config/darktable_test
both packages are unsigned, you might need to allow execution via terminal: " xattr -c <path/to/application.app> "
That would indeed not be a wise decision. I assume that if AgX is adopted, it will only be offered as another alternative, as has been the case so far with filmic and sigmoid.
I would definitely prefer it as an addition rather than a replacement for existing tone mappers.
This would give you the opportunity to test different approaches and choose the right one for you.
Here is a very flat scene that can be wonderfully extended with slope and offset.
Excellent and thank you - it does appear to launch.
It advises on start up that the DB structure will be updated. Will those changes prevent me from me from returning to DT 5.0.1(On ubuntu 24.04 if relevant)?
yes, you need to run darktable with a temporary config directory and maybe disable writing xmps if you process already processed raw files.
there’s no way back to 5.0.1 after the database updates except using a backup.
The three horizontal sections are masked instances of Filmic (top), AgX (middle) and Sigmoid (bottom), with the grey scale underneath. They should load with the attached .png and .xmp files
I’m trying to make black and white exposure offsets available, by switching from the fixed polynomial to the sigmoid function from Troy Sobotka’s original Python script, but something’s really weird. Most probably some silly oversight, but I’m too tired to continue today. Will hopefully catch it later today, in the morning.
OK, so there’s a new version out, with adjustable parameters to set the slope of the linear section, and various settings for the toe and shoulder. However, the most important one is relative black and white exposure – so you’ll probably have to fiddle less with the slope and the offset.
The contrast has changed a bit. I don’t know exactly what parameters the polynomial was fit; I used the ones in Troy’s scripts.
I’ve noticed after building the images that I left some debug prints enabled, sorry about that. Also, there’s a checkbox to toggle between the original (non-parameterised) polynomial and the one I ported from Troy Sobotka’s scripts. This is enabled by default, but for some reason not visible on the UI (it shows up unchecked, but it’s on). Just click it twice to get things consistent; I’ll ask the devs later how to get around that. The code is still unoptimised, and will remain so until the features are complete. I have not had time for the guard rails or the matrix rotation/inset controls, sorry. Also, in the presets, the hue recovery may be set inconsistently. I have a hard time following the maths, even though it’s basic; I have not had to do any of that in the past decades.
I’ve rolled back the gradually tapering off of the offset; hopefully you won’t need it now anyway. I’ve also removed the toggle to switch between the ‘outset’ matrices; the code now uses the ‘proper inverse’.
Please let me know about your experiences with the new build (I only tested on one image, and a grey ramp…). Thanks!
Thanks, @flannelhead , your tip regarding the tags was correct – the Windows version now has the proper version number. @MStraeten : I haven’t yet thanked you for your effort in providing a MacOS build. If you have time for another, please update your package.
I’m sure that I’m in the minority regarding my impression of the new build. However, I’m disappointed that this has gone from a simple AgX module to one that is so much more complex.
Of course I might be missing something here but as it stands now it’s just too overwhelming for me to understand. Perhaps someone could explain or show the workflow regarding the new build.
you might run it with an in-memory library via terminal: /Volumes/darktable/darktable.app/Contents/MacOS/darktable --library :memory:
or use a separate config directory: /Volumes/darktable/darktable.app/Contents/MacOS/darktable --configdir ~/.config/darktable_test
both packages are unsigned, you might need to allow execution via terminal: " xattr -c <path/to/application.app> "
