LR4 - inversion de "masque" ?

[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 ;-)