Rawtherapee: Roadmap for locallab

[Desmis]

French :
Voici les points qui me semblent importants à connaître et/ou à modifier en ce qui concerne l'évolution de "locallab".

Bien sûr ce qui suit est mon point de vue, fondé sur ma perception et la réalisation que j'ai effectuée durant 2 ans. Le contenu ainsi que les priorités peuvent être modifiés.

En avant-propos il me semble souhaitable de lire la documentation que j'aie réalisée (en français)...un préalable est probablement de la traduire en anglais. Elle contient les informations des difficultés que j'ai du résoudre pour faire fonctionner le système.
http://rawpedia.rawtherapee.com/Local_Lab_controls/fr

On peut classer ces points clefs en catégories :
1) GUI
2) Enregistrement et utilisation des paramètres locaux
3) Gestion des événements
4) Algorithmes de traitement des images partielles
5) Documentation

1) GUI
a) revue du code GUI

Haute priorité:
b) améliorer la création et le suivi des points de contrôle, aujourd'hui assurés par un "slider".
Ce point à une forte incidence sur la catégorie 2 ("enregistrement et utilisation des paramètres locaux")

Basse priorité :
c) intégrer les sliders et autres contrôles GUI (checkbox, ...) aux points de contrôle
d) remplacer les lignes imaginaires elliptiques par des LUT  reliant les 4 « sommets / délimiteurs ». Le point de contrôle ressemblerait un peu à un « lasso ». Attention toutefois ces LUT-courbes doivent permettre l’homothétie pour assurer les transitions

2)Enregistrement et utilisation des paramètres locaux
a) Évaluation du processus de création, suppression, ajout, type de données.. dans les fichiers *.mip
b) Impact de 1)a sur ce processus
c) Évaluation du « work around » du cryptage des données pour les courbes : voir le chapitre « conversion des données » de la documentation.

3)Gestion des événements
C'est un point clef du fonctionnement – voir le chapitre de la documentation « quelques fantaisies incontournables ».
a) revue des différents « contournements » et parades possibles pour rendre les système plus lisible et robuste.

4)Algorithmes de traitement des images partielles
C'est bien sûr le point clef du dispositif, car contrairement aux « lassos – calques ... » les algorithmes sont un peu ou très différents des algorithmes pleine image du fait de la détection de forme. Ces algorithmes doivent tenir compte de « proximités » pour agir.

4a) revue du principe généraux : détection de formes fondée sur le deltaE, « scope », transitions...

4b) revue de chaque module : fonctionnalités, dysfonctionnements, incompréhensions, optimisations : vitesse, fonctions « xxx_local » (ex cbdl_local, reti_local, et.) qu'il est possible de mieux rationaliser.
4b0) Settings
4b1) Color and light : normal et inverse
4b2) Exposure
4b3) Vibrance
4b4) Blur and Noise : normal et inverse
4b5) Tone Mapping : + automatiser la mise à zéro de réduction des artefacts (settings)
4b6) Retinex : normal et inverse
4b7) Sharpening : normal et inverse
4b8) Contrast by detail levels : + automatiser la mise à zéro de réduction des artefacts (settings)
4b9) Denoise
4b10) Ajout éventuel d'autres modules ?

5)Documentation
5a) traduction en anglais et en...
5b) séparer la documentation qui explique les algorithmes et celle qui commente le fonctionnement
5c) réaliser des tutoriels pédagogique
5c1) sur les particularités des points de contrôle de type RT-point, différents des calques / fusion
5c2) sur l'utilisation courante et les points clefs.
/////////////////////////////////////////////////////////////
English :
Here are the points that I think are important to know and / or modify regarding the evolution of "locallab".

Of course the following is my point of view, based on my perception and realization that I carried out for 2 years. Content and priorities can be changed.

In the foreword it seems to me desirable to read the documentation I have produced (in French) ... a prerequisite is probably to translate it into English. It contains information about the difficulties I have to solve to make the system work.
http://rawpedia.rawtherapee.com/Local_Lab_controls/fr

These key points can be classified into categories:
1) GUI
2) Recording and using local parameters
3) Event Management
4) Partial image processing algorithms
5) Documentation

1)GUI
a) code revuew

High priority:
b) improve the creation and follow-up of control points, now ensured by a "slider".
This point has a strong impact on category 2 ("recording and use of local parameters")

Low priority:
c) integrate sliders and other GUI controls (checkbox, ...) at control points
d) replace the elliptical imaginary lines by LUT connecting the 4 "top / delimiters". The control point would look a bit like a "lasso". Attention however these LUT-curves must allow the homothety to ensure the transitions

2)Recording and using local parameters
a) Evaluation of the process of creation, deletion, addition, data type .. in * .mip files
b) Impact of 1) a on this process
c) Evaluation of the "work around" of data encryption for curves: see the chapter "Data conversion" of the documentation.

3) Event Management
This is a key point of the operation - see the documentation chapter "some fantasies unavoidable".
a) review of the various "bypasses" and parries possible to make the system more readable and robust.

4)Partial image processing algorithms
This is of course the key point of the device, because unlike the "lasso - layer" ... the algorithms are somewhat or very different from the full image algorithms because of the shape detection. These algorithms must take into account "proximities" to act.

4a) review of the general principle: detection of forms based on the deltaE, «scope», transitions ...

4b) review of each module: functionalities, malfunctions, misunderstandings, optimizations: speed, "xxx_local" functions (ex cbdl_local, reloc_local, and.) That can be rationalized more effectively
4b0) Settings
4b1) Color and light : normal and inverse
4b2) Exposure
4b3) Vibrance
4b4) Blur and Noise : normal and inverse
4b5) Tone Mapping : + automatize reset artifacts reductions(settings)
4b6) Retinex : normal and inverse
4b7) Sharpening : normal and inverse
4b8) Contrast by detail levels : + automatize reset artifacts reductions (settings)
4b9) Denoise
4b10) Add eventualy others modules ?

5) Documentation
5a) translation into English and ...
5b) separate the documentation that explains the algorithms and the one that comments on the functioning
5c) create teaching tutorials
5c1) on the peculiarities of the RT-point control points, different from the layers / fusion
5c2) on current usage and key points.

[lrq3000]

I just wanted to say a BIG THANK YOU to @Desmis and everyone who worked on locallab (and RawTherapee also!), it is an AMAZING feature!

I am a total newbie, I just started using RawTherapee one week ago, and discovered newlocallab 2 days ago (I'm no photographer and I never did any Lightroom kind of image work, I just use Gimp from time to time!), and now I can essentially process all my images the way I want! Locallab is very intuitive and easy to use, I did not need to read any documentation. It is particularly very useful to fix the lighting of the face of backlit characters, it works wonderfully well!

In addition, I have found the new Local Contrast with differenciated Darkness and Lightness sliders very very useful to precisely set the look I want for a picture, as well as the new HDR tone compression module.

More specifically, I am using: RawTherapee_newlocallab_5.3-601-g63073b47_WinVista_64.zip.

Now for some feedback:

• the control point sometimes disappears when zooming in/out, but it usually reappears if one zoom in/out again.
• sometimes the app will freeze eternally when trying to save immediately an image.
• By reading @Desmis, I understand locallab is rather a workaround than a core feature, but I would like to suggest if it is possible that locallab should be a core feature. What I mean by that, is that instead of duplicating submodules (color correction, exposition, vibrance, etc.) for locallab, locallab could instead be a global control of the interface, which redirects any RawTherapee module either on the "global" image, or any "local" control. This would have two advantages: first then all RawTherapee modules would be available also for local controls, and developer-wise it would avoid code (and effort) duplication. Of course, this suggestion is only possible if the way locallab provide local control is generic (can we apply any image processing algorithm on local controls, or do they need adaptation?).

In conclusion, I strongly suggest that newlocallab should be merged to RawTherapee as soon as it matures enough to avoid usability issues (such as freezing -- which might be due to other changes in the dev branch BTW), because even if the implementation changes in the future, it is already very useable and intuitive and provide functionality that is otherwise impossible to do in RawTherapee. Kudos to the devs!

[Pandagrapher]

Hi
I've started using RawTherapee two years ago and I really like it. Locallab is a missing feature I was much expecting. So thank you @Desmis :)
In order to help I started to work on GUI as roadmap suggests it
Here is a preview with source code:

Control points can now be managed in a same time by a treeview. For the moment, the control points management panel is independent. If you are interested, I can continue working on it to integrate it with the other locallab functions

[Benitoite]

@Pandagrapher do you have a github repository fork or pull request for your work?

[Pandagrapher]

@Benitoite here is my fork:
https://github.com/Pandagrapher/RawTherapee

[Desmis]

@Pandagrapher @Hombre57

@Pandagrapher I push your work, whitout change, in a new branch "locallabgui"
Thanks to tou for this work :)

jacques

[Hombre57]

@Desmis @Pandagrapher Which one should be considered the official branch then ?

[Desmis]

@Hombre57
This new branch is the work of Pandagrapher, I have discover this work yesterday..
Curiously, I don't know why, the branch I download works, but the one I commit, does not works (the part add by Pantagrapher)
More , this branch is about 100 commit behind dev.

Actually the only official branch is newlocallab :)

I tried tu push the work of Pabdagrapher, to give to everybody this new possibility....but it does not work..why ?

jacques

[Desmis]

@Pandagrapher

It seems that the the files contains in https://filebin.net/9bkqg6kcoyadflc0 and in https://github.com/Pandagrapher/RawTherapee are very different :)

But how can I used https://github.com/Pandagrapher/RawTherapee. I don't know how to do ?

[Desmis]

I just delete the branch "locallabgui"...it does not work at all :)

[heckflosse]

@Desmis

