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

[THG]

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".

Ben oui c'est du texte, on l'a toujours dit. Dans Aperture, c'est une pile de fichiers TIFF cachés dans les méandres du système.

[kaf]

J'en remets une couche, limite hors sujet mais intéressant à remarquer tout de même. Gilles, si tu nous lis et peux nous éclairer...

Alors, si je peins sur toutes l'image avec comme paramètre saturation: +100, et que dans la partie Présence je positionne la saturation générale sur -100, mon image reste désespérément n&b. Par contre, si je mets tous les curseurs de saturation dans la partie TSL à -100 à la place d'utiliser le curseur dans Présence, là, ma photo retrouve ses couleurs. Bizarre non? Le même phénomène se produite avec clarté d'ailleurs.

Conclusion: certains paramètres sont appliqués avant les retouches locales, et d'autres après. Existe-t-il quelque-part une documentation à ce sujet? Même si ça ne doit pas souvent avoir beaucoup d'influence en pratique, c'est toujours bon à savoir

[Pat91]

Ben oui c'est du texte, on l'a toujours dit.

Ce qui n'est pas une justification : faire le constat répété d'une erreur ne corrige pas l'erreur . Ce point m'avait totalement échappé. Je trouve ça assez farfelu (mais je suis à l'écoute d'autres avis de développeurs). Ceci implique que :

- Quand les valeurs des paramètres sont stockées dans la BD (ce qui arrive à chaque modif ou presque), on convertit l'ensemble des paramètres courants (binaires) en texte avec tout ce que ça implique comme opérations coûteuses en temps, surtout si des corrections locales sont actives. En effet, le champ "text" contient d'un seul tenant l'ensemble des réglages sous forme de script. La mise à jour séparée de chaque paramètre est donc impossible.

- Quand on va chercher les infos de correction dans la BD, il faut charger le texte en entier et le passer dans un parseur (disons un interpréteur) qui va reconvertir ce texte en un lot de données binaires qui seront stockées dans des variables du programme.

- Le code de l'application est lui-même écrit dans un langage interprété.

Que l'on m'excuse si j'émets une fois de plus une critique (amicale mais fondée) : cela ne va pas du tout dans le sens de la recherche de performances. Personnellement, je n'aurais jamais fait un choix de ce type dans une application qui a de toute évidence besoin d'éviter toute charge superflue de la CPU. Cela me paraît totalement contre-productif et me laisse vraiment pantois. Je n'avais jamais songé à vérifier ça tant il me paraissait évident que ces infos étaient stockées en binaire dans la BD.

À moins qu'une raison majeure m'échappe. Auquel cas, merci de m'informer.

[kaf]

Ce qui n'est pas une justification : faire le constat répété d'une erreur ne corrige pas l'erreur . Ce point m'avait totalement échappé. Je trouve ça assez farfelu (mais je suis à l'écoute d'autres avis de développeurs). Ceci implique que :

- Quand les valeurs des paramètres sont stockées dans la BD (ce qui arrive à chaque modif ou presque), on convertit l'ensemble des paramètres courants (binaires) en texte avec tout ce que ça implique comme opérations coûteuses en temps, surtout si des corrections locales sont actives. En effet, le champ "text" contient d'un seul tenant l'ensemble des réglages sous forme de script. La mise à jour séparée de chaque paramètre est donc impossible.

- Quand on va chercher les infos de correction dans la BD, il faut charger le texte en entier et le passer dans un parseur (disons un interpréteur) qui va reconvertir ce texte en un lot de données binaires qui seront stockées dans des variables du programme.

- Le code de l'application est lui-même écrit dans un langage interprété.

Que l'on m'excuse si j'émets une fois de plus une critique (amicale mais fondée) : cela ne va pas du tout dans le sens de la recherche de performances. Personnellement, je n'aurais jamais fait un choix de ce type dans une application qui a de toute évidence besoin d'éviter toute charge superflue de la CPU. Cela me paraît totalement contre-productif et me laisse vraiment pantois. Je n'avais jamais songé à vérifier ça tant il me paraissait évident que ces infos étaient stockées en binaire dans la BD.

À moins qu'une raison majeure m'échappe. Auquel cas, merci de m'informer.

Mais il y a aussi de bonnes raisons pour stocker les paramètres sous forme de texte. Quand la structure de donnée change, il est beaucoup plus facile de gérer les mises à jours en texte qu'en binaire. De même, avec une structure variable, la gestion est beaucoup plus aisée en texte.

On peut légitimement se poser la question des performances du système, mais si les lectures/écritures dans la BD sont bien gérées, cela ne pose pas de réel problème. LR est un logiciel gourmand, notamment avec ses retouches locales qui doivent être, en temps réel, enregistrées dans la BD. Je ne suis pas certain que si des données binaires étaient stockées plutôt que du texte, le logiciel serait réellement plus rapide. Et surtout, avec le temps et les versions avançant, ces entrées/sorties deviendraient de plus en plus lourdes et complexes. Alors qu'en texte, la complexité ne change pas, et ne changera jamais. Donc, à plus ou moins long terme, le texte est probablement la meilleure des solutions.

