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.
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.
A nouveau je m’exprime en français - trop complexe à expliquer dans mon “pooreu angliche”
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
Jacques
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.
I have just returned from vacation!
I looked at the work done during my absence … impressing the number of commits
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…
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
@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.
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
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*
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.
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
@dngimage
“it won’t darken the Control Point to 100% black, in normal mode”. This is not a bug, but normal operation
