Vélocité de Photoshop

[frmfrm]

Si la suite des opérations s'effectuait sur une "bitmap" résultant d'un dématriçage unique sur lequel on ne reviendrait pas (ou rarement), quel avantage y aurait-il à photographier en RAW plutôt qu'en JPEG?  Pourquoi aurait-on des outils paramétriques comme LR et Camera RAW s'il s'agissait uniquement de dématricer une fois et d'éditer ensuite en mode "bitmap"? Autant laisser le boîtier dématricer une fois pour toutes et envoyer le fichier directement dans Photoshop, non?

C'est bien la possibilité de repartir des données de base qui rend le dématriçage aussi intéressant. Tous les réglages agissent les uns sur les autres. Si je ne repars pas des données d'origine, je perds toute la souplesse et toute la puissance du développement paramétrique.

Quel rapport. La question n'est pas de savoir si le raw et plus intéressant que le jpg, mais de savoir par quelle étape passe lightroom ou photoshop.

Et à mon avis, ca peut être utile pour comprendre pourquoi à un instant donné un raw peut être considéré comme équivalent à un tif produit dans la méthode suivante :

http://www.color.org/scene-referred.xalter

[Samoreen]

Quel rapport. La question n'est pas de savoir si le raw et plus intéressant que le jpg, mais de savoir par quelle étape passe lightroom ou photoshop.

Ce n'est pas de ça que je parle. J'explique pourquoi à mon sens, le dématriçage est refait à chaque modification des réglages. Processus que vous semblez mettre en doute en expliquant que selon la documentation du DNG SDK, il y aurait un dématriçage préliminaire sur lequel il ne serait pas nécessaire de revenir. Vous étendez ce que fait le DNG SDK - qui a mon humble avis n'a rien à voir dans la discussion - à ce qui se passe dans LR et Camera RAW, ce que je conteste. Et j'explique pourquoi.

[Samoreen]

Vous étendez ce que fait le DNG SDK - qui a mon humble avis n'a rien à voir dans la discussion - à ce qui se passe dans LR et Camera RAW, ce que je conteste. Et j'explique pourquoi.

Pour être plus précis: je ne vois pas ce que vient faire un SDK fournissant des fonctions de manipulation de fichiers DNG dans une discussion sur la rapidité relative des traitements dans PS et LR et sur ce qui se passe quand on charge un RAW sortant d'un APN dans Lightroom ou dans Camera RAW.

Si vous arrivez à faire la connexion, expliquez-nous mais je n'arrive pas à voir la relation.

[frmfrm]

je ne vois pas ce que vient faire un SDK fournissant des fonctions de manipulation de fichiers DNG dans une discussion sur la rapidité relative des traitements dans PS et LR et sur ce qui se passe quand on charge un RAW sortant d'un APN dans Lightroom ou dans Camera RAW.

Tu l'as téléchargé ou pas ? Parce que si tu ne l'as pas téléchargé à moins d'avoir un don particulier je ne pense pas que tu puisses voir grand chose.

Ceci dit, personnellement,  je ne vois pas l'intérêt de poursuivre donc  A+

[Christophe Mely]

Tu l'as téléchargé ou pas ? Parce que si tu ne l'as pas téléchargé à moins d'avoir un don particulier je ne pense pas que tu puisses voir grand chose.

Ceci dit, personnellement,  je ne vois pas l'intérêt de poursuivre donc  A+

...déplorable...c'était bien la peine d'intervenir...

[Samoreen]

Tu l'as téléchargé ou pas ? Parce que si tu ne l'as pas téléchargé à moins d'avoir un don particulier je ne pense pas que tu puisses voir grand chose.

Je l'ai téléchargé et j'ai regardé la doc, bien sûr. Sinon, je n'aurais pas pu faire les commentaires ci-dessus.

[frmfrm]

Si vous arrivez à faire la connexion, expliquez-nous mais je n'arrive pas à voir la relation.

Je ne pense pas qu' il y ait des différences de traitement (par lightroom) entre un raw de canon et un dng généré par lightroom à partir d'un raw de canon.

Pour développer un raw, lightroom  s'appuie sur les profils des appareils qu'il connait.

Si tu exportes un raw de canon en dng et que tu ouvres le dng, je pense que tu retrouveras les mêmes profils que ceux proposés pour le développement du raw canon.

Maintenant, dans le fichier dng_spec_xxxx.dpf du sdk, on trouve comment et suivant quelle séquence les dng sont développés à partir des infos stockées dans les profils de caméra.

A mon avis encore, il n'y a pas de raison pour que lightroom procède différemment pour les raws de canon.

Et se débarrasser le plus vite possible de ce qui différencie les appareils avant de faire le traitement d'image à proprement parlé ne me semble pas incongru.

[tenmangu81]

Je ne suis pas sûr qu'il s'agisse de la même chose. D'ailleurs Patrick l'avait bien expliqué dans son message:

Je ne vois pas très bien la connexion. Le DNG SDK est une description du format DNG et une bibliothèque d'outils permettant de lire ce format dans une application tierce qui ne sera d'ailleurs probablement pas un dématriceur. À mon humble avis c'est destiné à des gens qui voudraient visualiser un DNG dans leurs applications. Les espaces couleur cités ne correspondent d'ailleurs pas à l'espace couleur utilisé dans LR et Camera RAW : Melissa RGB.

