LightZone n'est plus

[Romu]

Quand je lis que Lightroom 2 a copié la retouche locale de LZ, et ayant eu la chance d'assister à la naissance de ces outils dans l'application d'Adobe, ça me fait bien rigoler, d'autant que le concept et les maths qui sont derrières n'ont strictement rien à voir.

Gilles, les maths derrière, tu peux me dire à quoi ça sert du strict point de vue le l'utilisateur ?...à rien il me semble. Que LR soit le meilleur, soit, que la puissance de feu de Adobe soit phénoménale, amen.

Maintenant que tu le veuilles ou non, la retouche locale, c'est pas LR qui l'a inventée, c'est LZ. Et à l'usage, je trouve bien plus pratique, encore aujourd'hui, la fonctionnalité dans feu LZ que dans LR. Dans LR c'est facile si t'as une tablette tactile, à la souris, ça l'est un peu moins.

Et l'inverse est aussi vrai, si tu bosses à la tablette tactile, les zones de LZ sont certainement plus difficiles à manier que le pinceau de LR.

Et si je t'ai fait rire, très bien, bois un coup à ma santé.

J'en profite pour donner le lien vers le site qui reprend LZ : http://lightzombie.org/

[THG]

Gilles, les maths derrière, tu peux me dire à quoi ça sert du strict point de vue le l'utilisateur ?...à rien il me semble. Que LR soit le meilleur, soit, que la puissance de feu de Adobe soit phénoménale, amen.

Maintenant que tu le veuilles ou non, la retouche locale, c'est pas LR qui l'a inventée, c'est LZ. Et à l'usage, je trouve bien plus pratique, encore aujourd'hui, la fonctionnalité dans feu LZ que dans LR. Dans LR c'est facile si t'as une tablette tactile, à la souris, ça l'est un peu moins.

Et l'inverse est aussi vrai, si tu bosses à la tablette tactile, les zones de LZ sont certainement plus difficiles à manier que le pinceau de LR.

Et si je t'ai fait rire, très bien, bois un coup à ma santé.

J'en profite pour donner le lien vers le site qui reprend LZ : http://lightzombie.org/

Fait rire non, sourire, oui.

Sache pour ta gouverne que la retouche locale de type paramétrique, telle qu'elle est dans Lightroom, n'a rien à voir avec la sélection vectorielle de Lightzone (qui d'ailleurs, n'était pas persistante). Ces deux approches et technologies sont totalement différentes... donc, ce qu'il y a dans Lightroom est bien une première et a bien été inventé par Adobe (très exactement par Mark Hamburg et le team Camera Raw...).

Amen.

PS : j'ai utilisé Lightzone dès la première heure, alors que le soft n'était pas encore connu en France. Et j'en avais parlé car il était le premier à tenter d'intégrer un workflow en tant qu'éditeur externe de Lightroom 1...
Donc faudrait arrêter de croire, toi et d'autres, que je ne connais que Lightroom...

[Zaphod]

Là où Romu a raison, c'est que la technique derrière, l'utilisateur s'en fout.
Qu'il y ait de la techno spécifique à Adobe dans la retouche locale de Lightroom, c'est certain.

Mais ce qui compte pour l'utilisateur, ce sont les fonction dispo, et ce qu'il peut faire avec.

