LR4 - inversion de "masque" ?

[Christophe Mely]

Bonjour,

Une petite question que je me trimballe depuis quelques jours : quand on utilise l'outil "Pinceau réglage" pour sélectionner une zone de l'image, est-il possible d'inverser ensuite cette sélection pour sélectionner l'autre partie de l'image ?

Merci 

[kaf]

Pas à ma connaissance mais... pour faire quoi exactement?

[Pat91]

Bonjour,

Non, on ne peut pas... parce qu'il ne s'agit pas d'un masque.

N'oublions pas que quand on décrit une zone de retouche locale, on stocke quelque part un ensemble d'informations décrivant la zone "peinte". On ne crée pas une image bitmap superposable à l'image originale, comme dans Photoshop (dans ce cas, l'inversion est une opération simplissime). Le mode de description utilisé n'est pas aisément "inversible". Ne serait-ce que parce que la zone de contour progressif se décrit dans une seule direction. Ensuite, si l'inversion était possible, il faut se rendre compte que la quantité de données générée par cette inversion serait inversement proportionnelle à la taille de la zone "masquée" : plus la zone masquée serait petite, plus il faudrait de données pour décrire la zone inversée. Ce que Lightroom n'aime pas du tout : cela aurait un impact immédiat sur les performances.

On pourrait imaginer de barbouiller la totalité de l'image et effacer ensuite la zone où l'on ne veut pas que le masque s'applique. Mais cela ne fonctionnera pas bien pour la raison citée plus haut : le contour progressif ne sera pas calculé dans le bon sens. Je ne parle même pas de l'automasquage.

[kaf]

Bonjour,

Non, on ne peut pas... parce qu'il ne s'agit pas d'un masque.

N'oublions pas que quand on décrit une zone de retouche locale, on stocke quelque part un ensemble d'informations décrivant la zone "peinte". On ne crée pas une image bitmap superposable à l'image originale, comme dans Photoshop (dans ce cas, l'inversion est une opération simplissime). Le mode de description utilisé n'est pas aisément "inversible". Ne serait-ce que parce que la zone de contour progressif se décrit dans une seule direction. Ensuite, si l'inversion était possible, il faut se rendre compte que la quantité de données générée par cette inversion serait inversement proportionnelle à la taille de la zone "masquée" : plus la zone masquée serait petite, plus il faudrait de données pour décrire la zone inversée. Ce que Lightroom n'aime pas du tout : cela aurait un impact immédiat sur les performances.

On pourrait imaginer de barbouiller la totalité de l'image et effacer ensuite la zone où l'on ne veut pas que le masque s'applique. Mais cela ne fonctionnera pas bien pour la raison citée plus haut : le contour progressif ne sera pas calculé dans le bon sens. Je ne parle même pas de l'automasquage.

Et cela ne répond pas à ma question, pourquoi vouloir inverser un masque dans LR?
J'ai beau y réfléchir, ça ne m'est jamais arrivé d'avoir envie de faire ça. Je pense qu'on est à la frontière entre ce qui doit être réalisé en bitmap et ce qui peut l'être en paramétrique.

[Pat91]

Et cela ne répond pas à ma question, pourquoi vouloir inverser un masque dans LR?

Oui mais ce n'est pas à vous que je répondais... 

Je conçois fort bien que dans le cas où la zone à masquer est importante, on veuille "masquer" la zone résiduelle de surface beaucoup plus réduite et inverser ensuite le résultat. Cela va beaucoup plus vite et c'est une pratique assez courante. Mais encore une fois, en paramétrique, cela pose des problème d'enregistrement des données. Je peux imaginer des solutions techniques (comme le marquage de la zone "masquée" comme devant être inversée mais je pressens que cela pourrait compliquer/alourdir les choses en termes de calcul - et Lightroom n'a pas besoin de cela en l'état actuel des choses).

[kaf]

Oui mais ce n'est pas à vous que je répondais... 

On est bien d'accord, c'est juste une interrogation "en passant" :-)

Je conçois fort bien que dans le cas où la zone à masquer est importante, on veuille "masquer" la zone résiduelle de surface beaucoup plus réduite et inverser ensuite le résultat. Cela va beaucoup plus vite et c'est une pratique assez courante.