Cette bibliothèque me semble donc destinée à fournir le code nécessaire à un dématriçage unique et à une traduction dans un espace couleur standard et un format qui pourront être exploités par l'application tierce pour visualiser l'image. Je ne pense pas que l'on puisse créer un éditeur paramétrique avec ça sans y rajouter beaucoup de code. Sinon, cela voudrait dire qu'Adobe met à disposition le code de son moteur de dématriçage.

Lorsqu'on travaille dans un dématriceur, l'image est recalculée à chaque modification d'un paramètre. Ici (j'ai aussi lu la doc), l'image est dématricée une fois en vue de sa transformation en dng pour une utilisation ultérieure dans un logiciel tiers.

[Samoreen]

Maintenant, dans le fichier dng_spec_xxxx.dpf du sdk, on trouve comment et suivant quelle séquence les dng sont développés à partir des infos stockées dans les profils de caméra.

A mon avis encore, il n'y a pas de raison pour que Lightroom procède différemment pour les raws de canon.

Encore une fois, la question n'est pas là. On ne discute pas de la manière dont on fait le dématriçage une fois. On discute de ce qui se passe quand dans Lightroom ou Camera RAW, l'utilisateur change un des paramètres de développement (dans le but de comprendre les différences de performances pendant le traitement d'une image TIFF ou JPEG traitée dans PS et un RAW traité dans LR ou ACR - ce qui est, je le rappelle, la question initiale).

L'idée que je défends (dont je ne revendique pas la paternité et qui semble acceptée par beaucoup comme une évidence), c'est qu'à chaque modification d'un paramètre on repasse par un dématriçage des données de base et que c'est cela qui explique la lenteur relative et les limites "éditoriales" des dématriceurs par rapport à un logiciel qui édite des "bitmaps". Peu importe la manière dont le dématriçage est calculé - chaque logiciel le fait de manière différente -, c'est le fait qu'il soit continuellement répété qui impacte les performances.

Je suis tout à fait prêt à accepter une autre explication si quelqu'un me montre comment un éditeur paramétrique peut éviter de boucler en permanence sur le dématriçage des données originales à chaque modification d'un des paramètres. J'ai beau activer mes "petites cellules grises", je ne vois pas comment on peut éviter ça.

[Samoreen]

Lorsqu'on travaille dans un dématriceur, l'image est recalculée à chaque modification d'un paramètre. Ici (j'ai aussi lu la doc), l'image est dématricée une fois en vue de sa transformation en dng pour une utilisation ultérieure dans un logiciel tiers.

Merci Robert, je vois que l'on a convergé en même temps  .

[frmfrm]

On discute de ce qui se passe quand dans Lightroom ou Camera RAW, l'utilisateur change un des paramètres de développement[/b] (dans le but de comprendre les différences de performances pendant le traitement d'une image TIFF ou JPEG traitée dans PS et un RAW traité dans LR ou ACR - ce qui est, je le rappelle, la question initiale).

Mais moi aussi, et il semble que d'après ce que j'ai lu, les corrections d'expos, de contraste etc.. se font après l'application de la table HueSatMap.

[Samoreen]

Mais moi aussi, et il semble que d'après ce que j'ai lu, les corrections d'expos, de contraste etc.. se font après l'application de la table HueSatMap.

Encore une fois, dans le cadre d'un dématriçage unique. Et ce n'est pas de ça dont on discute ici. Maintenant, je ne vais pas répéter la même chose ad nauseam. Lisez-vous vraiment les messages avec l'attention suffisante?

[frmfrm]

Encore une fois, dans le cadre d'un dématriçage unique. Et ce n'est pas de ça dont on discute ici. Maintenant, je ne vais pas répéter la même chose ad nauseam. Lisez-vous vraiment les messages avec l'attention suffisante?

Ben je pense c'est toi qui t'obstine avec ton histoire de dématricage unique.

Adobe a développé des outils et une procédure pour dématricer les raws. Tu penses qu'il change de stratégie en fonction d'un usage unique ou multiple ?

Lightroom utilise les profils de cameras, il ont ete pensé pour suivre un certain pipeline. Des développeurs indépendant peuvent produire leur propre profil et les utiliser dans lightroom. Z'ont pas à s'occuper d'un problème d'usage unique ou pas.

[Samoreen]

Je rends les armes.

[frmfrm]

Mais moi aussi, et il semble que d'après ce que j'ai lu, les corrections d'expos, de contraste etc.. se font après l'application de la table HueSatMap.

J'ai retrouvé la page où j'ai lu cela ( et ça peut aider à comprendre ce que l'on trouve dans le sdk dng ) :

http://dcptool.sourceforge.net/DCP%20FIles.html

A la fin de la page, on trouve la succession des étapes suivies par lightroom.

Les opérations effectuées à l'étape 7 n'obligent pas à à reprendre toute la procédure depuis le début.

Modifier, l'expo, le contraste, etc dans lightroom ne provoque pas un nouveau dématricage car il suffit de repartir des infos issues de l'étape 6 ( ou de l'étape 3 si le profile dcp ne comporte pas de table HueSatMap).