git clone https://github.com/Pandagrapher/RawTherapee.git somefolder
cd somefolder
git checkout newlocallab
mkdir build
cd build
cmake -G "MSYS Makefiles" -DCMAKE_BUILD_TYPE="Release" -DPROC_TARGET_NUMBER="2" -DBUILD_BUNDLE="ON" -DCMAKE_INSTALL_PREFIX="." -DBINDIR="." -DDATADIR="." ..
make install

[Desmis]

@heckflosse

Ingo
Thank you, I will test soon :)
jacques

[heckflosse]

@Desmis Jacques, I forgot one line. Updated my above comment.

[Desmis]

@heckflosse

I just compile, no problem :)

[Pandagrapher]

@Desmis Sorry I wasn't comfortable with Git so I firstly shared all the source code with my modification in filebin... As my fork is now up-to-date, I have deleted the filebin link above and I will (I hope) regularly update my fork ;)

[Desmis]

@Pandagrapher
Me also, I am not "comfortable with Git" :)

[gaaned92]

Neither me!
If you want frequent builds of this branch for windows64, let me know . Then, the easiest way for me is to put it in a branch of main repository .

[Desmis]

@gaaned92
I think it will be a good thing, to put in main repository :)

[heckflosse]

@Desmis @gaaned92 @Pandagrapher

Putting it into the main repo would need to give @Pandagrapher commit rights to the main repo to work on it. Not that I'm agains that, but we (the current contributors) have to agree.

Another possibility would be to use @Pandagrapher fork and he will give commit rights to @Desmis

What do you think?

[Pandagrapher]

@Desmis @heckflosse @gaaned92
I have no problem with giving commit rights to @Desmis for my fork
Isn't that easier I just send a pull request for newlocallab branch and @Desmis manages it ?

[heckflosse]

@Pandagrapher

Isn't that easier I just send a pull request for newlocallab branch and @Desmis manages it ?

absolutely

[Desmis]

In this case, no problem for me :)
No matter the solution, for me the essential thing is to be able to share the work

Recall : I am not at all a GUI specialist :)
jacques

[heckflosse]

@Desmis

I am not at all a GUI specialist :)

Nor am I.

[Pandagrapher]

@Desmis
Just sent the pull request :)

4623

[Beep6581]

You can of course give someone access rights to your own repo, but there's no _need_ to do that. Git is a _distributed_ version control system. Person A can add person B's fork as a "remote" and work on the code, and person B can then add person A's work as a remote and merge the changes.
https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes
https://help.github.com/articles/adding-a-remote/

[Desmis]

If I do on my repository where I clone Pandagrapher works

• git remote -v
  I obtain:
  origin https://github.com/Pandagrapher/RawTherapee.git (fetch)
  origin https://github.com/Pandagrapher/RawTherapee.git (push)

Is that true ?
But all the text is not clear enough for me !:)

Now how I can "commit", "merge" and so on....
a) ex for commit and push with the same command, "git push --set-upstream origin newlocallab" or only for push : "git push origin newlocallab"
b) are my login and password the same as for "Rawtherappe current" or are they different ?

[heckflosse]

@Desmis

a) if you are on newlocallab in https://github.com/Pandagrapher/RawTherapee.git git push should be enough
b) yes, they are the same

[Desmis]

@Pandagrapher
Could you go further in the integration of this new GUI interface, I am not currently available
Thank you

Jacques

[Hombre57]

@Desmis @Pandagrapher I'm finishing the testoutputprofile branch, and will then look at this new GUI stuff.

What I had in mind though is what @Desmis proposed :

c) integrate sliders and other GUI controls (checkbox, ...) at control points

i.e. It should be rather easy to add buttons at the control point's location, contextually. This would avoid having too much GUI in the Editor Panel. You can have a look at the spot-removal branch, where the GUI should be fully functional (not the engine part). Some elements appears contextually. Icon support is already done, but may have to bee more tested.

[Pandagrapher]

@Desmis @Hombre57
Yes I can go further with the GUI in order to continue with point 1)b) of your roadmap
To integrate the locallab tools with the new control points management, I see two solutions:

1. As in the actual implementation, I can add all the tool parameters to each control point.
   Pros: Easiest to implement
2. Each locallab tool can be added one or several times and has one or more attached control point. It's close to how darktable works with masks.
   Pros: Especially to manage normal and exclusive control points in coherence with one tool, we won't need to verify we have the same parameters on this tool for both curves. But maybe this will require to update locallab engine

What do you prefer?

[Desmis]

@Pandagrapher

For me, the solutions 1) is the first to be implemanted.
It keeps the processing processes present in iplocallab, it must keep "normal" and "exclusive" control point, and also "duplicated".
This solution once the GUI interface as you propose - with cursors, curves, menus, ..- on the right panel, can be directly merge with dev, once all tested

In a second step, we can add as @Hombre57 proposed, to add "floating" menus...(difficulties with curves, combobox..)

In a third step, we can add the 2) above. This solution allows "layers" and "masks" which are no needs with "RT-points" (as U-points), but if we add "selection" area with mouse, and change the algorithms, this feature will be great.

jacques

[Desmis]

And of course, for 1) multiple RT-points.
Actually it works in interaction between locallab.cc and improccoordinator.cc, up to 500 control points if necessary :)

[Pandagrapher]

@Desmis Ok, let's follow this plan :)
(I think I will add a limitation if someone wants to use 501 control points ;))

[Desmis]

@Pandagrapher
Can I merge dev in newlocallab, but for the master remote http://github.com/Beep6581/RawTherapee

Other question : I don't know how to update your remote from the "master"...I let you do it, but with what instructions. Thank you :)

[Pandagrapher]

@Desmis
Yes, you can merge dev in newlocallab. For my remote, as it is linked to your branch, I guess I will just have to merge your branch to my remote

I am currently still working on the integration. I just have one question: why using .mip file instead of .pp3 file to save locallab params? I think I have found a way to save spots in .pp3 file (which will also simplify the integration for me). I am testing it but I can still maintain .mip file if necessary

[Desmis]

@Pandagrapher
OK, I will merge dev in newlocallab for "master"
for "mip", I think to verify, pp3 are only for one file and does not stock multi values,but if it is possible why not :)

another remark, "mip" are save in real time, either it does not work!

[Desmis]

merge done :)

[Pandagrapher]

@Desmis
I am continuing the integration of the new control spot panel and I just pushed an update to my newlocallab fork with the following improvements:

• ProcParam and .pp3 files can now manage several control spots (number is dynamically managed) which can replace .mip files
• Control spot curves are automatically visible if the Locallab tab is selected or not (according to visibility parameter of each curve)

For the moment, ProcParam only manages few Locallab parameters (to test the evolution). For instance:
[Locallab]
Enabled=true
Nbspot=2
Selspot=2
Id_0=1
Name_0=Control Spot #1
Isvisible_0=1
Shape_0=RECT
SpotMethod_0=exc
ShapeMethod_0=SYMSL
LocX_0=232
LocXL_0=232
LocY_0=428
LocYT_0=428
[...]
Id_1=2
Name_1=Toto
Isvisible_1=1
Shape_1=ELI
SpotMethod_1=norm
ShapeMethod_1=INDSL
LocX_1=143
LocXL_1=243
LocY_1=467
LocYT_1=337

I now have to integrate the remaining parameters (easy but long job) and to update Locallab engine functions (deactivated in my fork) to directly manage the new ProcParam as interface and be consistent with RT philosophy (I will certainly need your help @Desmis)

@Desmis
J'ai fait une passe sur la liste des paramètres actuellement enregistrés dans le fichier .mip. J'ai l'impression que certains ne sont plus utilisés ou correspondent plus à des variables intermédiaires :
std::vector<double> localTgaincurverab;
int centerXbuf;
int centerYbuf;
int noisechrodetail;
int retrab;
int sensiexclu;
int struc;
Glib::ustring dustMethod;
bool cutpast;
bool lastdust;
bool inversrad;
double hueref;
double huerefblur;
double chromaref;
double lumaref;
double sobelref;
Faut-il les intégrer dans la mise à jour du ProcParam ? (les variables intermédiaires ne peuvent-elles pas plutôt être stockées en mémoire que dans le fichier .pp3 ?) Par ailleurs, vu que Locallab peut être géré par le mécanisme classique de RT via le ProcParam qui gère maintenant un nombre de points de contrôle illimité, je suis d'avis d'abandonner complètement le fichier .mip : cela te convient-il ?
Pierre

[Desmis]

@Pandagrapher
Si tu arrives à faire tout fonctionner avec des pp3, bien sûr que tu abandonnes les mip
Pour les variables décrites ci-dessus:

int centerXbuf;
int centerYbuf;
Glib::ustring dustMethod;
bool cutpast;
bool lastdust;
Ne sont pas utilisées actuellement, mais pourraient l'être. En effet j'avais commencé la possibilité de retirer les "merdes" et autres "dust", mais comme Hombre travaille dessus j'ai abandonné

std::vector localTgaincurverab;
int retrab;
Sont des variables que j'aie utilisée pour mettre à jour les événements (ce que j'appelle des bizarreries), si tu arrives à contourner elles peuvent être supprimées

int noisechrodetail==> est utilisé
int sensiexclu ==> est utilsé
int struc ==> est utilisé
bool inversrad ==> ne semble plus utilisée !!

double hueref;
double huerefblur;
double chromaref;
double lumaref;
double sobelref;
Ces 5 variables sont utilisées et fondamentales

Merci pour ton travail

[Desmis]