Justement, pour moi, on a loupé quelque-chose dans le développement si l'on doit faire ça. Si une grande partie de l'image est à revoir au pinceau, il est plus logique, en paramétrique, d'appliquer cette révision à toute l'image (avec les paramètres de développement normaux, hors retouche locale donc) et à revoir au pinceau la petite zone qui est alors devenue incorrecte. Je ne sais pas si ce que je raconte est clair

Par exemple, une photo de paysage avec un petit bout de ciel et beaucoup d'ombre. Il y a de grandes chance que, si on développe pour le ciel, les ombres soient enterrées. Il est plus logique de développer pour les ombres et de faire redescendre le ciel localement, que de développer pour le ciel et de remonter les ombres au pinceau. Non?

Mais encore une fois, en paramétrique, cela pose des problème d'enregistrement des données. Je peux imaginer des solutions techniques (comme le marquage de la zone "masquée" comme devant être inversée mais je pressens que cela pourrait compliquer/alourdir les choses en termes de calcul - et Lightroom n'a pas besoin de cela en l'état actuel des choses).

Tout à fait d'accord

[Pat91]

Justement, pour moi, on a loupé quelque-chose dans le développement si l'on doit faire ça. Si une grande partie de l'image est à revoir au pinceau, il est plus logique, en paramétrique, d'appliquer cette révision à toute l'image (avec les paramètres de développement normaux, hors retouche locale donc) et à revoir au pinceau la petite zone qui est alors devenue incorrecte. Je ne sais pas si ce que je raconte est clair

Absolument. Je pense cependant qu'il doit y avoir des cas où cette stratégie ne va pas fonctionner. C'est très clair s'il n'y a qu'une seule zone masquée mais cela peut devenir un peu plus compliqué s'il y en a plusieurs : effets de bord et interactions possibles entre les zones de retouche locale.

N'oublions pas non plus que les nouveaux algorithmes de réglage des tons de LR4 prennent en compte la globalité de l'image : ils n'ont plus de "valeur absolue" mais agissent de manière différenciée selon l'aspect général de l'image. D'où une autre question qui n'a pas encore été évoquée jusqu'ici : prennent-ils en compte une retouche locale existante ? Ou dit autrement : est-ce qu'une correction globale (Expo, Tons clairs, Tons sombres, etc.) prend en compte une correction locale existante et quid s'il y a modification de la retouche locale après coup ?

[kaf]

N'oublions pas non plus que les nouveaux algorithmes de réglage des tons de LR4 prennent en compte la globalité de l'image : ils n'ont plus de "valeur absolue" mais agissent de manière différenciée selon l'aspect général de l'image. D'où une autre question qui n'a pas encore été évoquée jusqu'ici : prennent-ils en compte une retouche locale existante ? Ou dit autrement : est-ce qu'une correction globale (Expo, Tons clairs, Tons sombres, etc.) prend en compte une correction locale existante et quid s'il y a modification de la retouche locale après coup ?

Remarque pertinente et bonne question, je n'ai jamais rien vu à ce sujet nulle part!

À mon avis non, les retouches locales ne sont pas prises en compte par les réglages globaux. Algorithmiquement parlant, cela déboucherait immanquablement sur des récursions infinies dont il serait difficile de se débarrasser. Et photographiquement parlant, il parait logique qu'une fois les réglages effectués sur l'image entière, en coup de pinceau ne viennent pas modifier ces derniers. Par contre, il est probable que les algorithmes utilisés pour les réglages locaux tiennent compte des bordures extérieures du masque et s'y adaptent. 

Pas simple à démontrer en tout cas

[JEANPAUL]

.../ Par exemple, une photo de paysage avec un petit bout de ciel et beaucoup d'ombre. Il y a de grandes chance que, si on développe pour le ciel, les ombres soient enterrées. Il est plus logique de développer pour les ombres et de faire redescendre le ciel localement, que de développer pour le ciel et de remonter les ombres au pinceau. Non? /...

Le problème du ciel pour ma part je le corrige localement, en utilisant le mode TSL Saturation non depuis les curseurs mais en positionnant l'outils (la "petite croix") sur la zone d'ombre et en saturant ou désaturant...

[Pat91]