[Pat91]

Mais il y a aussi de bonnes raisons pour stocker les paramètres sous forme de texte. Quand la structure de donnée change, il est beaucoup plus facile de gérer les mises à jours en texte qu'en binaire. De même, avec une structure variable, la gestion est beaucoup plus aisée en texte.

D'accord. Mais cela n'arrive qu'une fois au moment du changement de version. Ce n'est pas une charge permanente pour le système.

LR est un logiciel gourmand, notamment avec ses retouches locales qui doivent être, en temps réel, enregistrées dans la BD. Je ne suis pas certain que si des données binaires étaient stockées plutôt que du texte, le logiciel serait réellement plus rapide. Et surtout, avec le temps et les versions avançant, ces entrées/sorties deviendraient de plus en plus lourdes et complexes. Alors qu'en texte, la complexité ne change pas, et ne changera jamais.

On peut appliquer ce même raisonnement au XML (XMP en l'occurrence). Il y a un aspect pratique non négligeable dans l'utilisation du texte comme format de stockage de données, j'en conviens. Mais l'impact sur les performances est mesurable dès que le volume des données et la fréquence d'accès augmentent (j'ai déjà travaillé sur ce point et les chiffres sont éloquents). Je suis persuadé que le stockage des informations sous forme de texte ne prend pas plus de temps que le stockage en binaire. Ce que je remets en question c'est le processus de conversion binaire => texte et texte => binaire qui prend du temps alors qu'il n'existerait pas si on stockait en binaire.

Même en admettant que le choix du texte soit un bon choix (ce que je réfute, donc), je note également une autre incongruité. Pourquoi ne pas stocker ces infos exactement comme dans les XMP : au format XML ? Plutôt que d'avoir 2 convertisseurs et interpréteurs différents (binaire => texte vers la BD et binaire => texte vers XML + processus inverse pour l'interprétation du texte vers le binaire), on peut se demander pourquoi ils n'ont pas utilisé le même parseur XML dans les 2 cas et stocké du XML dans la BD.

Là encore c'est contre-productif : si la sauvegarde automatique des XMP est activée, cela signifie qu'au moment où les infos sont sauvegardées, on procède à 2 conversions des mêmes données : une conversion en XML et une conversion en script. Si on reprend les arguments que tu as développés plus haut, le choix du XML dans les 2 cas était de loin plus cohérent. Non ?

Si on choisit le texte comme support de stockage, autant le faire sous une forme qui permet un accès le plus optimisé possible : avec un parseur XML. Le fait que les infos soient stockées dans un format propriétaire non hiérarchisé les oblige à utiliser un parseur de type linéaire qui fonctionne probablement aussi mal qu'un outil de lecture de fichiers .INI.

Non, décidément, tout ça n'est pas très cohérent.

[kaf]

D'accord. Mais cela n'arrive qu'une fois au moment du changement de version. Ce n'est pas une charge permanente pour le système.

Non, il faut repasser par la logique de conversion (en gros, un switch sur le numéro de version) chaque fois qu'on lit quelque-chose. Parce qu'on n'est jamais sûr de ce qu'on lit, c'est peut-être un ancien catalogue, un vieux sidecar, etc. Donc, la lourdeur reste là à chaque lecture.

On peut appliquer ce même raisonnement au XML (XMP en l'occurrence). Il y a un aspect pratique non négligeable dans l'utilisation du texte comme format de stockage de données, j'en conviens. Mais l'impact sur les performances est mesurable dès que le volume des données et la fréquence d'accès augmentent (j'ai déjà travaillé sur ce point et les chiffres sont éloquents). Je suis persuadé que le stockage des informations sous forme de texte ne prend pas plus de temps que le stockage en binaire. Ce que je remets en question c'est le processus de conversion binaire => texte et texte => binaire qui prend du temps alors qu'il n'existerait pas si on stockait en binaire.

Même en admettant que le choix du texte soit un bon choix (ce que je réfute, donc), je note également une autre incongruité. Pourquoi ne pas stocker ces infos exactement comme dans les XMP : au format XML ? Plutôt que d'avoir 2 convertisseurs et interpréteurs différents (binaire => texte vers la BD et binaire => texte vers XML + processus inverse pour l'interprétation du texte vers le binaire), on peut se demander pourquoi ils n'ont pas utilisé le même parseur XML dans les 2 cas et stocké du XML dans la BD.

Là encore c'est contre-productif : si la sauvegarde automatique des XMP est activée, cela signifie qu'au moment où les infos sont sauvegardées, on procède à 2 conversions des mêmes données : une conversion en XML et une conversion en script. Si on reprend les arguments que tu as développés plus haut, le choix du XML dans les 2 cas était de loin plus cohérent. Non ?