@Pandagrapher
Of course, I can help you if need :)
Je suis curieux de voir comment tu vas traiter les données des "curves" et "double sliders", pour moi c'est du chinois, et les fichiers "mip" - qui fonctionnent cependant - traduisent mon ignorance profonde de l'informatique et de sa partie GUI (je n'ai aucune formation informatique : programmation, etc. ) :)

Je suis aussi curieux de voir comment tu vas passer les paramètres à "Lab_local"....dans improccoordinator.cc
Attention - rappel - il y a des pièges que je mentionne dans le début de cette "issue", ce que j'ai appelé des bizarreries sans lesquelles cela ne marche pas.

Quant à Hueref...sobelref, ces valeurs sont calculées dans "Lab_local" et "passées" au GUI, ce sont elles qui contiennent les "bases" des algorithmes de détection de forme.

jacques

[Pandagrapher]

@Desmis
Pour le traitement des données des "curves" (a priori, c'est le même principe pour les "double sliders"), tu peux voir comment j'ai fait avec mon dernier commit dans mon fork :
https://github.com/Pandagrapher/RawTherapee

Je continue l'intégration des paramètres des différents outils de Locallab dans procparams et le fichier .pp3 (j'ai juste fait les points de contrôle et "Color & Light" pour le moment mais ça devrait aller plus vite maintenant : ce n'est plus que du "copier/coller") et ensuite je m'attaque aux bizarreries et au passage des paramètres à "Lab_local" ;)

Pierre

[Pandagrapher]

@Desmis
Je viens de terminer l'intégration entre mes modifications d'interface et de procparams avec improccoordinator, dcrop, ... :

Pour l'instant, les mises à jour du code sont remontées uniquement dans mon fork :
https://github.com/Pandagrapher/RawTherapee

J'ai fait quelques tests et ça a l'air de donner la même chose que le code de la branche "newlocallab". Pourras-tu STP tester cette nouvelle version ?

Pour ma part, je vais continuer à apporter des améliorations à mon travail et si l'intégration te convient, je ferai le merge pour pouvoir remonter le code de mon fork vers la branche "newlocallab"

Pierre

[Desmis]

@Pandagrapher

Salut Pierre
Excellent travail, je dirais même plus super excellent...je suis époustouflé... tout est plus simple
Je n'ai pas tout testé, mais de mon point de vue comme tu n'as pas touché aux principes de l'algorithme dans iplocallab, tout doit fonctionner.....bien sûr à vérifier... :)

Il ne reste plus qu'à nettoyer le GUI des choses qui l'encombrent (les variables que j'utilisais pour contourner le problème) et le tour sera joué...

Je te laisse faire.

Si tu savais comme cela me satisfait...depuis plus de 2 ans maintenant que j'attends ce jour...

Merci et bravo

Jacques

[Floessie]

@Pandagrapher Salut Pierre. Great work. :+1: I browsed the diff and two things came to my mind:

1. You ran astyle on the files you changed, which is recommended. Regrettably, astyle is a bit dumb concerning C++11 uniform initialization and does more harm than good. So after an astyle run, it's an obligation to revert the places that look odd. That's still due in your branch as far I could see.
2. The locallab ProcParams layout shows its weakness in line 4492 et sqq.: This is extremely error-prone. Maybe consider to add a struct Spot (with c'tor and the two comparison operators) inside LocallabParams and have a single std::vector<Spot>. This would be a better data model, IMHO.

Seulement mes deux centimes (I know this is wrong :grin:),
Flössie

[gaaned92]

@Pandagrapher
On W64 and GCC 8.2.0, your branch builds and runs. uploaded at
https://keybase.pub/gaaned92/RTW64NightlyBuilds/Locallab_5.4-700-g757cf784_WinVista_64.zip

• It seems that your branch is very behind the dev branch. Could you update?
• I got some warnings

In file included from D:/RAWTHERAPEE/LL/Locallab/rtengine/dcrop.cc:30:
D:/RAWTHERAPEE/LL/Locallab/rtgui/md5helper.h:31:13: warning: 'std::__cxx11::string {anonymous}::getMD5(const Glib::ustring&)' defined but not used [-Wunused-function]
 std::string getMD5 (const Glib::ustring& fname)
             ^~~~~~

same here:

In file included from D:/RAWTHERAPEE/LL/Locallab/rtengine/improccoordinator.cc:29:
D:/RAWTHERAPEE/LL/Locallab/rtgui/md5helper.h:31:13: warning: 'std::__cxx11::string {anonymous}::getMD5(const Glib::ustring&)' defined but not used [-Wunused-function]
 std::string getMD5 (const Glib::ustring& fname)
             ^~~~~~

D:/RAWTHERAPEE/LL/Locallab/rtengine/iplocallab.cc: In function 'void rtengine::calclight(float, float, float&, bool, LUTf&)':
D:/RAWTHERAPEE/LL/Locallab/rtengine/iplocallab.cc:4845:68: warning: unused parameter 'inv' [-Wunused-parameter]
 static void calclight(float lum, float  koef, float & lumnew, bool inv, LUTf & lightCurveloc)
                                                               ~~~~~^~~
D:/RAWTHERAPEE/LL/Locallab/rtengine/iplocallab.cc: In member function 'void rtengine::ImProcFunctions::Lab_Local(int, int, int, LUTf&, LUTf&, LUTi&, LUTi&, float**, rtengine::LabImage*, rtengine::LabImage*, rtengine::LabImage*, int, int, int, int, int, const rtengine::LocretigainCurve&, LUTf&, const rtengine::LocLHCurve&, const rtengine::LocHHCurve&, bool&, bool&, LUTf&, bool&, LUTf&, bool&, LUTf&, LUTf&, LUTf&, LUTf&, LUTf&, double&, double&, double&, double&, double&)':
D:/RAWTHERAPEE/LL/Locallab/rtengine/iplocallab.cc:8041:47: warning: unused parameter 'maxspot' [-Wunused-parameter]
 void ImProcFunctions::Lab_Local(int call, int maxspot, int sp, LUTf & huerefs, LUTf & sobelrefs, LUTi & centerx, LUTi & centery, float** shbuffer, LabImage * original, LabImage * transformed, LabImage * reserved, int cx, int cy, int oW, int oH, int sk,
                                           ~~~~^~~~~~~
D:/RAWTHERAPEE/LL/Locallab/rtengine/iplocallab.cc:8041:71: warning: unused parameter 'huerefs' [-Wunused-parameter]
 void ImProcFunctions::Lab_Local(int call, int maxspot, int sp, LUTf & huerefs, LUTf & sobelrefs, LUTi & centerx, LUTi & centery, float** shbuffer, LabImage * original, LabImage * transformed, LabImage * reserved, int cx, int cy, int oW, int oH, int sk,
                                                                ~~~~~~~^~~~~~~
D:/RAWTHERAPEE/LL/Locallab/rtengine/iplocallab.cc:8041:105: warning: unused parameter 'centerx' [-Wunused-parameter]
 void ImProcFunctions::Lab_Local(int call, int maxspot, int sp, LUTf & huerefs, LUTf & sobelrefs, LUTi & centerx, LUTi & centery, float** shbuffer, LabImage * original, LabImage * transformed, LabImage * reserved, int cx, int cy, int oW, int oH, int sk,
                                                                                                  ~~~~~~~^~~~~~~
D:/RAWTHERAPEE/LL/Locallab/rtengine/iplocallab.cc:8041:121: warning: unused parameter 'centery' [-Wunused-parameter]
 void ImProcFunctions::Lab_Local(int call, int maxspot, int sp, LUTf & huerefs, LUTf & sobelrefs, LUTi & centerx, LUTi & centery, float** shbuffer, LabImage * original, LabImage * transformed, LabImage * reserved, int cx, int cy, int oW, int oH, int sk,
                                                                                                                  ~~~~~~~^~~~~~~



md5-08d4d19943d7d646c17ecce5f3c19c5e



D:/RAWTHERAPEE/LL/Locallab/rtengine/klt/klt_util.cc: In function 'void _KLTWriteFloatImageToPGM(_KLT_FloatImage, const char*)':
D:/RAWTHERAPEE/LL/Locallab/rtengine/klt/klt_util.cc:120:29: warning: argument 1 range [18446744071562067968, 18446744073709551615] exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=]
   byteimg = (uchar *) malloc(npixs * sizeof(uchar));
                       ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
In file included from C:/msys64/mingw64/include/c++/8.2.0/cstdlib:75,
                 from C:/msys64/mingw64/include/c++/8.2.0/stdlib.h:36,
                 from C:/msys64/mingw64/x86_64-w64-mingw32/include/assert.h:17,
                 from C:/msys64/mingw64/include/c++/8.2.0/cassert:44,
                 from D:/RAWTHERAPEE/LL/Locallab/rtengine/klt/klt_util.cc:6:
C:/msys64/mingw64/x86_64-w64-mingw32/include/stdlib.h:503:17: note: in a call to allocation function 'void* malloc(size_t)' declared here
   void *__cdecl malloc(size_t _Size);
                 ^~~~~~



md5-4b4ef3191c806e2b3150cbd9564a3856



In file included from D:/RAWTHERAPEE/LL/Locallab/rtengine/simpleprocess.cc:35:
D:/RAWTHERAPEE/LL/Locallab/rtgui/md5helper.h:31:13: warning: 'std::__cxx11::string {anonymous}::getMD5(const Glib::ustring&)' defined but not used [-Wunused-function]
 std::string getMD5 (const Glib::ustring& fname)
             ^~~~~~

• I didn't made tests. I just have some preliminary remarks if it can help:

  1. I don't understand the use of the 6 first sliders
  2. control spot: "status" is always "visible"; I did'nt find how to hide one control spot selectively. When right clicking on the display window, they all disappear, but status stay at "visible"
  3. when you select a control spot in right panel, the corresponding control point should be highlighted in display window
  4. "Color and light" function when opened, enlarge the sliders ; also "retinex". the right window becomes too narrow.
  • @Desmis I miss
  • the new RL sharpening and the new microcontrast by @heckflosse
  • local contrast, either the one from @agriggio or from the final touchup in wavelet
  • is the denoising function equivalent to the global one?

Jacques et Pierre, bon courage et merci à vous deux
André

[Desmis]

@gaaned92
we can do what we want from the moment everybody agree :)
In this case, I think first the goal is to make the new GUI work, then... merge in dev ???...when,? I hope in less than 2 years :)
Agorithm for local control are often different from general cases, and shape detection, will be in some cases difficult :)

After that we can perhaps add some functions.
I have not look but probably
i. is faisable
ii (local contrast) will be very difficult due to the place in the process, and wavelet very complex to implemented
iii. for me local denoise is better then general denoise

jacques

[Pandagrapher]

@Desmis
Thanks to your initial work too :) I really wanted this functionality: was so motivated to help you improving it ;)
I gonna start the code cleanup then I will start working on updating files to be able to merge my fork with "newlocallab" (will prevent you at beginning to stop merges from "dev" to "newlocallab")
By the way, you said me that noisechrodetail, sensiexclu and struc adjusters were used. In fact, they are by "Lab_Local" but GUI has no effect on them (are hidden to user and no updated some internal process). For the moment, i don't use the adjusters and, in "Lab_Local", their default values are hard coded in "calcLocalParams". Do I keep it like that?

@Floessie

1. Ok I will correct that (I had a blind trust on astyle :'()
2. I wasn't really satisfied on that part. Thanks for your idea, this will be better (and easier) using a struct vector. I had it to my list of improvements to code

@gaaned92
I have an important cleanup to perform on code (for instance, removing now useless LUT) and GUI. I gonna start cleaning code then will work on merging my fork with "newlocallab". Do you know a nice tool for that? (I am using Eclipse IDE with eGit plugin)

1. On old GUI, the 6 sliders were hidden and present for internal use: I now can remove them. It's the same for a slider and a curve in Retinex, for the two reset buttons (it's easier to remove then add a new curve to reset now)
2. It's not yet implemented (such as the ability to duplicate spot). It's on my list but I need to fix the unexpected behavior with right click
3. I agree
4. I can't reproduce what you said

Pierre

[gaaned92]

@Desmis Adding to my wishlist: use general mask (e.g. luminosity mask!) instead of shapes.
I understand that I will have to wait until present locallab is merged.

@Pandagrapher

I have an important cleanup to perform on code (for instance, removing now useless LUT) and GUI. I gonna start cleaning code then will work on merging my fork with "newlocallab". Do you know a nice tool for that? (I am using Eclipse IDE with eGit plugin)
As I have no experience in code development, I cannot help. ping @Hombre57 @heckflosse @agriggio

1. to reproduce:
   
   
   
   • open an image (SETM or METM)
   
   
   • activate local panel
   
   
   • close all functions (from color& light to Denoise): setting sliders are ok
   
   
   • open retinex function (no activation needed): size of "setting" sliders increase KO
   
   
   • open color & light function: size of sliders become far too large KO
   
   

André

[Beep6581]

@Pandagrapher

I gonna start cleaning code then will work on merging my fork with "newlocallab". Do you know a nice tool for that?

kdiff3 is your friend. Which OS do you use?

[Desmis]

@Beep6581
A question how merge 2 branches in 2 different forks with git
in normal configuration I use if I am in "newlocallab" ==> git merge dev
But here ?

@Pandagrapher
These variables have been create some time ago, and for various reasons I left this work in progress, so for now do not delete
I use kdiff3 and it is a good tool

@gaaned92
no problem to examine your requests, when the branch will have progressed and will be stabilized

[Beep6581]

@Desmis to the best of my understanding, here is the scenario:

• I created a repo on GitHub with RT code, and I gave you push access to it.
• When you cloned the RT code from this GitHub repo to your computer, this GitHub repo became the "origin" (which is "upstream").
• Every time you push, you are sending changes from your local git repo on your computer to this "origin" on GitHub.
• This "origin" is either [email protected]:Beep6581/RawTherapee.git or https://github.com/Beep6581/RawTherapee.git depending whether you cloned using SSH or HTTPS. You can check by typing git remote -v
• @Pandagrapher forked this RT GitHub repo to his own GitHub account to which he has full access. If you want to see his code, you need to add his repo as a "remote". The "remote" needs a name, so we will call it "panda" (you can call it anything). To add the remote and fetch a list of branches on his remote:
  git remote add panda https://github.com/Pandagrapher/RawTherapee.git git fetch panda
  For more info, see:
  https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes
  Or if you prefer French:
  https://git-scm.com/book/fr/v2/Les-bases-de-Git-Travailler-avec-des-d%C3%A9p%C3%B4ts-distants
• Once you added his repo as a remote and fetched his stuff, you can merge his newlocallab into your newlocallab. I assume you are currently inside your newlocallab branch. To merge his changes into your repo, and to fix the merge conflicts using kdiff3 as your "mergetool":
  bash git merge panda/newlocallab newlocallab git mergetool
• Once the merge conflicts are solved, compiled and tested, you can push the changes to the locallab branch in GitHub, same as always:
  bash git push

Hope it helps!

[Beep6581]

I just test-merged @Pandagrapher 's newlocallab into this newlocallab, it took less than 1 minute to solve the conflicts using kdiff3 (I won't push this, it was just a test). However, merging dev into newlocallab is quite more difficult and it needs your expertise to do it.

There are some functions with a lot of parameters making very long lines - it would probably make the code cleaner if those very long lines were split up into multiple lines.

[Beep6581]

KDiff3:
http://kdiff3.sourceforge.net/
How to set KDIff3 up as a git mergetool:
https://stackoverflow.com/questions/33308482/git-how-configure-kdiff3-as-merge-tool-and-diff-tool/33348841#33348841

[Pandagrapher]

@Beep6581
Thanks to all your explanations about merging :) (I am using Win10 64bits with MSYS2)

@gaaned92
Ok I reproduced it: I gonna fix it ;)

[Desmis]

@Pandagrapher
J'ai regardé plus en détail les 3 variables dont tu parles plus haut et "sensiexclu" est utilisé dans la version ancienne (non GUI) le locallab. Ce slider permet de tempérer l'action dans la zone d'exclusion d'action. A priori tu as du l'omettre.

@Beep6581
Thank you

@gaaned92
this should not be a problem for "RL deconvolution" (modification) and add "Local contrast" when it will possible :)

[Floessie]

@Beep6581 I edited your git HOWTO above and changed git remove -v into git remote -v.

There are some functions with a lot of parameters making very long lines - it would probably make the code cleaner if those very long lines were split up into multiple lines.

While a change won't help with this merge, there's some beauty in splitting long parameter lists. First and foremost, you realize that there are too many arguments (there's only a limited number of arguments which can be quickly passed in registers), so there is some pressure for OO modelling those parameters. Then there's the ability to merge more smoothly.

My rule of thumb is to split parameter lists with more than three parameters to one-param-per-line like so:

void fewParams(int a, int b, int c);

void manyParams(
    int a,
    int b,
    int c,
    int d,
    int e
);

[Beep6581]

Thank you @Floessie

[Pandagrapher]

@Desmis
Autant pour moi : "sensiexclu" est effectivement passé à la trappe... Du coup, je l'ai rajouté. Quant à "struc" et "noisechrodetail", je les ai remis fonctionnels mais ils sont par défaut cachés à l'utilisateur. Le jour où tu en auras besoin, il te suffira dé-commenter les lignes indiquées de la façon suivante :
// excluBox->pack_start(*struc_); // Uncomment this line to use the struc_ adjuster

Sinon, pour info, je suis toujours en train de nettoyer le code (très doucement, mais sûrement...)
Pierre

[Desmis]

@Pandagrapher
Pas de problèmes, prends ton temps :)

jacques

[Beep6581]

I merged dev into newlocallab, it compiled and ran fine.

[Desmis]

@Beep6581

Thank you

[Beep6581]

I merged dev into newlocallab and solved multiple conflicts. Compiled and ran fine, hope all is good.

[Beep6581]

Scratch that, I see @Desmis just did the same :smile: and my changes went into a new branch which I now deleted.

[Desmis]

@Beep6581
In french we say "les grands esprits se rencontrent"

Thank you :)

jacques

[Desmis]

@Pandagrapher

Salut
J'envisage, si tu n'y vois pas d'inconvénients ou d'objections, d'apporter quelques modifications à "locallab", ou alors préfères-tu que j'attende tes travaux
Ces modifications concernent iplocallab.cc, mais aussi, d'où ma demande, locallab.cc, en revanche controlspotpanel.cc n'est pas concerné.

Ces modifications portent sur :

• ajout du curseur "Contrast threshold" à "sharpening"
• ajout d'un module "Local Contrast"
  et plus délicat , peut être ajout d'un curseur "Dehaze" à Retinex
  J'en profiterais, peut être pour optimiser un peu "iplocallab.cc

Merci pour ta réponse, et par avance bonnes fêtes.

jacques

[Pandagrapher]

@Desmis
Salut Jacques,
Pas de problème à modifier locallab.cc
Pour ma part, j'ai pris du retard à développer ce sur quoi je travaillais avant mes vacances (des bugs et encore des bugs...). J'aurai plus de temps pendant les congés de fin d'année :)
Bonnes fêtes
Pierre

[Desmis]

@Pandagrapher

OK, merci
jacques

[Hombre57]

@Pandagrapher @Desmis

Comme l'a indiqué @lrq3000 :

By reading @Desmis, I understand locallab is rather a workaround than a core feature, but I would like to suggest if it is possible that locallab should be a core feature. What I mean by that, is that instead of duplicating submodules (color correction, exposition, vibrance, etc.) for locallab, locallab could instead be a global control of the interface, which redirects any RawTherapee module either on the "global" image, or any "local" control. This would have two advantages: first then all RawTherapee modules would be available also for local controls, and developer-wise it would avoid code (and effort) duplication. Of course, this suggestion is only possible if the way locallab provide local control is generic (can we apply any image processing algorithm on local controls, or do they need adaptation?).

