Nice, thanks for the feedback! Of course I will never have to read this part of the manual again 
Thanks again for the great work!
Two updates from ‘the other thread’:
can not download- not found error.
It’s been replaced, please check directly on the other thread.
Thank you.
I think there is an issue with AgX module if it is dublicated or copied.
The 2nd instance of the module does not fully become visible and as mouse arrow moves vertically down the sliders and sections become visible and moving up they disappear. Even the primary tab initially is not visible. Basically the 2nd instance UI is very unstable. It seems it is happening in Linux as well as osx-x86. I wanted to posted here if others can confirm it before report it.
I’ll check, but basically you shouldn’t use it twice. 
I wanted to see if I could use it locally with mask.
1 Like
Is there any reason why you wouldn’t use it twice with complimentary masks? Say to process the sky with a different curve to the land?
It may be hard to ensure a smooth transition
OK. I was just curtious .
Although I experienced this once on my machine, I cannot reproduce it now with the current master, or with the version I was at before this. Xorg or Wayland? (I’m on Wayland.) 2 or 3 tabs (plugins/darkroom/agx/enable_curve_tab set to true or false)?
Edit: I managed to reproduce this on a development branch, which I did not update from master recently. Once I did that, the issue was gone. What build are you using?
5.3.0+920~gb7b7b65c19-dirty for macOS>=10.14 from @MStraeten
and
5.3.0+930~g1c7eebfbd9 nightly for linux running inside virtualbox for osx.
both exhibit the same problem.
The custom macOS build is based on a 21 November master; the Linux build is based on code from 24 November. Let’s see if it goes away with the next build.
I tried building 1c7eebfbd9 locally, it showed no problem.
I just updated my linux nightly to 5.3.0+937~g323ff0234d and no problem. for osx will wait for next @MStraeten release.
Having problem in both versions blind sited me of trying to update at least the linux version for checking.
Thank you, I guess the issue was limited to 930 versions.
We’ll see. You had the issue with 1c7eebfbd9, I did not, so there may be further differences.
Don’t forget that the tonemapper modules do two things:
- they apply a tone curve, adapted to the input (in this respect, they are no different from tone equaliser), and
- they apply a log transform to the data to switch from scene-referred to display-referred data.
The output data from a masked copy would be a mix of scene-referred and display-referred (log-transformed) data. The second instance of such a module has no way of knowing which pixels already have the log transform applied. Result: you can end up with a mix of scene-referred pixels, display-referred pixels, and display-referred pixels with an extra log transform.
The same goes for the tone-mapping part of those modules of course, but it also happens with e.g. tone equaliser. That is not an issue.
If you want to do masked tone mapping, there are better tools for that (tone equaliser, for instance). With those, you can also get artifacts, of course, but you can control them.
So if you used one mask, inverted between the two instances, would the input and output format issues fundamentally break this use case, or is it just brittle?
I think from a conceptual perspective things break with half-transparent pixels. You could probably do it but I guess your time is better invested in learning a more robust solution for the problem you are trying to solve.