Local Lab build

(Sebastien Guyader) #201

Ok c’est plus clair ! Merci Jacques.

A translation of Jacques’ latest explanation:

  • before Ingo’s code modification, in single spot mode, the filter worked well when the spot was within the preview, but didn’t behave correctly when the spot was outside the preview area
  • after Ingo’s modification, in single spot mode everything worked, whether the spot was inside or outside the preview area
  • but currently, in multiple spot mode (and even if only one is activated), the filter can behave incorrectly whether the spot is inside or outside the preview area, because of an incorrect management in “mip” files of Ingo’s algorithm

Jacques’ temporary proposal is to allow correct behaviour in the current multiple spot mode, but only if the spot is within the preview area. A solution will remain to be found to deal with spots outside the preview, without iinterfering with the global behaviour.

(Desmis) #202

Hello Sébastien

Thank you for the translation :slight_smile:

(Desmis) #203

I push a change.
It solves the problem above, but as I said, not if the spot is outside the preview :slight_smile:

I’ll try to fixe that since tomorrow, but I’m not sure about the time to do it


(Sebastien Guyader) #204


Thanks for the change, it looks good (though I haven’t tried extensively yet).
One thing I noticed, which is just a little bit annoying, is that when I resize the zone of the active spot, the preview refreshes at regular intervals even if I’m still dragging the handle, and while it refreshes, it slows down on my computer.
Wouldn’t it be better to prevent the preview from refreshing while you’re still dragging the handle, and refresh only when you release the mouse button?
I would prefer this, but I don’t if it’s something people would prefer generally.

(Desmis) #205

A nouveau je m’exprime en français - trop complexe à expliquer dans mon “pooreu angliche” :slight_smile:

Je viens de pousser un changement qui je l’espère solutionne définitivement le (gros) bug que tu as trouvé - merci pour cette “trouvaille” - le système devrait globalement avoir de meilleures réponses !
Maintenant les références “spot” sont actualisées et à la bonne valeur, y compris si le spot est hors du “preview”. Pour cela j’ai créé 3 “sliders” totalement invisibles à l’utilisateur, qui permettent via une relation entre rtengine et rtgui, une mise à jour en temps réel.

Le problème que tu évoques est absolument incontournable - comme je l’explique dans la doc - le système ne fonctionne que si et seulement si, le rafraichissement se fait en temps réel pour mettre à jour le fichier “mip” (ce n’est pas le cas pour les pp3, mais ceux-ci dans le cas général ne servent que de mémoire des actions, contrairement aux “mip”)…Donc inévitable…du moins tel que je l’ai conçu :slight_smile:


last locallab_dev_5.0-r1-gtk3-94-g2e7741d1_WinVista_64 uploaded athttps://drive.google.com/open?id=0B2q9OrgyDEfPS2FpdDAtMVI1RG8

(Desmis) #207

I have found another bug…It was a giddiness…Which led to bad behavior in “preview”

I just push a change with this fix and change also “expander style for gtk3”

I think, I hope, it’s solved :slight_smile:


last locallab_dev_5.0-r1-gtk3-107-g05c22357_WinVista_64 uploaded at https://drive.google.com/open?id=0B2q9OrgyDEfPS2FpdDAtMVI1RG8

(dngimage) #209

Hey all,
I just got RawTherapee_locallab_dev_5.0-r1-gtk3-109-g90e66b6f_WinVista_64.zip
from here:
and it is running fine but it still has this bug:

RT locallab 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 work in older versions. If you quit and re-start, RT locallab forgets the last main window’s position and size.

(Desmis) #210

I have just returned from vacation!
I looked at the work done during my absence … impressing the number of commits :slight_smile:

I just pushed “merge with dev”.

As for the behavior evoked by @dngimage, I tried with 2 compiled versions of the last commits.

  • One with locallab_dev
  • The other with dev
    I do not see any behavioral differences (I’m under Windows 8), “Windows M” does not work in both cases, and in both cases click on the task bar does nothing.
    This is probably a general behavioral differences from to GTK3…


(dngimage) #211

I have just returned from vacation!

Nice to have you back, Jacques.

I do not see any behavioral differences (I’m under Windows
8), “Windows M” does not work in both cases, and in both
cases click on the task bar does nothing.
This is probably a general behavioral differences from to GTK3…