et envisagé par @Pandagrapher :

1. Each locallab tool can be added one or several times and has one or more attached control point. It's close to how darktable works with masks.
   Pros: Especially to manage normal and exclusive control points in coherence with one tool, we won't need to verify we have the same parameters on this tool for both curves. But maybe this will require to update locallab engine

... la finalité sera de n'avoir qu'une seule fonction dans rtengine pour chaque outil (comme dans le dev actuel) mais qui fonctionne à la fois en global et en local (sans duplication de code donc). Plutôt que de faire 2 fois le boulot dans rtengine/procparams (comme proposé ici), pourquoi ne pas adapter directement les fonctions existantes pour que rtengine les réutilises autant de fois que nécessaire à chaque étape ? J'aimerais beaucoup qu'on parte sur de bonne base, et qu'on fasse des RT-Points un sélecteur de zone parmi d'autres à venir (et combinable entre eux), sinon je crains que le code soit compliqué à remodifier par la suite si on veut ajouter d'autres type de sélection de zone car il faudra faire une nouvelle modif massive.

Pour cela, je pense qu'il vaudrait mieux se concentrer sur le point n°4 du poste initial, càd perfectionner l'algo des RT-Points et adapter les algos de traitement actuels pour un usage "en boucle" basé sur un masque (ou global si le pointeur vers le masque est nullptr par exemple). Car c'est bien ce que génère les RT-Points ? Si non, comment intégrer les RT-Points à des masques ?

Question subsidiaire : les RT-Points peuvent-il par la suite utiliser des formes quelconques plutôt qu'ellipsoïde ? Si oui, il faut en tenir compte en créant les bonnes fondations dans procparams.

Enfin, concernant les outils eux-mêmes, autant ne conserver que les modes "sans artefacts", les utilisateurs ne se serviront de toutes façons pas d'outils qui en génère.

PS : @Desmis Je n'ai pas compris ce que tu as voulu dire ici :

It keeps the processing processes present in iplocallab, it must keep "normal" and "exclusive" control point, and also "duplicated".

[Beep6581]

I am very fond of the "Color toning - Regions" mask feature.

Can RT-Points eventually use any forms rather than ellipsoid?

This is just wishful thinking, but the Inkscape "freehand lines" tool can draw complicated shapes which, thanks to "smoothing", result in the use of just a few control points:

[Hombre57]

@Beep6581 That's basically what I had in mind :slightly_smiling_face:

[Desmis]

@Hombre57
Peut être est-il possible de modifier le code général pour pouvoir servir en local.
Quelquefois les modifications seront faibles dans d'autres cas non, par exemple denoise est très différent, ou Retinex est en mode Lab au lieu de RGB proche de demosaicing, l'échelle joue aussi...
Mais ce n'est pas rédhibitoire, cela peut être fait n'importe quand au fur et à mesure et cela ne doit pas être cela qui retarde l'avancement, peut être pas pour toutes les fonctions...car pour l'instant vu le temps que cela a pris, en gros 3 ans, les mises à jour le "locallab" auraient été très laborieuses!!.

Pour ce qui est de l'algorithme des RT-points...il y en a plusieurs, le principal étant la détection de forme (j'appelle cela comme je peux, ce n'est peut être pas le bon mot...).
J'ai apporté une nette amélioration il y a quelques mois, mais je n'ai eu aucun retour de l'équipe de développement.
J'ai essayé d'autres choses qui se sont avérées peu efficaces (Contrast threshold, Sobel Canny...)...
Bien sûr on doit pouvoir l'améliorer, les contributions sont les bienvenues.

Pour les masques, non les RT-points ne s'en servent pas, bien sûr dans certains cas ils pourraient apparaître (ex Retinex...), quand à intégrer l'algo aux masques pourquoi pas...mais quel intérêt sinon de faire un double système RT-point + système avec calques / masques comme Photoshop.

Pour ce qui est des formes des délimiteurs, il y a environ 1 an et demi, je t'ai dit qu'on pouvait mettre n'importe quelle courbe (en plus des ellipses et rectangles) à 2 conditions:
a) chaque portion doit se raccorder, sur les 4 points délimiteurs Gauche - Droit - Haut - Bas
b) chaque portion de courbe doit pouvoir subir une homothétie avec comme centre, le centre du point de contrôle. Au cours de cette homothétie, il ne faut pas que les courbes homothétiques se coupent.
Mais en termes de GUI je ne sais pas faire...là aussi les contributions sont les bienvenues.
De plus si l'algo de détection est très performant, cela devient de peu d'utilité...sinon dans des cas rares.

Les artefacts (rares) se produisent la plupart des cas, lorsqu'on est aux limites de l'algo de détection de forme. Si on améliore l'algo, plus d'artefacts...la dernière mouture a quasiment tout supprimé.

A noter que les 2 logiciels du commerce qui ont des points de contrôles (NXD dérivé des anciens U-points de NX2, et DxO, tous dérivés de NIk Software)) ne retouchent que des fonctions basiques (lightness, contrast, saturation, etc.) et sont "à part" au moins pour Dx0...

Les points de contrôles doivent avoir 3 caractéristiques globales:

• normal : c'est le point de contrôle de base, il peut combiner plusieurs parmi n'importe quelle des fonctionnalités actuelles ==> Color-Light, Exposure, Vibrance, Soft-light, Blur and noise, Tone Mapping, Retinex, Sharpening, Local contrast, CBDL, Denoise
• excluding : il a en théorie les mêmes fonctionnalités que "normal", mais il sert surtout à annuler l'effet pour certaines zones... c'est un point fondamental du système.
• duplicate : comme son nom l'indique, permet de dupliquer à un endroit donné les mêmes réglages qu'un autre spot (actuellement en attente du travail de @Pandagrapher )

Bien sûr il faut ajouter aussi mais cela semble évident : ajouter et supprimer...

@Beep6581 I will have a look for "Color toning Regions"

jacques

[Hombre57]

@Desmis Ok, merci pour ces réponses.

quand à intégrer l'algo aux masques pourquoi pas...mais quel intérêt sinon de faire un double système RT-point + système avec calques / masques comme Photoshop

Parce que les utilisateurs vont le demander (moi y compris) ; on peut espérer que les RT-Points soient très efficace, mais si on prend un cas concret : les RT-Points permettent-ils de sélectionner le ciel d'une photo de paysage qu'on voudrait sous-exposer, et si possible avec un effet dégradé et une détection de forme à ne pas toucher (arbres, bâtiments...) ? Cela nécessiterait sans doute un opérateur de sélection ad-hoc je suppose car la zone ne sera certainement pas elliptique. Ce ne serait peut-être pas des calques à proprement parler, mais des zones sur lesquelles appliquer des modifications particulières, comme les RT-Points mais avec une sélection plus basique et sans limitation quand à la géométrie. Et pour ça j'imagine qu'il faut passer par un système de masque. D'ailleurs si j'ai bien compris ton code, tes effets sont appliqués différemment selon que tu es dans la zone _effet total_ ou la zone _transition_. Un masque 8 bits (256 valeurs donc) peut servir à çà, non ? Si 256 valeurs ne suffisent pas, on peut prévoir un masque 16 bits.

J'ai aussi besoin d'une petite précision : le cercle au centre du RT-Point peut s'agrandir, mais je n'ai pas l'impression que cela soit suivi d'effet. À quoi correspond la taille de ce cercle ?