Algorithmiquement parlant, cela déboucherait immanquablement sur des récursions infinies dont il serait difficile de se débarrasser.

Exact. Ah, heureusement que j'ai fait voeu de ne plus replonger dans les problèmes de codage. Le dernier projet R&D dont je me suis occupé a nécessité la "dérécursification" de la quasi totalité des algorithmes. Nous avions atteint un niveau de récursion tel que la pile explosait systématiquement. J'ai d'ailleurs été surpris de constater que quasiment tous les algorithmes peuvent faire l'objet d'une dérécursification. C'est juste notre mental qu'il faut adapter.

Ceci étant, il y a probablement une solution technique mais qui demandera de la puissance. On en reparlera quand LR10 sera sorti et que nos PCs seront équipés de processeurs qui ressembleront à la CPU réfrigérée d'un 3090 avec des tuyaux partout et un plombier à domicile.

[kaf]

Exact. Ah, heureusement que j'ai fait voeu de ne plus replonger dans les problèmes de codage. Le dernier projet R&D dont je me suis occupé a nécessité la "dérécursification" de la quasi totalité des algorithmes. Nous avions atteint un niveau de récursion tel que la pile explosait systématiquement. J'ai d'ailleurs été surpris de constater que quasiment tous les algorithmes peuvent faire l'objet d'une dérécursification. C'est juste notre mental qu'il faut adapter.

Si je me souviens bien de mes cours d'algorithmique (ça date un peu quand même), tous les algorithmes récursifs peuvent être convertis en itératif. C'est juste parfois très très compliqué

Ceci étant, il y a probablement une solution technique mais qui demandera de la puissance. On en reparlera quand LR10 sera sorti et que nos PCs seront équipés de processeurs qui ressembleront à la CPU réfrigérée d'un 3090 avec des tuyaux partout et un plombier à domicile.

Seul l'avenir nous le dira

[olivierrychner]

Bonjour!

Et cela ne répond pas à ma question, pourquoi vouloir inverser un masque dans LR?
J'ai beau y réfléchir, ça ne m'est jamais arrivé d'avoir envie de faire ça. Je pense qu'on est à la frontière entre ce qui doit être réalisé en bitmap et ce qui peut l'être en paramétrique.

Le souffreteux que je suis en ce qui concerne l'informatique (voir mon post récent dans cette section) est aussi d'avis que la question était influencée par les programmes similaires à PS/CS: dans certains cas, une selection au pinceau, dans ces éditeurs bitmap, est plus rapide faite "à l'envers" que directement, en sélectionnant la zone à préserver (petite) puis en inversant pour qu'au final, on travaille sur le reste... mais je ne sais si je m'exprime correctement. Mes travaux d'histoire attendent mes corrections, alors je vous laisse entre vous

Olivier

[kaf]

Bonjour!

Le souffreteux que je suis en ce qui concerne l'informatique (voir mon post récent dans cette section) est aussi d'avis que la question était influencée par les programmes similaires à PS/CS: dans certains cas, une selection au pinceau, dans ces éditeurs bitmap, est plus rapide faite "à l'envers" que directement, en sélectionnant la zone à préserver (petite) puis en inversant pour qu'au final, on travaille sur le reste... mais je ne sais si je m'exprime correctement. Mes travaux d'histoire attendent mes corrections, alors je vous laisse entre vous

Olivier

On est bien d'accord. Mais quand, dans un logiciel de développement, on en arrive à sélectionner une grande partie de la photo pour la modifier localement (ce mot n'a d'ailleurs plus vraiment de sens dans ce cas), c'est qu'on a loupé quelque-chose dans le développement initial

[Pat91]

dans certains cas, une selection au pinceau, dans ces éditeurs bitmap, est plus rapide faite "à l'envers" que directement, en sélectionnant la zone à préserver (petite) puis en inversant pour qu'au final, on travaille sur le reste... mais je ne sais si je m'exprime correctement.

Si, si. On a bien compris l'intention mais on explique justement qu'en paramétrique, ce n'est pas fait pour. Donc facile à mettre en oeuvre sous Photoshop mais pas sous Lightroom.

[kaf]

Si, si. On a bien compris l'intention mais on explique justement qu'en paramétrique, ce n'est pas fait pour. Donc facile à mettre en oeuvre sous Photoshop mais pas sous Lightroom.

