I started cleanups and speedups for Local Lab build. In case of interest you can follow this thread.
It will take a while but the first results are promising especially when using large spots and zooming in to 100% or using 100% detail windows (example).
@gaaned92 Please don’t make builds of this branch before it’s completed as I improve tool by tool and the tools which are not yet improved will crash.
I am extremely impressed with the progress that Local lab has made, it really adds so much functionality to RawTherapee, and reduces the need to use other software.
It seems very useable now, are there plans to incorporate it into the main build so that more people can benefit from this great feature?
I have a suggestion about the interface, but feel free to ignore…
I find the ‘show modifications without mask’ view very useful as you can see which areas of the photo will be affected. Could there be a way of making this more prominent, eg a button to toggle it on and off. At the moment it is hidden in a drop down menu, not in an obvious place.
I wait for the green light 
No need to make a build from that branch. I just merged the speedups into the main newlocallab branch.
With my speedup commit I broke Locallab Retinex tool by accident. Working on a fix but can not promise a fix before tomorrow. Other Locallab tools still should work well…
Local Lab is now a very nice and useful branch, and I am very impressed by the color/edge detection capability of the spot.
As asked previously, is it plan to include local lab in the master branch?
If no, what would be needed for an inclusion in master branch?
Hi all
After many changes, update, etc. I recommended to clean cache, and not used old pp3
jacques
Currently there is no timeline to include locallab into dev branch. But we’re working hard on locallab (currently with 3 developers + two testers).
There are a lot of things in locallab which have to be solved before we can merge it. More speedups are needed, the code needs more cleanups to be maintainable, the ui has to be improved, and so on.
Short message, it’s work in progress, with increasing progress, but no timeline.
Ingo
Edit: In case of interest just follow the commits to newlocallab branch
@cabernet_olivier
Thank you for this evaluation 
I have improve “shape detection” - this term include everything that contributes intuitively or not to what the user wants to do - and in this sense it’s very different from a “clipping technique” (mask, layers…) of the objects we want to treat.
I begin this improvment in January 2019, and it is based essentially on the deltaE, but also on the variation of structure. In most cases this technique should solve the problems.
Over the last few weeks I have added a series of algebra control for deltaE, transitions, … I think today the algorithm is sensibly finalized - even if of course alongside this algorithm there are improvements that can be made over time (regardless of the rigor of the code or its speed);
Ingo is right, before “merge with dev”, we have to check the code, its robustness, improve its speed, and for the GUI part (thanks to Pandagrapher) test the current interface
Thank you for these answers!
@jdc Jacques, can you check if the scope slider works as intended for the Blur filter?
I tried to simulate lens blur in the background of an image (see [Play Raw] Street scene challenge - #8 by sguyader). I put a big RTspot in the background foliage but to my surprise, whatever the value of “scope”, I could never make it to blur only the green foliage, everything in the the spot area was blurred (even the blue jean, the girl’s skin, the grey concrete…) so I had to use many excluding spots.
@sguyader
Have you tried with an “old” version ?
I think the last is a little better, but for “Blur” - perhaps due to the principle of “blurr”, scope has small effect
jacques
No it was with a recent build (from friday I think). But I understand if by principle scope has only a small effect.
@sguyader
I have found (it is my fault) a big big bug in “Blur filter”
The last commit, corrects this
Now I think it works
jacques
@sguyader
With the “old” version, Blur works very very very bad
Too much blur, scope inactive (or near inactive!)
Now, Blur is progressive, scope is active, and inverse works as normal
jacques
Ok, I’m compiling now. I think this it is because of this bug if I had trouble simulating the lens blur in foliage, i’ll try again with the new build. Thanks!
@jdc I tested the corrected blur filter. In fact it doesn’t work as I was expecting: the scope slider seems to work more like an overall blend slide. If you set high radius value, and scope is not very high, the effect looks like it introduces some haze, and as you increase the scope value, it’s like you’re increasing the blur filter opacity (just as in Gimp if you duplicate the base layer and apply the gaussian blur on the duplicated layer, and use the opacity slider.
Ok now it works a little better than before the bug. It works as I have concepted.
But what do you want …in french.
Thank you
Jacques
Jacques, je m’attendais à ce que “scope” fonctionne davantage comme un moyen de sélectionner plus ou moins les zones impactées par le flou en fonction du deltaE. Du coup je me disais que si je place le spot sur une zone verte (feuillage) et que j’agrandis la zone couverte pour y inclure une zone rouge par exemple, en modifiant la valeur scope je m’attends à ce que l’effet ne change pas sur les zones vertes, mais que ça inclue (en augmentant la valeur scope) ou évite (scope plus faible) d’affecter la zone rouge.
C’est comme ça que je comprends l’action du “scope” pour les autres filtres en tous cas, donc je m’attends par défaut que ça fonctionne de même pour blur.
Si j’ai testé cela, c’est pour essayer d’avoir un beau flou sur un feuillage en arrière plan tout évitant que le sujet en avant plan, s’il est d’une couleur très différente du vert du feuillage, ne se retrouve flouté également.