@todd, can you post a pp3 file which leads to the memory leak in locallab? I will try to fix it while @jdc est en vacances 
1 Like
@heckflosse,
While Jacques drinks a beer “en vacances” , you may also want to take a look under: Color & Light - Contrast.
If you move the slider to -100 several times and inverse is checked, RT will crash.
I just pushed a fix for a memory leak to locallabgtk3 branch. Though I don’t know if that’s the one @todd reported.
2 Likes
Here are a couple… IMGP2315.DNG.pp3 (11.7 KB)
IMGP2328.DNG.pp3 (11.7 KB)
@todd
Looking at your pp3 I think I fixed the memory leak you reported
1 Like
Crash confirmed. Looking.
@jdc there were many stale (dépassé?) locallab issues, I merged them all into #3421 and I re-wrote there the bugs I listed in my comment above.
Crash confirmed. Looking.
Good to know. Thanks for looking into this, Ingo!
Fix for the crash pushed to locallabgtk3 branch.
De rien. 
RawTherapee_locallabgtk3_5.0-r1-gtk3-27-g4fc43ca6_WinVista_64.zip is running fine.
I just got it from here:
https://drive.google.com/drive/folders/0B2q9OrgyDEfPS2FpdDAtMVI1RG8
It looks like the bugs reported are gone!
The only thing now is that RT doesn’t seem to “remember” the last main window’s position and size. If you click on it on the task bar it won’t minimize. The Windows key + M doesn’t minimize the main window either as it used to in older versions and in RT5-r1. For now, the only way to get the main window where you want it is by re-positioning the main window with the mouse every time you start RT.
Thanks!
I create a new branch “locallab_dev” (the old locallabgtk3 is buggy).
Now
- no more unnecessary message in history
- mip files are stored in “mip” folder inside “cache”
Obviously old mip files are obsolete.
1 Like
I push a change in “locallab_dev”
Now, in option “Preferences” , you can enable in “general / local adjustements”, spot delimiters.
Be carefull, this spot delimiters in not “perfect”, but it must be good in 95% situation.
see Rawpedia Local Adjustments/fr - RawPedia
More : I have merge with dev, with many changes…I hope no error !
locallab_dev_5.0-r1-gtk3-77-g1f7ad78e_WinVista_64 uploaded at https://drive.google.com/open?id=0B2q9OrgyDEfPS2FpdDAtMVI1RG8
@jdc Bonjour Jacques,
I just tried, quickly, your new Local Lab version (in Linux). I’m not sure if the behaviour I’m going to describe is correct, but it is not what I expect. In the following link, I uploaded a raw file and the .pp3 and .mip files: https://filebin.net/xhpd3ijakkjmlaj5
What I did it create a single control point, in standard mode, and set chrominance to -100. To my surprise, some color patches don’t loose their chrominance. For example, the yellow patch stays yellow if the control point is centered on the patch, but if I move the center of the control point to the patch below, then the yellow patch become grey. Similar things happen with the purple patch.
Any idea?
Bonjour Sébastien
Je préfère répondre en français, car c’est complexe…
Rappel : au début de “locallab” (à l’époque où il n’y avait qu’un seul spot), nous avons été confronté au problème du spot central (celui qui mesure hueref, chromaref, lumaref et qui sert de références aux algorithmes), lorsque celui-ci sort du “preview”…donc pour l’essentiel lorsqu’on fait un zoom et que le spot de mesure n’est plus visible.
Ingo a trouvé une élégante parade qui consiste à mettre “de côté” les 3 valeurs calculées en les déclarant “INFINITY” au départ et en ne les recalculant que si nécessaire.
Mais ce que je viens de découvrir par ton signalement, et qui maintenant m’explicite certains dysfonctionnements, c’est que ce dispositif peut être pris en défaut dans certains cas. Les valeurs ré-attribuées après sauvegarde dans les fichiers “mip” peuvent dans certains cas être erronées.
Le problème est loin d’être simple. Je vais faire une première modification (en la vérifiant) qui va revenir au fonctionnement antérieur (en fait ce n’est pas simple, même de revenir en arrière, car l’algorithme est sensé prendre en compte en multi-spot, le fonctionnement prévu par Ingo…qui fonctionne parfaitement en simple spot).
Si elle fonctionne, je posterais un changement - avant mon départ samedi pour les Caraïbes - ce coup-ci ce n’est pas dans ta belle Guadeloupe !). Ce changement permettra un fonctionnement correct en multi points, mais avec “bug” lorsque le spot est hors “preview.”.
Puis, j’examinerais avec l’appui de Ingo (s’il peut dégager du temps), comment faire fonctionner correctement en multi-points et spot en dehors du “preview”…
Si tu peux traduire ce serait très bien…
Merci
Jacques
Jacques,
Si je comprends bien tu dis que le problème apparaît quand le point de référence est déplacé hors de la zone de “preview”, en mode multipoints?
Mais sauf si quelquechose m’a échappé, j’ai observé le problème cité avec 1 seul point déclaré, en sans déplacer la zone hors du champ de “preview”…
-Sébastien
Tu vois que ce n’est pas simple à expliquer…même en français, alors en angliche
Le problème apparaît dans tous les cas, même si le spot est à l’intérieur du “preview”, mais l’algorithme “Ingo” prend en compte le cas où le spot est en dehors.
C’est cette prise en position qui interfère sur la gestion des fichiers “mip”.
Dit autrement
-
avant en mode mono spot, avant la modification faite par Ingo - le système fonctionnait correctement avec le spot visible et mal lorsque le spot était en dehors
-
après la modification de Ingo, en mono spot, tout fonctionne correctement que le spot soit dans ou hors le preview;
-
maintenant, en mode multi spot (même si il n’y en a que un d’activé), le système peut dysfonctionner que le spot soit dans ou hors le preview, et la cause est la mauvaise gestion (par moi) dans les fichiers “mip” de l’algorithme mis au point par Ingo.
Donc ce que je propose (provisoirement), c’est un fonctionnement correct en multi spot, mais uniquement si le spot est dans le preview…Reste à solutionner en multi spot, la sortie du preview, sans interférer sur le fonctionnement global.
est-ce plus clair ?
Merci
Jacques