D'autant que, selon moi (c'est mon avis et je le partage ), on ne devrait pas arriver devoir faire ce genre de sélection dans un logiciel de développement, quel qu'il soit

[Pat91]

D'autant que, selon moi (c'est mon avis et je le partage ), on ne devrait pas arriver devoir faire ce genre de sélection dans un logiciel de développement, quel qu'il soit

Il y a des situations où si, quand même... Exemple:

J'ai une photo récente qui contient une zone bleue de faible surface à laquelle je ne veux pas toucher. Par contre, je veux jouer sur la saturation des "autres bleus" très répartis et très présents dans tout le reste de la photo. La solution serait donc de masquer la zone bleue que je ne veux pas affecter, d'inverser le masque et d'agir sur les bleus dans le reste de la photo (puisque LR4 me permet maintenant d'agir localement sur la saturation).

On peut comme indiqué plus haut, effectuer la correction souhaitée globalement sur toute l'image et ensuite corriger l'effet de cette correction sur la zone qui ne doit pas être affectée en compensant l'effet global par une correction locale. Je ne suis pas sûr que cela donne le même résultat et c'est moins simple.

[kaf]

On peut comme indiqué plus haut, effectuer la correction souhaitée globalement sur toute l'image et ensuite corriger l'effet de cette correction sur la zone qui ne doit pas être affectée en compensant l'effet global par une correction locale. Je ne suis pas sûr que cela donne le même résultat et c'est moins simple.

C'est à essayer, et c'est à coup sûr la direction dans laquelle je partirais naturellement Je n'aurais peut-être même pas penser au "tout sélectionner sauf" en fait

[Christophe Mely]

Déjà merci pour les réponses...ça a fusé pendant que je suis allé déjeuner !!

Ensuite pour répondre à Kaf, dont je sens que ma question l'a plongé dans un abîme de perplexité  :