@Pandagrapher Je suis sur IRC (irc.freenode.net / #rawtherapee) ce soir, pouvons nous discuter du dev de la GUI sans rallonger ce fil déjà très long ?

[Desmis]

@Hombre57
Le système ne fonctionne pas comme cela...(tu raisonnes à la Photoshop... ce qui n'est pas une critique.. :)) le périmètre externe ne sert pas à délimiter quelque chose (on peut certes lui attribuer cette fonction, mais c'est aller à contre sens), mais à limiter dans l'absolu l'action. Au delà de cette limite il ne se passe rien. Entre les deux, le spot central qui est la "ref" (référence) - hue - chroma - luma (H, C, L) et la scène (zone d'image), l'algo - en fonction de "scope" (l'étendue) - va choisir les couleurs qui correspondent les plus proches de "ref".
Par exemple si tu sélectionnes le bleu du ciel (et pas les limites du ciel), l'algo va modifier (dans les limites définies) le ciel et toutes les couleurs proches, ignorant les bâtiments rouges ou bruns ...).

Si tu sélectionnes un vert dans un arbre (les feuilles), seules les feuilles seront modifiées et pas le ciel ni les branches derrières - sauf si tu agis sur scope...

Si tu as dans une image des feuilles vertes réparties sur l'image, avec des fleurs rouges et bleues...Si tu fais une grande sélection en ayant le pointeur sur un "vert", tous les verts seront retouchés sans impact sur les rouges et les bleus.

etc.

La transition sert "géographiquement" lorsque l'utilisateur veut créer soit un dégradé d'action, dans ce cas il choisira une valeur faible de "transition", soit juste assurer l'invisibilité d'une transition si on est dans une zone d'action de "scope", dans ce cas il choisit une valeur élevée...Mais en aucun cas cela ne ressemble à un masque.

Le cercle peut varier, et cela peut changer la valeur de "ref", si par exemple tu prends un arbre avec des feuilles avec le ciel derrière, si le cercle est grand la valeur de "ref" sera un mélange de bleu et vert...Donc dans ce cas intérêt d'un petit diamètre. Si tu prends un portrait (peau), les varaitions de peau peuvent être assez importantes, point noirs, acnés,... dans ce cas choisir un diamètre assez grand.

jacques

[Desmis]

@Hombre57
bien sûr je pourrais continuer longtemps....
Juste un dernier point. Lorsque malgré l'algorithme, il y a débordement ou bavures, cela se produit lorsque le deltaE (ou sur des parties de code pas optimisées la variation de hue) est trop faible, dans ce cas il faut utiliser "excludind spot" qui va reconstituer les couleurs d'origine...Mais là encore, pas de calques, pas de masques.... Certes on peut en ajouter, mais dans ce cas c'est pour faire du Gimp (ou Photoshop), ce qui n'est pas incompatible... enfin pas en même temps, mais dans ce cas, l'essentiel est la géographie, les limites du sujet à traiter, l'algo n'a rien à voir...

[Hombre57]

@Desmis

J'ai donc compris que le rectangle ou l'ellipse était une zone de recherche, mais ton algo va plus loin en déterminant une sélection automatique basée sur ce qu'il y a sous le cercle, un peu comme la fonction "baguette de sélection magique" de Gimp ou Photoshop (avec un algo différent derrière, on est d'accord). Du coup, au final, est-ce qu'on ne se retrouve pas avec un masque interne (que l'utilisateur ne verra jamais) dont se servent les algos de traitement ?

J'ai essayé de sur-exposer une image (pour avoir une partie basse correct) tout en essayant de conserver le ciel avec l'exposition initiale (voir les fichiers test ici). On voit que si on diminue l'exposition de la zone 1, des zones grises apparaissent. On vois aussi que les arbres verts sont touchés, donc donc le 2ème fichier pp3, je rajoute une zone d'exclusion, mais je vois que le ciel cyan est partiellement exclu lui aussi.

Pourrais-tu me renvoyer un fichier pp3 avec le bon traitement local pour ce cas de figure ?

Au passage, ce que je veux faire n'est possible que si on décoche la case Tronquer les valeurs hors gamut de l'outil Exposition principal. Je me demande si la modulation locale de l'effet ne serait pas plus efficace si cela modulait le traitement principal plutôt que de rajouter un traitement à postériori sur des zones potentiellement cramées ?

Lorsque tu auras fusionné les dernières modifs de @Pandagrapher, je ferais quelques modif dans locallab pour améliorer la manipulation du rectangle et de l'ellipse.

[Desmis]

@Hombre57
D'abord un oubli, la courbe autre que rectangle et ellipse doit avoir les caractéristiques suivantes
Si j'appelle H=Haut, B=Bas, G=Gauche, D=Droite la position du délimiteur et C=Centre le centre de la zone
On peut tracer 4 courbes différentes
Par exemple pour le coin supérieur droit qui correspond à un rectangle dont 2 côtés sont CH et CD
la courbe doit
1) passer par H et D
2) s'inscrire dans le rectangle dont 2 côtés sont CH et CD
3) dans l'homothétie de centre C, les diverses courbes ne doivent pas se recouper

[Desmis]

@Hombre57
Je ne sais pas si c'est un masque interne (je ne pense pas), car il n'y en a pas. Je vais essayer de réduire au maximum l'explication du traitement.
Il y a un document dans Rawpedia, mais pas à jour, néanmoins beaucoup de choses sont vraies
https://rawpedia.rawtherapee.com/Local_Lab_controls/fr
1) les 4 zones délimitées par HGBG sont indépendantes et correspondent chacune à un traitement séparé
2) l'ensemble du rectangle correspond à la zone où est appliqué l'algorithme (traitement "normal"...lorsque il y a "inverse", c'est le rectangle HGBG qui reste intact)
3) l'algo prend en référence ce qu'il y a dans le cercle et "en gros" en fonction du deltaE s'assure dans la zone délimitée par la courbe, de la proximité des couleurs. Plus c'est proche de "ref" plus on agit, plus c'est loin moins on agit. On peut agir sur la proximité de l'algo par "scope" uniquement sur Hue
Scope = 100 ==> 6,28 radians
Scope = 19==> en gros 1 radian (défaut)
4) ensuite "transition" joue son rôle...Il est géographique pour délimiter la zone principale. Si transition = 60, 60% de la zone maximale est concernée par l'algo ci-dessus, au-delà il y a progressivement réduction jusque 0, mais dans tous les cas on continue avec le deltaE et la comparaison
5) si on utilise un "excluding", la zone sélectionnée avec son "scope" et sa "transition" va ramener l'image originale

[Desmis]

@Hombre57
Pour ton image, j'ai fait comme je le sens...pour faire les réglages j'ai utilisé tes remarquables "lockable color picker"
1) ne pas toucher l'image originale
2) ajouter un spot sur la mer très large (elliptique ici, mais cela n'a pas d'importance)
3) agir sur "exposure" et "highlight compression"
4) pour l'arbre qui devient un peu trop lumineux,==> excluding spot en augmentant "scope" à 29

je joins le pp3
IMGP0129.PEF-Jac.pp3.txt

Bien sûr on peut faire autrement, avec d'autres spot, mais j'ai tenu a être pédagogique et montrer l'essentiel
J'ai même volontairement fait certains réglages légèrement inappropriés.. toujours à titre pédagogique

[Beep6581]

I don't recall it ever being listed what local editing is supposed to achieve. Here are my needs regarding local treatment:

1. Healing/cloning, mostly used to remove dust, skin imperfections, etc.
2. Dodge and burn with a brush, mostly used to add depth to a scene, e.g. a portrait, a mushroom or a landscape. This sort of thing (the light-colored strokes indicate dodging, the dark strokes burning):
   
   [Credits: Image from here]
   Complicated dodging and burning requires working with multiple layers and masks, but simple dodging and burning by shadows/mid-tones/highlights as in the example above covers most cases. This is not something you can practically do with anything other than a free brush. The brush strokes could of course be converted to a vector blob under the hood.
   
   [Credits: Mine.]
   
   [Credits: Mine.]
3. Adjust exposure/color using a mask which depends on a property of the image, e.g. make pink more red, make yellow less luminant, etc. This is mostly already achieved by the new Color Toning > Regions tool.

These are the standard things every photographer needs. I don't see a need for local retinex, local CIECAM02, local tone mapping, local CBDL, local denoise (the noise reduction tool already has curves to target a specific luminance), etc. It would be unfortunate if adding support for those three universal things was stifled by the difficulties in adding local editing support to those other tools.

[sguyader]

I mostly agree with Morgan, though I think that:

1. Local CBDL would help for skin smoothing. Currently, global CBDL restrained to a range of skin hues affects all the similar colors, which often happen in the background or in the model's clothes or props. Acting locally helps a lot.
2. Local denoise helps in some cases when for exemple noise is more obvious in some areas. I had such a case with musicians posing on stage under the stage LED lights, the red curtain showed more disturbing noise than the rest of the image (I had to use ISO 2500). If I could target heavier denoise to the curtain, that would be great.

[Pandagrapher]

@Desmis
Have you done working on locallab.cc ? If yes, I gonna start merging my work with branch newlocallab (my merge will also have impacts on improccoordinator.cc due to ProcParams locallab structure changes)

Ping @Hombre57

[Desmis]

@Pandagrapher
I am working on locallab.cc and iplocallab.cc, but no problem you can merge your work

And happy new year :)
Jacques

[Hombre57]

@Pandagrapher Nothing started yet, so go ahead.

[Pandagrapher]

@Desmis @Hombre57 Ok I start the merge

Happy new year :)
Pierre

[Desmis]

@Pandagrapher
J'ai compilé la version courante de ton développement (avant merge)
Tu dois avoir du boulot avec le merge !!! Si je peux t'apporter une aide ?

C'est remarquable, les bugs précédents (peut être à confirmer) sont supprimés, les fonctions "show/hide" et "duplicate" fonctionnent très bien, etc.

En cours : J'ai fait des modifications - pour l'essentiel sur iplocallab.cc - mais aussi évidemment sur locallab..cc et autres.... - que je voulais faire depuis longtemps

• optimisation par réduction du nombre de procédures dans iplocallab.cc (on a gagné quelques lignes ...plusieurs centaines de lignes de code...)
• vision à l'écran des modifications (je l'ai réalisé pour color and light, et exposure..., mais on peut le faire pour les autres...)

2 questions
a) les modifications dans iplocallab.cc ne concernent a priori de ce que j'ai vu que les appels à params par exemple params->locallab.shardamping.at(sp)
remplacé par
params->locallab.spots.at(sp).shardamping,
b) si je veux faire mes modifications (bien sûr après ton merge) est-ce que je dois les faire : a) dans ta branche ou b) dans celle principale de Beep6581 ? a) me semble préférable et évidemment je changerais aussi procparams et paramsedited

Merci encore

Jacques

[Pandagrapher]

@Desmis
Salut Jacques,

Tu dois avoir du boulot avec le merge !!! Si je peux t'apporter une aide ?

Effectivement mais, après 4h dessus hier, j'ai presque fini : il me reste locallab.cc à terminer et à traiter les conflits dans iplocallab.cc. Donc ça devrait aller pour terminer. J'aurai par contre besoin de ton aide pour tester le merge final :)

a) les modifications dans iplocallab.cc ne concernent a priori de ce que j'ai vu que les appels à params par exemple params->locallab.shardamping.at(sp)
remplacé par
params->locallab.spots.at(sp).shardamping,

Oui, c'est cela

b) si je veux faire mes modifications (bien sûr après ton merge) est-ce que je dois les faire : a) dans ta branche ou b) dans celle principale de Beep6581 ? a) me semble préférable et évidemment je changerais aussi procparams et paramsedited

L'intérêt d'avoir travaillé en priorité sur le batch mode à ce stade, c'est que maintenant je ne changerai plus les structures de procparams et paramsedited (ou changements mineurs). C'est donc comme tu préfères, mais on peut continuer de faire comme on fait actuellement : les merges seront maintenant plus faciles

Je vais continuer de travailler sur le merge cet après-midi : je devrai être capable d'envoyer une pull request aujourd'hui ou demain :)

Pierre

[Desmis]