I hope it isn’t a permanent problem when using GTK3.
It is an annoying bug.
I am using Windows 10 and did the same test you did.




I made my first tests with last RawTherapee_locallab_dev_5.0-r1-gtk3-309-g04bdea0b_WinVista_64.zip available here

I have some preliminary remarks

1- display and management of control points.
As it is, it is not intuitive but I can get used to that.
Perhaps the display button should display all control points then clicking in central circle should select the control point. Then all commands applicable to this contol point are available.
deleting a CP. If I understand there is no deleting of CP but you “restet” it.

2 MIP files. They are part of the processing as the pp3. Why they are not saved alongside the pp3. I found them in the cache dir though I ask the pp3 be saved alongside the raw file. I think it could be improved.

3 Tone mapping : even with strength =1 (all other parameters unchanged, neutral profile) it can generate huge artifacts
see http://imgur.com/a/grVH1

(Morgan Hardwood) #213

@gaaned92 last time I checked, mip files were not needed to reproduce the processing. i.e. All I had to do was to apply the PP3 and the locallab points were placed in the correct places and did the correct things. If that’s still the case then the mip files are deletable cache items and belong in the cache.


Perhaps I am wrong somewhere but it is not my experience.

To reproduce
-open an image

  • apply 3 CP on it with some different parameters
    -close RT
  • reopen it and open the image. You get previous processing
  • close RT, suppress MIP reopen the image, There is no more CP.

(LZ1) #215

Something is wrong with Lab L curve in the last builds. See attached picture.
As you can see, I placed pointer on bright spot ( L=77.6), but corresponding point on the curve is not correct - it is close to 15.

Version: 5.0-r1-gtk3-499-g5b0d816
Branch: locallab_dev
Commit: 5b0d816
Commit date: 2017-04-12
Compiler: cc 5.4.0
Processor: x86_64
System: Linux
Bit depth: 64 bits
Gtkmm: V3.18.0
Build type: release
Build flags: -std=c++11 -Wno-deprecated-declarations -Wno-unused-result -O3 -std=c++11 -march=native -Werror=unused-label -fopenmp -Werror=unknown-pragmas -Wall -Wno-unused-result -Wno-deprecated-declarations -O3 -DNDEBUG
Link flags: -march=native
OpenMP support: ON
MMAP support: ON

This one works fine:
Version: 5.0-r1-gtk3-174-g11940f9
Branch: locallab_dev
Commit: 11940f9
Commit date: 2017-03-12
Compiler: cc 5.4.0
Processor: x86_64
System: Linux
Bit depth: 64 bits
Gtkmm: V3.18.0
Build type: release
Build flags: -std=c++11 -Wno-deprecated-declarations -Wno-unused-result -O3 -std=c++11 -march=native -Werror=unused-label -fopenmp -Werror=unknown-pragmas -O3 -DNDEBUG
Link flags: -march=native
OpenMP support: ON
MMAP support: ON


Possible I’m a NOOB or I’m doing something not correct.

I just instalad the last version of the DEV local lab version, but when I’m trying to activate the local lab, it crash tand exit…

Does it need some preparation or so?

(Morgan Hardwood) #217

Delete your cache, and write a useful bug report if it still crashes.



just deleted the cache folder and try again to run the RT (RawTherapee_locallab_dev_5.0-r1-gtk3-521-g5006a891_WinVista_64) open an image, and when i click to activate the local edit just shut down the program.

it’s the only thing it make the shut down the program, never had this kind of problem in other versions.

i’m using Windows 10, and before i installed this version i had removed the previous one.

wish it helps

PS. I just deleted the cache folder on …\AppData\Local\RawTherapee*CACHE*

(dngimage) #219

Using RawTherapee locallab_dev 5.0-r1-gtk3-521-g5006a891 from here: https://drive.google.com/drive/folders/0B2q9OrgyDEfPS2FpdDAtMVI1RG8

Another possible bug. If you activate Local Lab and Color & Light, then set Lightness to -100, it won’t darken the Control Point to 100% black.
But It works fine when Inverse is checked.

(Desmis) #220

Under certain circumstances, Locallab could crash, for example in the event that the spot area was outside the preview.
This was a new bug related to the improvement in processing speed.
This is solved from 5ab2aa3

"it won’t darken the Control Point to 100% black, in normal mode". This is not a bug, but normal operation