Si on choisit le texte comme support de stockage, autant le faire sous une forme qui permet un accès le plus optimisé possible : avec un parseur XML. Le fait que les infos soient stockées dans un format propriétaire non hiérarchisé les oblige à utiliser un parseur de type linéaire qui fonctionne probablement aussi mal qu'un outil de lecture de fichiers .INI.

Non, décidément, tout ça n'est pas très cohérent.

Je n'ai pas regardé dans la BD, mais je suppose que c'est la même forme que pour les sauvegardes de paramètres (s = {...}). Cette forme est interprétable sans parser en LUA, c'est une simple sérialisation d'objet, comme le JSON du Javascript. Il est donc logique de l'utiliser, pour des raisons de performances. Choisir le XML aurait obligé les développeurs à parser les paramètres tout le temps, ce qui aurait forcément pris du temps.

[Pat91]

Non, il faut repasser par la logique de conversion (en gros, un switch sur le numéro de version) chaque fois qu'on lit quelque-chose. Parce qu'on n'est jamais sûr de ce qu'on lit, c'est peut-être un ancien catalogue, un vieux sidecar, etc. Donc, la lourdeur reste là à chaque lecture.

Je n'ai jamais géré ça comme ça. Les fichiers susceptibles de conversion sont marqués par un tag indiquant le numéro de version. À la première lecture on effectue la conversion dans le nouveau format et c'est terminé. Évidemment, ça n'est possible que si on a pensé dès le départ à marquer les fichiers de données avec un numéro de version. Ce que de trop nombreux développeurs oublient de faire : ils n'y pensent en général qu'au premier changement de version majeur mais là, il est déjà trop tard.

[kaf]

Je n'ai jamais géré ça comme ça. Les fichiers susceptibles de conversion sont marqués par un tag indiquant le numéro de version. À la première lecture on effectue la conversion dans le nouveau format et c'est terminé. Évidemment, ça n'est possible que si on a pensé dès le départ à marquer les fichiers de données avec un numéro de version. Ce que de trop nombreux développeurs oublient de faire : ils n'y pensent en général qu'au premier changement de version majeur mais là, il est déjà trop tard.

Bien sûr il faut convertir, cela simplifie les relectures suivantes. Mais la logique doit rester dans le code ad vitam eternam, parce qu'on est toujours susceptible de devoir relire un vieux truc. Et quand on est à la version 13.2 et qu'on doit relire un truc en version 2.1 ce n'est pas toujours simple C'est beaucoup plus facile en texte

Mais bon, on peut se perdre en conjectures autant que l'on veut, ça ne changera rien au fait que LR stocke en texte. Pourquoi? Parce que c'est ce qu'ils ont décidé de faire

[Pat91]

Je n'ai pas regardé dans la BD, mais je suppose que c'est la même forme que pour les sauvegardes de paramètres (s = {...}). Cette forme est interprétable sans parser en LUA, c'est une simple sérialisation d'objet, comme le JSON du Javascript. Il est donc logique de l'utiliser, pour des raisons de performances.

Oui, il s'agit bien de ce format. Quant aux performances en matière de parseur XML, tout dépend du type de parseur utilisé. Si on utilise un parseur séquentiel (modèle SAX), les performances sont affectées puisque l'on relit tout du début à chaque fois que l'on cherche une info. Ce modèle n'est pas résilient et les infos ne peuvent pas être stockées de manière permanente en mémoire. C'est adapté pour aller chercher une info, une fois.

Si par contre on utilise un parseur basé sur le modèle DOM, cela va plus vite car on ne doit charger l'arborescence qu'une seule fois. L'ensemble des données peut rester et évoluer en mémoire. Ça reste moins rapide que de la BD classique mais c'est mieux que d'aller chercher des lignes de type <nom_valeur> = valeur . Et si on utilise .Net comme environnement de développement, c'est encore mille fois mieux.

Je continue donc de penser que tout cela pourrait (aurait pu) être modernisé afin d'offrir des performances largement améliorées. Mais on tombe là sur le problème des équipes de développement qui repoussent toujours à plus tard le moment du changement d'architecture et d'outils. Et comme plus on attend, plus c'est coûteux et douloureux, on décide en général d'attendre encore plus...  . Air connu.

Bon, tout ça ne fera pas changer d'un iota la stratégie d'Adobe mais il n'y a aucune raison de laisser croire que tout est parfait dans le meilleur des mondes.

[kaf]

Bon, tout ça ne fera pas changer d'un iota la stratégie d'Adobe mais il n'y a aucune raison de laisser croire que tout est parfait dans le meilleur des mondes.

Eh oui, comme on dit chez nous, tout ça ne nous rendra pas le Congo ;-)