@Pandagrapher
Salut Pierre

Pas de problèmes pour tester :)
Je pense que je ferais les modifications dans ta "branche", cela évitera les futures mises à jour de locallab.cc iplocallab.cc procparams.cc paramsedited.cc

Simplement à titre de rappel pour moi il suffit - si tu peux me confirmer - lorsque je suis dans
https://github.com/Pandagrapher/RawTherapee
de faire après :
git commit -m "blabla" -a
git push --set-upstream origin newlocallab
avec mon identifiant et mon mot de passe ?

jacques

[Desmis]

@Pandagrapher

Merci,
Je viens d'accepter ton invitation, et cela me dit
_You now have push access to the Pandagrapher/RawTherapee repository._

Donc, si j'entre mon identifiant et mot de passe pour Beep6581 cela devrait marcher je pense ?

jacques

[Pandagrapher]

@Desmis

Donc, si j'entre mon identifiant et mot de passe pour Beep6581 cela devrait marcher je pense ?

Je pense aussi (je n'ai jamais fait)

Pierre

[Desmis]

@Pandagrapher
On verra bien...mais il me faudra presque 1 journée pour faire mes modifications.
Jacques

[Pandagrapher]

@Desmis
J'ai terminé le merge. Quand je lance RT, j'obtiens deux erreurs du type Gtk-CRITICAL **: 17:36:26.870: gtk_box_pack: assertion '_gtk_widget_get_parent (child) == NULL' failed : les as-tu aussi dans la branche newlocallab ?

Pierre

[Desmis]

@Pandagrapher
j'ai exactement le même message dans Beep6581
jacques

[Desmis]

@Pandagrapher
Par contre je n'ai pas ce message avec d'autres branches que "newlocallab" (dev, cat02wb,...)
Donc il est lié probablement au GUI de newlocallab....

[Pandagrapher]

@Desmis
Ok : je ne les avais pas avant le merge donc ce n'est pas lié à mon merge. Je vais donc remonter le merge dans mon fork. Par ailleurs, j'ai trouvé un autre bug où des spots "fantômes" peuvent subsister sur le GUI. Je vais m'atteler à corriger ces deux bugs avant de faire ma pull request vers la branche

Pierre

[Desmis]

@Pandagrapher
Il y a aussi un autre bug qui était déjà présent avant. Lorsque tu cliques droit avec la souris, l'affichage de la zone disparaît...Il "suffit" de toucher une commande autre que dans locallab et réactiver "la main" et tout réapparaît

jacques

[Desmis]

@Pandagrapher
Je viens de "pull" ta branche.
La compilation se déroule sans problèmes.
A l'exécution on a le message "critical", mais comme avant.
Cela a l'air de fonctionner correctement, - examen rapide.

Demain
1) je vérifie que tout fonctionne
2) je fais mes modifications que je pense assez importantes....j'espère avoir fini demain soir.. car c'est dimanche (bon pas de problèmes d'emploi du temps, je suis retraité..., mais demain il y a la galette...et le coup de téléphone aux enfants et petits-enfants...)

Bonne soirée
Jacques

[Desmis]

@Pandagrapher
et bien sûr avant de commit et push, je t'avise :)

[Desmis]

@Pandagrapher
Je vais essayer de "commit" et "push" dans moins de 1 heure :)

Si je n'y arrive pas je t'adresse un patch

jacques

[Desmis]

@Pandagrapher
Finalement j'ai poussé rapidement et cela a l'air de bien fonctionner

jacques

[Desmis]

@Pandagrapher
Je prépare, pas sûr que cela fonctionne...et je ne sais pas encore comment je fais faire, la possibilité d'utiliser un masque (comme dans Colortoning) pour renforcer / atténuer l'effet des algorithmes de détection de forme dans locallab.
J'ai fait les changements nécessaires qui ont un impact sur ton travail (locallab, procparams, paramedited, procevents, refreshmap, curves,...) et a minima improccordinator, dcrop, simpleprocess.

Maintenant il ne me reste "plus qu'à" voir comment je vais adapter l'algo actuel....qui utilise déjà pas mal de trucs - il est essentiel fondé sur le deltaE, avec un rôle majeur pour Hue... pas évident...et pas évident que cela améliore...bref je verrais...

Merci encore pour ce remarquable travail que tu as accompli.

Jacques

[Pandagrapher]

@Desmis
Ok
Pour l’instant, je me focalise sur le crash que tu as remonté
Après n’hésite pas si tu as besoin que je travaille sur un point spécifique du GUI pour t’aider à mettre en place le masque :)

Par ailleurs, @Hombre57 souhaiterait apporter des améliorations sur la façon de manipuler les control spots sur l’image. Pour cela, il faudrait qu’à un moment on remonte nos modifications dans la branche

Pierre

[Desmis]

@Pandagrapher
Je viens de push un changement où l’utilisateur peut générer un masque sur la partie d'image qui va ensuite être modifiée par l'algo de détection de forme. Donc ce masque agit avant.

L'action se réalise en mode Lab (Lch) pour L et C
Le code est quelque peu différent de celui utilisé dans "Colortoning"... en fait c'est très simple.
a) pour le masque
b) pour intégrer ce supplément dans l'algorithme actuel

@Hombre57
Pour moi, pas de problèmes pour mettre à jour newlocallab dans Beep6581....il suffit de se mettre d'accord.

Jacques

[Desmis]

@Pandagrapher

Puisque l'on parle de GUI, ce serait un plus si dans la courbe C=f(C) la valeur de chromaref pouvait apparaître, et dans L=f(L) faire apparaître lumaref.
Cela aiderait l'utilisateur pour connaître les zones à affaiblir.

[Pandagrapher]

@Desmis
Hello Jacques,

To improve GUI for mask visibility, here what I have planned to change:

• Adding two toggle buttons (for Color & Light and Exposure) to enable mask use. With mask curves, these toggle buttons will be saved in .pp3
• The remaining combobox (for mask visibility options) won’t be saved in .pp3 and won’t disable Color & Light or exposure tool in GUI and in .pp3. The states of these combobox will be transmitted to improcoordinator and used to show mask on selected spot only (deactivation of Locallab tools according to spot visibility will be managed in improcoordinator). When a new pic is loaded, mask visibility will be reinitialized

What do you think about this behavior? Does it seem you correct?

Puisque l'on parle de GUI, ce serait un plus si dans la courbe C=f(C) la valeur de chromaref pouvait apparaître, et dans L=f(L) faire apparaître lumaref.
Cela aiderait l'utilisateur pour connaître les zones à affaiblir.

I was thinking about showing them using the same method than for histogram in exposure curves for instance. For instance, how to translate a chromaref value to show it in curves? (Horizontal grey zone with a specific value?)

Pierre

[Desmis]

@Pandagrapher
This is a very good solution.
No problem you can go on

Jacques

[Desmis]

@Pandagrapher

Salut
Je pense avoir terminé le changement d'algorithme de détection de formes. Maintenant quand je compare à l'équivalent dans Dx0 ou Capture NX2 ou NXD (U point), c'est au moins égal sinon meilleur...mais plus de sliders...

De plus j'ai regroupé tout ce qui pouvait être regroupé en termes de code.

Je vais m'attaquer à la documentation 'Rawpedia)... gros boulot.

Je souhaite - comme dans le menu principal", ajouter 1/1 à certaines rubriques - pour indiquer qu'il faut travailler à zoom 100% : Denoise, Sharp, CBDL, mais je ne sais pas faire !

Autre chose : on doit pouvoir, mais il n'y a pas le feu, améliorer "Structure" dans "Color and Light" et "Exposure"....cela viendra plus tard

De même on doit pouvoir si certains le souhaitent ajouter des masques à d'autres modules (pas difficile maintenant, il suffit de faire du "copier coller"), mais beaucoup de travail, qu'en penses-tu ?

Est-ce que tu consultes le forum PIXLS.US avec la rubrique locallab, les utilisateurs (certains) évoquent les problèmes (maintenant connus) du GUI ?

Je serais absent de vendredi matin, à lundi soir.

Amicalement

Jacques

[gaaned92]

De même on doit pouvoir si certains le souhaitent ajouter des masques à d'autres modules (pas difficile maintenant, il suffit de faire du "copier coller"), mais beaucoup de travail, qu'en penses-tu ?
Perhaps a stupid idea!
Shouldn't be simpler ( for user also) to apply the mask to all modules. And if we want an other mask for some module, we generate an other control point.
And also could we use mask generated by other modules ( depth mask, luminance mask...)

[Desmis]

@gaaned92
Je suis d'accord avec toi, au niveau de la simplicité, mais le masque tel qu'il est conçu, peut (doit) avoir des effets différents selon les modules...par exemple CBDL qui est un wavelet simplifié va réagir différemment de Color and Light.... on ne cherche pas la même chose, et si le masque est commun ce sera un effet "moyen"...Mais j'en prends note

[Pandagrapher]

@Desmis
Salut Jacques,

Je souhaite - comme dans le menu principal", ajouter 1/1 à certaines rubriques - pour indiquer qu'il faut travailler à zoom 100% : Denoise, Sharp, CBDL, mais je ne sais pas faire !

C'est pas instantané sur les MyExpander mais je vois comment faire : je l'ajoute à ma liste de modifications à faire

De même on doit pouvoir si certains le souhaitent ajouter des masques à d'autres modules (pas difficile maintenant, il suffit de faire du "copier coller"), mais beaucoup de travail, qu'en penses-tu ?

Oui, c'est bien cela : ça ne se résume plus qu'à des copier/coller maintenant que la philosophie est en place. Après je ne penses pas que ça demande beaucoup de travail (ce sera moins pire que de rajouter un paramètre en plus)

Est-ce que tu consultes le forum PIXLS.US avec la rubrique locallab, les utilisateurs (certains) évoquent les problèmes (maintenant connus) du GUI ?