Pour moi, clairement le premier soft avec de la retouche locale en RAW que j'ai utilisé, c'est Lightzone.
Lightroom est venu après... de manière différente certes (supérieur sur certains points, inférieur sur d'autres, comme la sélection des zones)

[Pat91]

Là où Romu a raison, c'est que la technique derrière, l'utilisateur s'en fout.

Je ne suis pas d'accord à 100% avec ça. Il est bien évident qu'à la base, le problème principal de l'utilisateur c'est de se servir du produit et que ça marche comme prévu. Cependant, il s'agit en l'occurence, qu'on le veuille ou non, de logiciels techniques et il faut parfois faire des choix de paramètres qui présupposent une certaine connaissance technique.

Quand j'utilise un logiciel de comptabilité, aussi simple soit-il, viendra inéluctablement le moment où une compétence minimale en compta sera nécessaire.

Dans mon club, nous traitons le problème de la manière suivante. Chaque mois, l'adhérent trouve dans le bulletin un article technique synthétique de 3 pages maximum exposant les connaissances nécessaires à la prise de certaines décisions pendant l'utilisation du logiciel. Cela lui permet de comprendre à la fois ce qui se passe et ce qu'il fait sans avoir à retourner à ses bouqins de maths ou d'informatique. Quelques exemples:

- Bits-et-octets.pdf (Quelques considérations sur le calcul numérique utiles au photographe numérique)
- La température de couleur.pdf (Introduction à la notion de température de couleur)
- Résolution_image.pdf (Pour tout savoir sur la résolution, la taille d'image, les dpi, les dpp,...)
- ...

On l'aura compris, je suis l'anti-Kelby. J'ai toujours pensé que tout le monde peut comprendre un processus technique quand c'est expliqué simplement et correctement. Même sans avoir fait bac+n. Quand on a compris l'essentiel de ce qui se passe sous le capot, on est un meilleur utilisateur. Du temps où je m'occupais d'une ligne de fabrication en usine, je me souviens avoir expliqué à des opérateurs ayant à peine un CAP comment fonctionnait un spectrophotomètre infra-rouge (les mesures effectuées n'étaient pas fiables). Ils ont préféré ça à entendre toute la journée la maîtrise leur hurler dessus. Et je n'ai plus jamais été embêté par des mesures erronnées.

[THG]

Dans mon club, nous traitons le problème de la manière suivante. Chaque mois, l'adhérent trouve dans le bulletin un article technique synthétique de 3 pages maximum exposant les connaissances nécessaires à la prise de certaines décisions pendant l'utilisation du logiciel. Cela lui permet de comprendre à la fois ce qui se passe et ce qu'il fait sans avoir à retourner à ses bouqins de maths ou d'informatique. Quelques exemples:

- Bits-et-octets.pdf (Quelques considérations sur le calcul numérique utiles au photographe numérique)
- La température de couleur.pdf (Introduction à la notion de température de couleur)
- Résolution_image.pdf (Pour tout savoir sur la résolution, la taille d'image, les dpi, les dpp,...)
- ...

Oui, ça c'est une excellente idée dont beaucoup de clubs feraient bien de s'inspirer. Lorsque je faisais des formations Lightroom, notamment au salon de Riedisheim, j'étais parfois effaré de voir des stagiaires inscrits à mon cours de niveau avancé être totalement dépourvus de la moindre notion de base.
Je crois qu'il est bon, pour tout le monde, y compris les "experts", de revoir les bases, et d'expliquer, sans entrer dans les détails, la manière dont certains outils fonctionnent.
Dans ma dernière intervention, il est important de comprendre qu'il y a une différence entre les masques vectoriels et bitmap à la Lightzone, et la retouche dite "paramétrique" du pinceau de Lightroom. On a affaire à deux technologies différentes, il est donc inutile d'argumenter pour savoir qui a été le premier.

Je suis toujours amusé de voir le nombre d'intervenants réclamant les U-points ou des outils de sélection de zones dans Lr. Il est bien évident qu'Adobe a sa propre idée sur la question et qu'elle ne se satisfera pas de repomper les idées ou la technologie des autres. Après, tout est question de priorités et de ressources disponibles...

[Romu]

Gilles, veux tu m'autoriser à me coucher moins ignare ce soir ? Par exemple en expliquant précisément, en quoi les 2 approches LZ/LR diffèrent, avantage et inconvénients des 2 solutions. Essaie de rester succinct autant que possible, n'y passe pas des heures. Mais c'est juste pour ma culture perso, sans aucun esprit polémique.

Merci à toi.

[Zaphod]

Dans mon club, nous traitons le problème de la manière suivante. Chaque mois, l'adhérent trouve dans le bulletin un article technique synthétique de 3 pages maximum exposant les connaissances nécessaires à la prise de certaines décisions pendant l'utilisation du logiciel. Cela lui permet de comprendre à la fois ce qui se passe et ce qu'il fait sans avoir à retourner à ses bouqins de maths ou d'informatique. Quelques exemples:

- Bits-et-octets.pdf (Quelques considérations sur le calcul numérique utiles au photographe numérique)
- La température de couleur.pdf (Introduction à la notion de température de couleur)
- Résolution_image.pdf (Pour tout savoir sur la résolution, la taille d'image, les dpi, les dpp,...)
- ...

On l'aura compris, je suis l'anti-Kelby. J'ai toujours pensé que tout le monde peut comprendre un processus technique quand c'est expliqué simplement et correctement. Même sans avoir fait bac+n. Quand on a compris l'essentiel de ce qui se passe sous le capot, on est un meilleur utilisateur.

Je trouve que c'est quand même légèrement différent.

Par exemple, je trouve ça important de comprendre est fait conçu un capteur, comment est codé un RAW etc...

En revanche, savoir en quoi les algorithmes d'Adobe de retouche locale sont différents de ceux de Lightzone... ça...

C'est différent par exemple, si le concept est différent.
Là, dans ce cas, ça m'intéresse, par ce que ça peut aider à l'utiliser comme il faut.

Mais je n'ai jamais vu d'explication sur ce point. Si ça existe, je suis preneur.
En tant qu'utilisateur, je trouve que le concept est très proche, même si les outils sont différent.

[Pat91]

Je trouve que c'est quand même légèrement différent.

Oui, c'est pour cela que j'ai répondu  "je ne suis pas à 100% d'accord" à la phrase "la technique derrière, l'utilisateur s'en fout.". On ne demande bien sûr pas à l'utilisateur de savoir comment on code des calques et des masques. Par contre, un minimum de technique peut aider à faire des choix.

Un développeur expérimenté comprendra vite pourquoi la technique des calques utilisée par PS est plus rapide, par nature, que la technique de retouche locale de LR ou de LightZone. On ne demande pas à un utilisateur non informaticien de comprendre ça. Par contre, je peux assez simplement expliquer à un non technicien pourquoi il faut décocher l'option de mise à jour automatique des XMP dans LR (surtout si le processeur est un peu mou des genoux). C'est ce que je fais dans mes cours Lightroom. Ça prend 3 minutes et l'utilisateur sait pourquoi il faut décocher et il n'oubliera pas de le faire.

[coval95]

Allez, clic

Si je le fais courte : ils ont exploité l'idée de postscript, rendu rentable grâce à une startup (Apple) puis pour tout le reste, ils ont commencé par racheter des "petites boites novatrices" pour constituer leur situation actuelle à grands coups de développements croisés et packaging marketing (extrèmement bien faits)...

Acrobat, par exemple, fuit d'un rachat aussi, l'idée géniale a été de donner la visionneuse tout en vendant le driver. Ils ont bouffé ce marché grâce à cette idée géniale. Et je dis çà d'autant à l'aise qu'à l'époque, je vendais (enfin j'essayais...) une techno bien meilleure (meilleur taux de compression, plus de perfs, meilleur rendu graphique), mais on a été laminé par le marketing génial d'Adobe

Et je dis çà sans absolument pas l'ombre d'une critique, ce modèle de développement a prouvé son efficacité. C'est juste que "fleur bleue" c'est légèrement condescendant et parfaitement faux (en l'espèce)

Bonjour
Je découvre ce fil et je voudrais y ajouter ma contribution (mon grain de sel si vous préférez...  ).
Je ne suis pas toujours d'accord avec Lesfilmu (c'est le moins qu'on puisse dire  ) mais dans ce cas je vais abonder dans son sens.

En effet, jusqu'en 2006 j'utilisais un dématriceur qui s'appelait RawShooter fait par une petite boîte danoise, Pixmantec.
Il y avait une version gratuite (Essentials) et une version payante (Premium) de RawShooter. La gratuite était déjà relativement évoluée, en tout cas pour des besoins d'amateur. Elle était très ergonomique et réactive. L'application qui lui ressemble le plus de nos jours par son ergonomie, c'est Capture One à ce qu'il me semble. Mais point de version gratuite. 

En 2006, cette boîte a été rachetée par Adobe qui voulait reprendre son savoir-faire pour l'injecter dans LightRoom. A l'époque j'ai lu qu'Adobe reprenait des développeurs de Pixmantec. Et bien sûr Adobe n'a pas jugé utile de laisser une version gratuite (de LightRoom). 

On voit dans l'article mis en lien par Lesfilmu ce rachat de Pixmantec par Adobe mais il n'est pas précisé à quel produit ça correspond.
Pour en savoir plus, vous pouvez lire l'article publié le 26/6/2006 par dpreview à ce sujet :
http://www.dpreview.com/news/2006/6/26/adobebuypixmantec

En particulier, je cite cet extrait de dpreview :
"Pixmantec is a privately held company headquartered in Copenhagen, Denmark and currently ships the RawShooter® line of digital photography software products.  Adobe plans to integrate Pixmantec raw processing technologies into Lightroom™ and wherever customers will be working with raw files.

In preparation for this integration, the Pixmantec RawShooter Premium product is being discontinued, though the free RawShooter Essentials product will continue to be available until the Lightroom public beta program is completed. Existing Pixmantec customers will continue to be supported by Adobe and will be provided with an upgrade path to the Adobe digital imaging product family."

Je crois que LightRoom existait déjà avant cette acquisition mais qu'il a subi une refonte complète après le rachat de Pixmantex par Adobe.

[Powershot]

... et bien sûr Adobe n'a pas jugé utile de laisser une version gratuite ...

Question aux forts en droit commercial :
- dans quelle mesure une ancienne version gratuite est-elle partageable ?
Bonnes photos à tous !

[Zaphod]

Par contre, je peux assez simplement expliquer à un non technicien pourquoi il faut décocher l'option de mise à jour automatique des XMP dans LR (surtout si le processeur est un peu mou des genoux). C'est ce que je fais dans mes cours Lightroom. Ça prend 3 minutes et l'utilisateur sait pourquoi il faut décocher et il n'oubliera pas de le faire.

Ah moi justement cette option je la laisse cocher en connaissance de cause
Ca m'intéresse d'avoir les XMP régulièrement mis à jour, même si quand je veux être sur d'avoir des XMP à jour, je fais un petit Ctrl+S.
(accessoirement je n'ai vu aucune différence de perfo avec ou sans - ça ne veut pas dire qu'il n'y en a pas, mais c'est imperceptible)

En revanche j'aimerais bien connaitre la technique derrière la gestion du cache... car je n'arrive pas à le faire fonctionner correctement, et je ne sais pas à quoi c'est du.
(mais je ferai un message dédié dans la section adéquate... car ça devient totalement HS).

[THG]

Ah moi justement cette option je la laisse cocher en connaissance de cause
Ca m'intéresse d'avoir les XMP régulièrement mis à jour, même si quand je veux être sur d'avoir des XMP à jour, je fais un petit Ctrl+S.
(accessoirement je n'ai vu aucune différence de perfo avec ou sans - ça ne veut pas dire qu'il n'y en a pas, mais c'est imperceptible)

En revanche j'aimerais bien connaitre la technique derrière la gestion du cache... car je n'arrive pas à le faire fonctionner correctement, et je ne sais pas à quoi c'est du.
(mais je ferai un message dédié dans la section adéquate... car ça devient totalement HS).

+1

En plus, cette option apporte, à peu de frais, un deuxième niveau de sauvegarde du travail exécuté dans Lightroom, et facilite le partage avec d'autres utilisateurs de Lightroom et Camera Raw.
Dès lors qu'on a laissé le catalogue mouliner et digérer le temps qu'il faut, l'impact sur les performances est négligeable.

[Nikojorj]

On l'aura compris, je suis l'anti-Kelby.

Oh my God, they killed Kelby!
J'abonde abondamment au principe d'essayer de ne pas prendre ses interlocuteurs pour des téléspectateurs devant TF1...

Même si pour les XMP, je préfère aussi les sauver (question de sauvegarde).

[Pat91]

Même si pour les XMP, je préfère aussi les sauver (question de sauvegarde).

Je les sauvegarde aussi mais manuellement (Ctrl-S après sélection ou clic sur l'icône qui signale la désynchronisation entre les XMP et le catalogue). Et je regrette une fois de plus qu'il soit toujours impossible de filtrer sur ce critère. Cela permettrait de sélectionner en une fois toutes les photos du catalogue qui n'ont pas leur XMP à jour et de procéder à la sauvegarde. Actuellement, il faut procéder dossier par dossier.

J'en ai parlé à Dan Tull il y a déjà longtemps et il a reconnu que ça serait très utile. Mais je ne vois rien venir (version 3.6 peut-être?).

[THG]

Je les sauvegarde aussi mais manuellement (Ctrl-S après sélection ou clic sur l'icône qui signale la désynchronisation entre les XMP et le catalogue). Et je regrette une fois de plus qu'il soit toujours impossible de filtrer sur ce critère. Cela permettrait de sélectionner en une fois toutes les photos du catalogue qui n'ont pas leur XMP à jour et de procéder à la sauvegarde. Actuellement, il faut procéder dossier par dossier.

J'en ai parlé à Dan Tull il y a déjà longtemps et il a reconnu que ça serait très utile. Mais je ne vois rien venir (version 3.6 peut-être?).

Procéder dossier par dossier ? Un filtre ? Je n'en vois pas l'utilité : il suffit de sélectionner tout le catalogue et faire Ctrl+S, et ce qui est déjà à jour restera en l'état.
Il est inutile de compliquer l'interface ou de rajouter encore un filtre ou menu supplémentaire.

[Pat91]

Il suffit de sélectionner tout le catalogue et faire Ctrl+S, et ce qui est déjà à jour restera en l'état.

Pas si simple. Cela suppose que l'on remonte d'abord à la racine du dossier et que l'on active la visualisation des sous-dossiers (chez moi comme chez beaucoup d'utilisateurs, elle est désactivée pour éviter l'encombrement). Ensuite, Ctrl-S n'aura aucun effet sur les images incluses dans des piles si les piles ne sont pas dépliées. Il faut donc penser à déplier l'ensemble des piles avant de faire Ctrl-S et à les replier ensuite. Puis désactiver à nouveau la visualisation des sous-dossiers.

J'ajouterai à ça qu'il y a un bug lié à l'icône de signalement de non synchronisation des XMP. Supposons que dans un dossier, je modifie une image. Si la sauvegarde automatique des XMP est désactivée, la flèche en bas apparaît dans dans le coin haut droit de la vignette. Si je clique dessus, on me propose la sauvegarde du XMP. Si par inadvertance, j'accepte la sauvegarde alors que l'ensemble (ou une partie) des photos du dossier est sélectionné, les XMP seront créés systématiquement pour toutes les images sélectionnées même si cela ne sert à rien.

Je continue donc de penser qu'un outil de filtrage sur ce flag est utile et qu'il devrait prendre en compte (comme les autres outils de filtrage) les images qui sont masquées pour cause de pile repliée (cela devrait en fait être une option).

Il suffit de consulter le forum LR pour constater que je ne suis pas le seul à avoir formulé cette requête. Réponse de Dan Tull sur ce point (je sais, ce n'est pas lui qui décide mais bon, son avis est a priori important):

"Yeah, I can definitely see where that would be useful. I think there's an existing feature request for something of that sort (including highlighting in the folder panel which folders contain files or other folders containing files which may need XMP to be saved). "

[THG]

Pas si simple. Cela suppose que l'on remonte d'abord à la racine du dossier et que l'on active la visualisation des sous-dossiers (chez moi comme chez beaucoup d'utilisateurs, elle est désactivée pour éviter l'encombrement). Ensuite, Ctrl-S n'aura aucun effet sur les images incluses dans des piles si les piles ne sont pas dépliées. Il faut donc penser à déplier l'ensemble des piles avant de faire Ctrl-S et à les replier ensuite. Puis désactiver à nouveau la visualisation des sous-dossiers.

J'ajouterai à ça qu'il y a un bug lié à l'icône de signalement de non synchronisation des XMP. Supposons que dans un dossier, je modifie une image. Si la sauvegarde automatique des XMP est désactivée, la flèche en bas apparaît dans dans le coin haut droit de la vignette. Si je clique dessus, on me propose la sauvegarde du XMP. Si par inadvertance, j'accepte la sauvegarde alors que l'ensemble (ou une partie) des photos du dossier est sélectionné, les XMP seront créés systématiquement pour toutes les images sélectionnées même si cela ne sert à rien.

Je continue donc de penser qu'un outil de filtrage sur ce flag est utile et qu'il devrait prendre en compte (comme les autres outils de filtrage) les images qui sont masquées pour cause de pile repliée (cela devrait en fait être une option).

Il suffit de consulter le forum LR pour constater que je ne suis pas le seul à avoir formulé cette requête. Réponse de Dan Tull sur ce point (je sais, ce n'est pas lui qui décide mais bon, son avis est a priori important):

"Yeah, I can definitely see where that would be useful. I think there's an existing feature request for something of that sort (including highlighting in the folder panel which folders contain files or other folders containing files which may need XMP to be saved). "

Ok, je comprends, je vois un peu mieux ce que tu veux dire.

Néanmoins, je reste quand même avocat de l'activation permanente de l'écriture XMP. En attendant qu'Adobe aille un peu plus loin dans la gestion de ces fichiers annexes, ce qui, manifestement, ne figure pas en tête des priorités.

[Nikojorj]

Cela suppose que l'on remonte d'abord à la racine du dossier et que l'on active la visualisation des sous-dossiers (chez moi comme chez beaucoup d'utilisateurs, elle est désactivée pour éviter l'encombrement).

Ben pour ça y'a "all photographs" tout en haut?
Mais ça ne désempile pas les piles par contre, oui.

PS tu as pu quantifier la perte de performances liées à l'écriture auto, au fait?

[Pat91]

Néanmoins, je reste quand même avocat de l'activation permanente de l'écriture XMP.

Ça cessera d'être un problème quand nous aurons tous des machines très puissantes. Ce qui n'est pas le cas actuellement et de loin. Et par les temps qui courent, les budgets ne vont pas être revus à la hausse.

Le souci est qu'il y a des ordres de grandeur de différence entre le temps mis à sauvegarder une info de correction dans le catalogue et le temps mis à sauvegarder la même info dans le XMP. Un fichier XMP est un fichier XML. C'est-à-dire, pour faire simple, un fichier texte contenant des données organisées de manière hiérarchisée à l'intérieur de balises (<la_balise>). À chaque fois que l'on lit ou écrit dans ces fichiers, il faut réaliser les opérations suivantes:

- Lire le texte en question
- Répérer les balises
- Vérifier la validité de leur organisation (une balise ouverte doit toujours être fermée, une balise doit toujours se trouver à l'intérieur d'une autre balise, vérifier le type du contenu des balises,...). On appelle ça la validation.
- Reconstituer en mémoire la structure hiérarchique qui en découle.
- Écrire ou lire les données depuis cette structure en vérifiant la validité de l'opération.
- Refermer le fichier.

L'ensemble de ces opérations s'appelle le parsing du fichier XML. Elles sont réalisées par ce que l'on appelle un parseur qu'il faut bien sûr charger en mémoire avant de commencer. Par nature et en comparaison de l'écriture dans une base de données, ces opérations sont extrêmement lentes (informatiquement parlant).

Si on considère par exemple que lors de l'utilisation du pinceau, LR met à jour en permanence l'ensemble des coordonnées des zones peintes (il suffit d'ouvrir un XMP dans le bloc-notes pour voir la tête du texte généré par cette seule opération), il n'est pas étonnant que les machines qui ne sont pas équipées d'un processeur puissant et de mémoire en quantité voient leurs performances affectées lors de telles opérations.

[kaf]

Si on considère par exemple que lors de l'utilisation du pinceau, LR met à jour en permanence l'ensemble des coordonnées des zones peintes (il suffit d'ouvrir un XMP dans le bloc-notes pour voir la tête du texte généré par cette seule opération), il n'est pas étonnant que les machines qui ne sont pas équipées d'un processeur puissant et de mémoire en quantité voient leurs performances affectées lors de telles opérations.

D'ailleurs, même les machines puissantes souffrent quand on abuse des retouches locales. C'est le principal désavantage de la "retouche paramétrique" telle que proposée par LR.

[Pat91]

PS tu as pu quantifier la perte de performances liées à l'écriture auto, au fait?

Comme dans l'exemple cité dans mon message précédent, sur ma machine, si j'active la sauvegarde automatique des XMP et que je commence à utiliser le pinceau, ma tension monte. J'ai un AMD 64 Athlon X2 Dual Core 4400 qui n'est pas de première fraîcheur mais ça correspond à une machine disons "moyenne". Je vais changer d'UC un de ces jours mais il y a d'autres priorités (peut-être un X100 par exemple ). Je pense représenter un cas de figure assez standard.

[Pat91]

D'ailleurs, même les machines puissantes souffrent quand on abuse des retouches locales. C'est le principal désavantage de la "retouche paramétrique" telle que proposée par LR.

Oui. C'est bien pour ça que la méthode PS via des calques et des masques est nécessairement plus rapide. mais c'est plus lourd à gérer par l'utilisateur.

[kaf]

Oui. C'est bien pour ça que la méthode PS via des calques et des masques est nécessairement plus rapide. mais c'est plus lourd à gérer par l'utilisateur.

Bah, oui et non, ça dépend de ce qu'on fait. Quand on abuse des objets dynamiques et des filtres dynamiques par exemple, on se retrouve parfois avec des fichiers énormes qui prennent un temps fou à charger ou sauver. Les deux techniques ont leurs avantages et leur inconvénients.

[Pat91]

Quand on abuse des objets dynamiques et des filtres dynamiques par exemple, on se retrouve parfois avec des fichiers énormes qui prennent un temps fou à charger ou sauver.

C'est parfaitment exact mais ça n'affecte pas massivement la vitesse de traitement en cours d'édition parce que PS ne travaille que sur les "parties actives" de l'image. D'un point de vue programmation, chaque calque doit être représenté par une bitmap en mémoire. La fusion des différents "étages" pour la visu est facile et rapide et le travail sur les bitmaps aussi. De plus, PS sait découper une image en zones de travail et il n'effectue les calculs que sur les zones affectées par l'action en cours à l'instant T (voir les réglages "mosaïque" correspondants dans les Préférences).

A contrario, LR, de par sa nature paramétrique, est obligé d'agir en permanence sur la globalité de l'image. Il y a même quelques fautes d'optimisation assez flagrantes que l'on peut mettre facilement en évidence. Si vous travaillez en mode double écran avec LR, si vous vous trouvez par exemple en mode Développement avec l'image sur l'écran principal et si vous avez laissé le second écran en mode loupe au lieu de passer en mode grille, vous comprendrez rapidement ce que mise à jour permanente veut dire : 2 rafraîchissements complets au lieu d'un à chaque correction, on perçoit tout de suite la différence. En tous cas sur ma machine (si j'oublie de faire la manip, je suis rappelé à l'ordre immédiatement).

Avec le temps, j'ai appris ce qu'il ne fallait pas faire avec LR si on veut éviter des baisses de performances spectaculaires. Mais fondamentalement, c'est un logiciel plus lent que PS par sa nature même. On n'en parlera plus dans quelques années quand les processeurs auront encore progressé.

[kaf]

Mais fondamentalement, c'est un logiciel plus lent que PS par sa nature même.

Tout dépend si l'on compte le temps passé globalement sur l'image, ou juste le temps de traitement effectif. Mais de toute façon, les deux approches ont leurs points forts et leurs points faibles, et servent donc à des choses différentes. En général, les problèmes se posent quand on essaye de faire avec LR ce qu'on devrait réaliser avec PS, ou au contraire quand on veut faire du 100% réversible dans PS.

On n'en parlera plus dans quelques années quand les processeurs auront encore progressé.

Pas sûr, parce que la demande en ressources va aussi augmenter, pour les deux logiciels.