Supposons une fleur toute seule, sur un fond plus ou moins uni (en fait un flou d'arrière - plan) et une envie subite de désaturer complétement le fond sauf la fleur. C'est plus rapide de sélectionner la fleur puis d'inverser le "masque" que le contraire.

Ensuite quel que soit la valeur de l'exemple ci-dessus, à partir du moment où l'on peut sélectionner la zone sur laquelle on veut appliquer un effet, il me paraissait logique de me poser la question de savoir si l'on pouvait également sélectionner la zone sur laquelle on ne veut pas appliquer un effet.

Concernant la question du "pourquoi pas ne pas utiliser aussi un logiciel de retouche", la réponse est simple  en ce qui me concerne : je n'en n'ai pas envie et je veux me limiter qu'à ce que peux me proposer mon logiciel de développement, en l'occurence LR. On verra plus tard, dans quelques années, quand je saurais faire des photos, peut-être franchirais-je ce cap.

Mais pour le moment, Lightroom étant devenu très puissant dans ses capacités de "developpement", de fait il ouvre la voie à une démarche créative très poussée. Plus en tout cas que ce que ne le suppose au départ la "simple" notion de développement. Même s'il n'est pas conçu pour "ça" au début, Lightroom permet de "créer" (d'un point de vue artistique) en plus de "développer" (d'un point de vue purement "technique"), même si les deux sont très proches (mais là n'est pas la question).

[kaf]

Effectivement, dans ce cas, la seule solution dans LR pour le moment est des barbouiller toute l'image et de désélectionner la fleur avec le pinceau de désélection. Ce n'est pas très joli et peut avoir des conséquences fâcheuses sur les performances, mais il n'y a pas d'autre possibilité pour y parvenir. Mais pour en revenir à ce que j'ai dit tout à l'heure, on est à la limite de ce qu'un logiciel de développement paramétrique peut faire. Pour ma part, je passerais très certainement pas un logiciel bitmap pour ce genre chose

[Christophe Mely]

Mais pour en revenir à ce que j'ai dit tout à l'heure, on est à la limite de ce qu'un logiciel de développement paramétrique peut faire. Pour ma part, je passerais très certainement pas un logiciel bitmap pour ce genre chose

En même temps, vous admettrez quand même que Lightroom repousse pas mal les limites de ce que l'on peut faire en paramétrique !
C'est encore un complot d'Adobe ça !!!

[kaf]

En même temps, vous admettrez quand même que Lightroom repousse pas mal les limites de ce que l'on peut faire en paramétrique !

Tout à fait! Mais la frontière n'est pas évidente à trouver entre ce qui doit se passer dans LR et ce qui doit se faire en bitmap. Et plus LR avance, moins la limite est claire. Au début c'était facile, on développait dans LR, et on faisait tout le reste en bitmap. Maintenant, il est fréquent (pour moi en tout cas) de développer dans LR, puis de retoucher dans CS pour finir par réappliquer certains paramètres dans LR par la suite.

C'est encore un complot d'Adobe ça !!!

Sûrement

[kaf]

On peut comme indiqué plus haut, effectuer la correction souhaitée globalement sur toute l'image et ensuite corriger l'effet de cette correction sur la zone qui ne doit pas être affectée en compensant l'effet global par une correction locale. Je ne suis pas sûr que cela donne le même résultat et c'est moins simple.

Je viens de faire un petit essai, il vaut ce qu'il vaut, mais me semble rassurant.

Deux copies de la même photo:
- Sur la première, je pousse la saturation de l'orange à +50.
- Sur la seconde
   1° Je réduis la saturation de tout sauf l'orange à -50 (en laissant cette dernière à 0).
   2° Au pinceau, je barbouille toute l'image et j'augmente la saturation localement à +50.

J'envoie les deux images vers PS (avec les modifications de LR évidemment), je les empile en mode différence et... je vois qu'en pratique, le résultat est identique.

[Christophe Mely]

Je vais essayer ce soir avec ma photo de fleur, pour voir 

Merci en tout cas à Kaf et à Pat91 pour les infos et pour les pistes...

J'ai pas encore tout bien compris les histoires de récursivité infinie à double boucle itérative, mais en même temps, je n'en n'ai peut-être pas trop besoin pour le moment pour développer mes photos ... si ...

[Pat91]

Tout à fait! Mais la frontière n'est pas évidente à trouver entre ce qui doit se passer dans LR et ce qui doit se faire en bitmap.

Je crois que la limite est la manière dont les opérations peuvent être décrites et la quantité de données que cela génère. Décrire un éclaircissement général de l'image ou un redressement vertical se fait en quelques octets. La description de l'action se stocke donc rapidement et peut se relire très vite.

Décrire une retouche locale demande la description d'une surface de forme aléatoire avec une application qui n'est pas binaire (selon la densité choisie). C'est déjà beaucoup de données pour une petite surface, c'est beaucoup trop pour une surface importante. En fait, si on regarde le contenu d'un XMP contenant une retouche locale, on s'aperçoit que la description du "masque" est quand même assez grossière. Ce n'est pas un reproche, on comprend pourquoi et c'est déjà bien que cela soit possible (ni DxO, ni DPP ne proposent cette fonction). Bibble le faisait mais d'une manière qui peut également se discuter. Cela n'ira donc pas beaucoup plus loin tant qu'une étape supplémentaire ne sera pas franchie sur la puissance des CPU et la formalisation de ces descriptions. Le XMP est du XML : c'est incroyablement pratique et universel mais l'insertion et l'extraction de données dans un document XML est par nature d'une lenteur rédhibitoire.

A contrario, l'opération consistant à superposer et à combiner 2 bitmaps en mémoire est une opération système, indépendante du logiciel, se décrivant à l'aide quelques paramètres et effectuée en 2 ou 3 lignes de code maximum.

PS : Du coup, j'ai eu la curiosité de vérifier dans la base de données Lightroom comment étaient stockées les descriptions de corrections, en particulier pour les masques. La réponse est très surprenante : comme dans les fichiers XMP. C'est du texte. On pouvait sûrement imaginer plus efficace avec un stockage dans des champs binaires, plus faciles à réinterpréter. Pour les curieux, c'est dans le champ "text" de la table "Adobe_imageDevelopSettings".

[ambre099]

Quand tu utilises le pinceau sur LR tu as tout intérêt à cocher la case masquage automatique et si tu veux inverser ton pinceau appuye sur la touche alt ou option du clavier, ton pinceau se transforme alors en gomme