Oui je le consulte de temps en temps. Suite à des remarques/suggestions, je me suis planifié les améliorations/corrections de bug suivantes pour les prochains jours :

• Faire en sorte d'afficher les chromaref etc. du point de contrôle en fond des courbes de masque (comme pour l'histogramme en fond des courbes d'exposition) plutôt que sur un label (ce sera plus pratique pour savoir comment placer les points des courbes de masque)
• Faire en sorte que l'historique gère des lignes différentes quand plusieurs points de contrôle sont ajoutés/supprimés consécutivement
• Faire en sorte d'indiquer visuellement sur le treeview quel point de contrôle on survole avec la souris
• Déplacer le paramètre avoid vers controlspotpanel
• Corriger le problème du "clic-droit" (à voir en fonction des améliorations que fera Hombre)

Est-ce que tu en vois d'autres ?

Pierre

[Desmis]

@Pandagrapher
Je pense que tu as fait le tour des modifications à faire, et à ce jour je n'en vois pas d'autres.
Merci encore pour ce "beau" travail

J'ai rédigé la documentation avec un petit chapitre GUI, si tu souhaites ajouter quelque chose (sur le GUI ou autre chose, ou modifier...), dis le moi, sauf si tu as l'autorisation d'écrire sur Rawpedia, dans ce cas, tu peux modifier

https://rawpedia.rawtherapee.com/Local_Lab_controls/fr

[Hombre57]

@Pandagrapher Attention avec les copier/coller, ça peut vite devenir galère s'il y a de la maintenance à faire. De quel code parles-tu ?

Corriger le problème du "clic-droit" (à voir en fonction des améliorations que fera Hombre)

J'attends toujours un top départ de vous deux pour commencer, j'ai du mal à suivre votre ping pong dans les commit ni quelle branche modifier (je suppose que c'est localisé).

[Desmis]

@Hombre57
Pas de problèmes, tu peux y aller dans la branche Beep6581::newlocallab
Celle-ci est à jour de toutes les modifications, celle de Pandagrapher sert de tests provisoire à son travail, du fait qu'il n'a pas les accès à Beep6581
Le ping pong est simple @Pandagrapher fait une modif sur sa branche, je la mets à jour dans Beep6581, les autres modifs tiennent à la mise à jour importante des algorithmes et n'ont que peu à voir avec le GUI

D'ailleurs avant de faire un commit je regardais si tu n'avais pas avancé quelque chose....problème de coordination.

En ce qui concerne les masques, l'idée de @gaaned92 se heurte (en dehors de programmer Controlspotpannel...) , 1) les données du masque devront être itératives, car par exemple color and light, modifie les données pour la suite; 2) il n'est pas évident - sauf pour améliorer la détection qu'il faille le même masque pour chaque module, 3) le masque d'un module X va modifier les données générales....
J'ai essayé de voir comment on pourrait faire pour fabriquer une procédure - si on veut accroître le nombre de rubriques avec masques - mais je me heurte aux passages de paramètres avec les 3 courbes, qui seraient différentes.
Aujourd'hui le problème ne se pose pas, il n'y en a que 2, avec des données de départ différentes et des courbes différentes.

[Hombre57]

@Desmis C'est noté, par contre mes modifs pourront fortement empiéter sur les tiennes @Pandagrapher . Mon but est de transférer un maximum de chose en interaction sur la prévisu, et donc potentiellement supprimer des choses que tu es en train de mettre en place (cela ne concerne pas la partie engine donc). Ne vaudrait-il pas mieux se coordonner en privé dans ce sens ?

[Pandagrapher]

@Hombre57

@Pandagrapher Attention avec les copier/coller, ça peut vite devenir galère s'il y a de la maintenance à faire. De quel code parles-tu ?

Le terme « copier/coller » est peut être maladroit. Il s’agit plus de reprendre la philosophie que j’ai introduite avec le commit fc6e4ce pour de nouveaux masques à introduire

Concernant les modifications que tu veux faire, je pense que les deux premiers points de mon « planning » peuvent être fait sans nous gêner. Mais en peu en rediscuter en priver pour se coordonner : quand serais-tu disponible ?

Pierre

[Desmis]

@Hombre57 @Pandagrapher

Hombre, je ne comprends pas très bien, tu dis que cela pourrait toucher mes modifications (ou alors ce sont celles de Pandagrapher ? ) Je pense pour la deuxième, car tu dis que "engine" n'est pas concerné.

Bref, je pense dans ce cas - mais je ne suis que peu concerné directement que votre travail en commun sur le GUI pourrait se faire sur la branche de @Pandagrapher

De plus j'ai fait deux modifications que je souhaiterais "commit" dans la branche Beep6581:newlocallab, y voyez-vous un inconvénient ?
jacques

[Hombre57]

Hombre, je ne comprends pas très bien, tu dis que cela pourrait toucher mes modifications (ou alors ce sont celles de Pandagrapher ? ) Je pense pour la deuxième, car tu dis que "engine" n'est pas concerné.

Oui je parlais de @Pandagrapher

Bref, je pense dans ce cas - mais je ne suis que peu concerné directement que votre travail en commun sur le GUI pourrait se faire sur la branche de @Pandagrapher

Je vais cloner le repos. de @Pandagrapher dans ce cas et créer de PR. Ce sera plus simple à gérer lorsqu'il faudra fusionner avec newlocallab je pense.

De plus j'ai fait deux modifications que je souhaiterais "commit" dans la branche Beep6581:newlocallab, y voyez-vous un inconvénient ?

Aucun

[Hombre57]

@Pandagrapher

quand serais-tu disponible ?

Je suis beaucoup en déplacement pour le boulot ces temps-ci. Le mieux serait de rester connecté sur IRC dans les moments de développement. Si j'y suis c'est le soir à partir de 21h ou le w.e. Aujourd'hui je devrais être sur IRC vers 17h

[Desmis]

@Hombre57 @Pandagrapher

Ok je vais "commit" mon changement
Remarque: je suis à la maison au lieu de "dans la famille" car je suis plus que patraque, attaqué par la grippe (atténuée avec le vaccin)

Jacques

[Hombre57]

@Desmis

Petit résumé de ma discussion avec @Pandagrapher sur IRC :

1. une nouvelle branche newlocallab-newGUI a été créé dans le repos de @Pandagrapher
2. cette branche recevra toutes mes modifs en vu d'un transfert de toute l'interface actuellement dans le panneau latéral vers la zone de prévisu, en contextuel.
3. cela nécessitera une amélioration de la classe Edit et de ses sous-classes. Ceci sera poussé dans dev. Comme c'est du code inutilisé par dev, cela ne portera pas à conséquence en terme de bug, mais complètera le framework permettant (2) et tous les outils ayant besoin d'une GUI poussée en édition "on-preview"
4. cette méthodologie permet de séparer les patch en patch plus petit comme le veut la charte de programmation. Cela nécessitera de faire un merge de dev dans Beep6581/newlocallab et de Beep6581/newlocallab dans Pandagrapher/newlocallab-newGUI régulièrement.
5. je vais d'abord m'atteler à utiliser un overlay Gtk pour dessiner les widgets dedans plutôt que de les dessiner sur l'image de sortie comme actuellement. Cette modif sera faite dans dev et sera nécessaire pour (2)

[Desmis]

@Hombre57 @Pandagrapher

OK, merci pour l'info,
Nota : je viens de faire un additif pour le calcul des références (dans improccoordinator) - utile dans certains cas.

jacques

[heckflosse]

@Desmis Jacques, I just merged dev into newlocallab localy. May I push?

[heckflosse]

@Desmis I just saw you have been faster

[Desmis]

@heckflosse

Ingo
The older we get, the faster we are :)

jacques

[gaaned92]

• Is it intended to merge some features of autowblocal in newlocalab?

[Thanatomanic]

@Desmis @Pandagrapher Congratulations on the merge into dev!
Can you comment on this issue: should we close and start a fresh new list?

[Thanatomanic]

@Desmis Since the number of PR's and new additions to the functionalities of Local Adjustments keep coming at a steady pace, could you please give an update on your plans? What new things would you still like to implement or improve?
Or, put differently, what is the status of all the things mentioned in the original post of this issue? Can we close and start a new list?

[Desmis]

@Thanatomanic
After this Pull-Request on "log encoding", for me, except for bugs or bad behavior (PR #5981), it's over.
There is still the work started by Ingo on denoise, but it has been postponed to 6.0

:)

jacques

[Thanatomanic]

Thank you for the update! It's good to hear that the end is near, that brings the 5.9 release a good deal closer 😄

[heckflosse]

@Desmis @Thanatomanic

As soon as Jacques' work is completed I will continue work on dehaze_blend branch to add dehaze blend also to the local adjustments. I just waited with that to avoid merge conflicts with Jacques' open pull requests.

[Desmis]

@heckflosse @Thanatomanic

I will merge the 2 PR "Local adjustments" tomorrow...
1) the second is only GUI problems
2) the first is an improvment of Log_encoding...with main GUI, a little of Ciecam, and mask... but no revolution...just more easy to use...

Jacques

[lrq3000]

@Desmis Thank you very much for your amazing work and inspiring dedication, that's an incredible achievement! Do you have a donation page? I would like to modestly retribute you for your work :-)

[Desmis]

@lrq3000

Thank you very much for these compliments :)

I do this to distract myself (I'm retired...and no longer very young...) and in no way to gain anything, except the pleasure of a product that works and satisfies the users.

if you wish to make a donation to Rawtherapee, I don't know how to do it !

Thank you again

Jacques

[Desmis]

@heckflosse @Thanatomanic

The 2 PR are now merge :)

Thank you

Jacques

[Thanatomanic]

I guess that means that this roadmap is currently ended and we can close this issue. Thank you @Desmis !