Pages: 1 2 [3]  Toutes   Bas de page
  Imprimer  
Auteur Fil de discussion: LightZone n'est plus  (Lu 1882 fois)
kaf
Hyper actif
*
Messages: 1 013



WWW
« Répondre #50 le: Novembre 24, 2011, 11:49:18 »

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.
Signaler au modérateur   Journalisée
Pat91
Hyper actif
*
Messages: 2 006



WWW
« Répondre #51 le: Novembre 24, 2011, 11:50:50 »

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 Sourire ). Je pense représenter un cas de figure assez standard.
Signaler au modérateur   Journalisée

Patrick
Pat91
Hyper actif
*
Messages: 2 006



WWW
« Répondre #52 le: Novembre 24, 2011, 11:53:03 »

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.
Signaler au modérateur   Journalisée

Patrick
kaf
Hyper actif
*
Messages: 1 013



WWW
« Répondre #53 le: Novembre 24, 2011, 12:04:47 »

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.
Signaler au modérateur   Journalisée
Pat91
Hyper actif
*
Messages: 2 006



WWW
« Répondre #54 le: Novembre 24, 2011, 13:39:35 »

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é.
Signaler au modérateur   Journalisée

Patrick
kaf
Hyper actif
*
Messages: 1 013



WWW
« Répondre #55 le: Novembre 24, 2011, 15:38:43 »

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.

Signaler au modérateur   Journalisée
THG
Hyper actif
*
Messages: 6 056



WWW
« Répondre #56 le: Novembre 25, 2011, 17:49:42 »

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

Euh, il ne faut pas faire une généralité du cas d'un Athlon comme le tien qui, à l'évidence, n'est pas à la hauteur de la tâche. Maintenant, j'utilise Lightroom avec une machine d'aujourd'hui, et c'est un autre univers.
Non, Lightroom n'est pas lent per se, mais des processeurs d'il y a deux, trois ans (ou plus) et XP (système 32 bits), sont forcément à la peine.

De plus, l'augmentation permanente de la qualité du traitement des images, telle qu'elle est réclamée par les utilisateurs eux-mêmes, fait que le processus de développement sera de plus en plus lourd et exigeant en puissance.
Signaler au modérateur   Journalisée

Pat91
Hyper actif
*
Messages: 2 006



WWW
« Répondre #57 le: Novembre 25, 2011, 18:20:27 »

Euh, il ne faut pas faire une généralité du cas d'un Athlon comme le tien qui, à l'évidence, n'est pas à la hauteur de la tâche. Maintenant, j'utilise Lightroom avec une machine d'aujourd'hui, et c'est un autre univers.
Non, Lightroom n'est pas lent per se, mais des processeurs d'il y a deux, trois ans (ou plus) et XP (système 32 bits), sont forcément à la peine.

De plus, l'augmentation permanente de la qualité du traitement des images, telle qu'elle est réclamée par les utilisateurs eux-mêmes, fait que le processus de développement sera de plus en plus lourd et exigeant en puissance.

Nous sommes d'accord. Je n'ai pas dit que LR est lent en soi. Je dis qu'il est nécessairement plus lent que PS à machine égale. Forcément, ça se voit plus sur des machines qui, comme la mienne et comme celle de beaucoup d'autres, sont en retard d'une génération au niveau processeur. Mais plus la machine est puissante, moins ça se voit. Je sais que je dois changer d'UC mais j'ai un X100 à commander d'abord.
Signaler au modérateur   Journalisée

Patrick
THG
Hyper actif
*
Messages: 6 056



WWW
« Répondre #58 le: Novembre 26, 2011, 20:30:51 »

Nous sommes d'accord. Je n'ai pas dit que LR est lent en soi. Je dis qu'il est nécessairement plus lent que PS à machine égale. Forcément, ça se voit plus sur des machines qui, comme la mienne et comme celle de beaucoup d'autres, sont en retard d'une génération au niveau processeur. Mais plus la machine est puissante, moins ça se voit. Je sais que je dois changer d'UC mais j'ai un X100 à commander d'abord.

Je comprends pour le X100 ;-)
Signaler au modérateur   Journalisée

Romu
Actif
*
Messages: 134



WWW
« Répondre #59 le: Novembre 30, 2011, 18:00:36 »

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.

Je me cite et m'en félicite  Grimaçant
Signaler au modérateur   Journalisée
Pages: 1 2 [3]  Toutes   Haut de page
  Imprimer  
 
Aller à: