Vélocité de Photoshop

[Samoreen]

Dans un dématriceur j'intuite que cet ordre est toujours le même. Que je me préoccupe des niveaux avant ou après la température de couleur produira un résultat final identique. On repart du RAW.

Absolument. À chaque modification. C'est le point essentiel.

On parle souvent du dématriçage en le comparant au développement d'un film argentique. Mais c'est une très mauvaise comparaison. Le dématriçage, c'est comme si je pouvais redévelopper ma pellicule en lui faisant subir à nouveau tout le processus chimique comme si elle venait de sortir de mon boîtier.

Cette comparaison vaut plutôt, paradoxalement, pour le cas où je photographie en JPEG directement : le développement (dématriçage) a lieu dans l'appareil en fonction de mes réglages et une fois que c'est fait, c'est définitif et je ne peux plus revenir en arrière. C'est pour cela que l'on peut dire que photographier en JPEG est une pratique destructive.

[Miaz3]

 [at] Verso92 :

Je ne comprends pas bien le but de ton message... personne n'a écrit ici que tous les logiciels avaient le même flux de travail ni utilisaient les mêmes algorithmes de dématriçage, par exemple.

Je réagis juste la dessus :

LR est un dématriceur qui travaille en paramétrique sur un RAW qui ne doit pas être altéré ce qui conduit à recalculer l'image intégralement à chaque modification d'un réglage

Je n'ai pas pointé le dématriçage en particulier, mais plutôt un pre-dematricage. Ce qui permet de ne pas passer par un tampon (type bitmap, pixmap voir greymap) et donc de travailler en temps réel avec le fichier RAW.

[at] Samoreen :

Non. Pas de doc Adobe.

D'accord.

Vous confondez les algorithmes de dématriçage qui sont propres à chaque éditeur de logiciel et le processus général de dématriçage qui est le même pour tout le monde.

Bhé je ne vois pas la différence, dans le sens ou : les algorithmes de dematricage font partis du processus général de dématriçage.
[at] voxpopuli :

Il y a un élément très important à prendre en compte dans le coté "destructif" c'est l'ordre dans lesquels sont exécutés les changements.

Exactement, c'est la concaténation.
Ça n'a rien à voir avec les logiciels de photos, mais c'est toujours bon de voir en image ce que ça peut donner.

[Miaz3]

 [at] Verso92 :
En gros ce que je cherche, c'est de savoir comment PS fonctionne après avoir passer son RAW sous ACR. Quel est sont fonctionnement (réel et non pas par supposition).
voxpopuli vise juste en posant cette question, car c'est se que j'aimerai connaitre. CàD : La manière dont PS concaténise les informations.

[voxpopuli]

[at] Verso92 :
En gros ce que je cherche, c'est de savoir comment PS fonctionne après avoir passer son RAW sous ACR. Quel est sont fonctionnement (réel et non pas par supposition).
voxpopuli vise juste en posant cette question, car c'est se que j'aimerai connaitre. CàD : La manière dont PS concaténise les informations.

Il te faudra postuler chez Adobe pour connaitre les arcanes du produit, sûrement plus complexes qu'on ne l'imagine vu l'histoire et le nombre de versions de photoshop. Tu auras peut-être tes chances si tu es mathématicien de haut vol.

Vu de notre PC nous ne pouvons que déduire la logique d'un produit à partir de notre expérience sans être vraiment sûr de la véracité de nos constatations 

[Samoreen]

Bhé je ne vois pas la différence, dans le sens ou : les algorithmes de dematricage font partis du processus général de dématriçage.

Reprenons. Je répondais à l'assertion suivante :

Bien sur que non, chaque logiciel a son propre flux de travail. Sinon il n'y aurait aucune utilité à choisir tel ou tel logiciel s'ils avaient tous la même "façon" de procéder.

Je disais donc que le problème posé à chaque éditeur d'un dématriceur est strictement le même, quel que soit l'appareil, quel que soit le capteur (exception faite des Fovéon et des X-Trans de Fuji) : interpoler une matrice de Bayer à partir des paramètres fournis par l'utilisateur. Cela ne peut se faire que d'une manière (et le pré-dématriçage de Rawtherapee n'est que marginal dans ce processus) :

- Récupérer les données brutes du RAW.
- Produire un aperçu calculé avec les valeurs par défaut des paramètres de développement et l'afficher à l'écran.
- Attendre les changements de paramètres spécifiés par l'utilisateur.
- Calculer un nouvel aperçu à chaque changement de paramètre et l'afficher.
- Boucler jusqu'à ce que l'utilisateur décide d'exporter ou d'abandonner provisoirement le traitement de cette image.

Je ne vois pas d'autre flux général possible. Si vous trouvez un dématriceur qui fonctionne autrement que comme décrit ci-dessus, faites nous signe, ça devrait être une curiosité intéressante.

Les dématriceurs peuvent différer essentiellement sur 2 points :

- Le calcul de l'aperçu (plus rapide chez LR par exemple que chez DxO Optics Pro mais c'est logique si le calcul d'interpolation est plus poussé chez ces derniers, ce qui est le cas de manière évidente chez DxO).

- Le calcul d'interpolation lui-même qui peut par exemple prendre en compte plus ou moins de pixels dans l'environnement du pixel en cours de calcul. De même, le résultat du calcul des 2 valeurs RVB manquantes du pixel en cours, pour un nombre donné de pixels voisins examinés, varie selon la manière dont on pondère les valeurs trouvées dans les pixels voisins. Il y a d'autres éléments qui peuvent ou non être pris en compte par le dématriceur.

Chaque éditeur utilise la méthode d'interpolation et de pondération de son choix - et ne la publie jamais, sauf quand le source du logiciel est en accès libre - et c'est ça, et seulement ça globalement, qui différencie les dématriceurs entre eux. Le reste est une question de conception de l'interface utilisateur et de mise à disposition de fonctions complémentaires améliorant le confort. Mais aucun, que je sache, ne dévie du flux décrit plus haut.

Ces différences dans la technique d'interpolation ne changent rien sur le flux général  de dématriçage ou sur les contraintes et avantages liés à cette technique comparée au travail sur une bitmap.

[Miaz3]

 [at] voxpopuli :
Bon c'est juste par curiosité et au détour de cette conversation, hein.
Pour la petite histoire :
Il y a quelques années de ça ont voulaient intégrer des traitement PS à notre pipeline et les développeurs avaient un compte dev chez Adobe.
Mais certains points étaient mal documentés et après moult retours par mail ont a laissé tomber pour passer sur des logiciels plus open

Après, c'était particulier. Mais disons que;
quand j'achète un logiciel j'aime savoir se qui se passe derrière les boutons et si je veux intégrer ce logiciel à mon flux de travail avoir une documentation digne de ce nom.
Ce n'est pas le cas d'adobe.

edit:  [at] Samoreen je n'ai pas le temps de lire votre post, je reviendrai après l'apéro

[Verso92]

[at] Verso92 :
En gros ce que je cherche, c'est de savoir comment PS fonctionne après avoir passer son RAW sous ACR. Quel est sont fonctionnement (réel et non pas par supposition).

A vrai dire, je ne comprends pas bien ta question... une fois que le fichier RAW a été ouvert (développé) avec ACR, tu te retrouves avec une "classique" image bitmap (3 X 8 bits ou 3 X 16 bits en fonction de ton paramétrage dans ACR) en mémoire.

Et là, tu pourras enregistrer cette image bitmap dans le format de fichier qui te convient (TIFF, Jpeg, etc).
Après,  les mécanismes induits quand on ouvre le fichier RAW en tant qu'objet dynamique, aucune idée...

[Miaz3]

 [at] Samoreen :
Ça va un peu loin pour pas grand-chose...

Ce que je voulais savoir, c'était ça :

PS et consorts travaillent sur une bitmap de manière destructive. LR est un dématriceur qui travaille en paramétrique sur un RAW qui ne doit pas être altéré ce qui conduit à recalculer l'image intégralement à chaque modification d'un réglage. C'est donc un calcul beaucoup plus intensif qu'un travail destructif sur une bitmap.

Maintenant je sais que c'est sur votre expérience professionnelle en temps qu'un ingénieur logiciel que vous tirez cette conclusion.
Ne remettant en rien a la véracité de vos propos.
Moi ce que je cherche c'est une documentation qui appuierait votre conclusion.

Ce n'est pas compliqué ?

La ou je reste septique c'est le fait de dire qu'ils travaillent sur une bitmap de manière destructive.
En quoi elle serait destructive ?
Qui vous dit qu'ils passent par du bitmap ? Et pas un pixmap ? Ou exr... voir un autre format proprio qui donnerait lieu à plus d'info peut-être ? Je sais pas mais je me pose ces questions...

[Samoreen]

Moi ce que je cherche c'est une documentation qui appuierait votre conclusion.

Je ne pense pas que ça existe. Un développeur peut toujours lire le code source d'un logiciel Open Source comme Rawtherapee mais je l'ai vu et c'est très peu documenté. Illisible par le non programmeur. Il doit bien exister quelques documents de recherche mais je n'en ai pas vu jusqu'ici.

Là ou je reste septique...

Navré, c'est un état que l'on ne souhaite à personne.   Désolé, je ne sais pas résister à ce genre d'opportunité quand on me tend la perche. C'est une manie détestable, je sais.

Là ou je reste septique c'est le fait de dire qu'ils travaillent sur une bitmap de manière destructive.
En quoi elle serait destructive ?

J'ai expliqué plus haut ce que destructif veut dire. Je n'y reviens pas.

Qui vous dit qu'ils passent par du bitmap ? Et pas un pixmap ? Ou exr... voir un autre format proprio qui donnerait lieu à plus d'info peut-être ? Je sais pas mais je me pose ces questions...

Vous faites une nouvelle confusion. Dans ce contexte, on ne parle pas de bitmap en tant que format (.bmp ?) mais en tant que type de représentation d'une image. En fait, je ne sais pas si qui que ce soit en dehors d'Adobe sait exactement dans quel format sont les bitmaps utilisées en interne par Photoshop. On sait juste que l'on peut enregistrer l'image dans un des nombreux formats standard proposés, dont le .bmp.

Pour les logiciels comme PS, on parle de représentation bitmap, c-à-d une représentation où chaque pixel porte sur un ou deux octets une information couleur et luminance complète. Ce qui est totalement différent de la représentation des données dans un dématriceur : un ensemble de pixels portant seulement une information de luminance - le plus souvent sur 12 bits - pour une seule couleur et qui, de plus, ne doit jamais être altérée. C'est la "nuance" fondamentale qui explique que, pour répondre au post initial, un dématriceur n'est absolument pas comparable à un logiciel d'édition d'image en mode bitmap et qu'ils ne couvrent pas les mêmes champs d'application.

[Miaz3]

Je ne pense pas que ça existe. Un développeur peut toujours lire le code source d'un logiciel Open Source comme Rawtherapee mais je l'ai vu et c'est très peu documenté. Illisible par le non programmeur. Il doit bien exister quelques documents de recherche mais je n'en ai pas vu jusqu'ici.

Dans le cas présent, j'ai toujours trouvé se que je voulais sur ( http://rawpedia.rawtherapee.com). Par contre chez Adobe, non.
On parlait de concaténation plus haut, quid sur PS...néant.
Bon après c'est un cas général dans tous les logiciels de retouche d'image fixe (photo), mais c'est frustrant.

Navré, c'est un état que l'on ne souhaite à personne.  Sourire Désolé, je ne sais pas résister à ce genre d'opportunité quand on me tend la perche. C'est une manie détestable, je sais.

Hehe on ne se refait pas

D'accord, j'ai lu en diagonal "une bitmap de manière destructive." J'étais partis sur le format de fichier alors que vous expliquez un procédé. méaculpa.
J'ai souvent entendu pixmap surtout quand on parle plus de pixel que d'image, plutôt que de bitmap, ou raw bitmap mais j'aurai du tiqué car il n'étais pas suivit de "format".
En tout cas quand je vois ça, ça porte à confusion :

Pour les logiciels comme PS, on parle de représentation bitmap

Le bitmap, celui dont je parlai plus haut est le "portable bitmap" (.pbm) un fichier d'échange graphique dont bon nombre ne logiciels d'image fixe utilise.
En fait c'est plutôt une famille de fichier d'échange, chaque format à sont utilité. Dont par exemple; le graymap qui est souvent utilisé pour la représentation des données brutes du capteur et qui permet d'étudier le malfonctionnement du capteur (pixel chaud, mort...ect).

[jipT]

...
Il s'agit juste de faire la différence entre les traitements sur une image bitmap (à savoir déjà développée et possédant pour chaque pixels ses composantes RVB "gravées dans le marbre") et les traitement en RAW (sur un fichier ne contenant encore qu'un mapping de valeurs de luminance associées à une matrice de filtrage, une image en devenir, en quelque sorte).

Attention par contre, un traitement paramétrique s'applique aussi à partir d'une bitmap, ce n'est pas une méthode propre au RAWs, c'est clairement ce que fait LR lorsqu'on travaille sur des JPG (c'est d'ailleurs un avantage car il n'y a pas de perte à la sauvegarde comme il pourrait y en avoir sur un logiciel bitmap)
Bien entendu certains traitements comme la balance des blancs sont impossibles (ou de manières simplifiés) sur un fichier bitmap.

jip

[Samoreen]

Attention par contre, un traitement paramétrique s'applique aussi à partir d'une bitmap, ce n'est pas une méthode propre au RAWs...

Oui. Mais avec un RAW, seul le traitement paramétrique est possible. Avec les JPEGs et les TIFFs, on fait du traitement paramétrique sur un fichier déjà développé et les possibilités d'interprétation sont donc très réduites.

[Verso92]

Attention par contre, un traitement paramétrique s'applique aussi à partir d'une bitmap, ce n'est pas une méthode propre au RAWs, c'est clairement ce que fait LR lorsqu'on travaille sur des JPG (c'est d'ailleurs un avantage car il n'y a pas de perte à la sauvegarde comme il pourrait y en avoir sur un logiciel bitmap)

Là, je ne vois pas en quoi il n'y aurait pas de pertes à la sauvegarde en Jpeg avec LR et pas avec Photoshop, par exemple...

[Gérard_M]

Lightroom ne modifie pas l'image originale. Lightroom ne modifie pas l'image originale.. Lightroom ne modifie pas l'image originale.
Celà doit bien faire 10000 fois qu'on l'écrit, le crie
Lightroom inscrit les modifications apportées dans l'entete du fichier jpeg sans modifier l'image elle même, et elles sont visibles sous LR sans recompresser....
La sauvegarde sous Lightroom est celle du catalogue.

[Verso92]

Lightroom ne modifie pas l'image originale. Lightroom ne modifie pas l'image originale.. Lightroom ne modifie pas l'image originale.
Celà doit bien faire 10000 fois qu'on l'écrit, le crie
Lightroom inscrit les modifications apportées dans l'entete du fichier jpeg sans modifier l'image elle même, et elles sont visibles sous LR sans recompresser....
La sauvegarde sous Lightroom est celle du catalogue.

?

[Miaz3]

Traitement paramétrique.
Peu importe l'original il ne sera pas modifié, les traitements sont enregistrés sous forme de métadonnées.

[Samoreen]

Là, je ne vois pas en quoi il n'y aurait pas de pertes à la sauvegarde en Jpeg avec LR et pas avec Photoshop, par exemple...

Encore un malentendu. Ne pas confondre "export en JPEG depuis LR" avec "enregistrement des corrections dans le JPEG original" quand il est traité dans LR.

Tant qu'on ne se décidera pas à utiliser les bons mots, on continuera à perdre du temps sur ces quiproquos.

"Mal nommer un objet, c'est ajouter aux malheurs du monde" - Albert Camus.

[gerarto]

Bon, si j'ai bien compris, on ne "perd" rien avec le traitement paramétrique d'un jpeg par LR...
tant qu'on ne fait pas de sortie du jpeg d'origine traité !

En fait ce qui est sûr, c'est qu'on ne perd rien des données paramétriques de traitement, ça, c'est sûr !

[Verso92]

Encore un malentendu. Ne pas confondre "export en JPEG depuis LR" avec "enregistrement des corrections dans le JPEG original" quand il est traité dans LR.

Tant qu'on ne se décidera pas à utiliser les bons mots, on continuera à perdre du temps sur ces quiproquos.

"Mal nommer un objet, c'est ajouter aux malheurs du monde" - Albert Camus.

Bon, OK...
En même temps, j'ai toujours considéré le Jpeg comme un format de sortie, sur une image finalisée. L'utiliser en tant que format d'entrée, même "en paramétrique", j'ai du mal à en saisir l'intérêt.

[Bélisaire]

Je me permets d'intervenir... Même si mon domaine de compétence ne me permet pas de saisir tout le pointu des interventions des uns et des autres, j'ai compris qu'il a surtout été question de modifications de l'image, et de la différence de traitement entre Photoshop et Lightroom (pour ne citer qu'eux). Dans mon message initial, j'ai (aussi) fait allusion à la rapidité d'affichage du premier, c'est-à-dire à une manipulation du logiciel sans (apparent) traitement de l'image. J'ai fait l'essai avec un tif de 900 mo "inconnu" des deux logiciels. L'affichage à 100% par Photoshop est quasi instantané (pas le temps de chronométrer); il faut plus de 23 secondes à Lightroom. Pour que Lightroom descende à la seconde, il faut d'abord que l'image ait été mise en cache. Même si l'on suppose que Photoshop met l'image en cache à son chargement, sachant qu'une poignée de secondes lui suffit  pour le faire, il est rapide. A moins que Lightroom, pour demander aussi longtemps, fasse simultanément, lui, autre chose...

[gigi4lm]

Il y a un élément très important à prendre en compte dans le coté "destructif" c'est l'ordre dans lesquels sont exécutés les changements.

Dans un dématriceur j'intuite que cet ordre est toujours le même. Que je me préoccupe des niveaux avant ou après la température de couleur produira un résultat final identique. On repart du RAW.

...

Oui, ... mais pas tout à fait.

Il y a un ordre logique à l'application des différents outils et la modification de cet ordre peut avoir (certes, à la marge) des conséquences sur le résultat final.
Un exemple :
Si je commence à appliquer les réglages de tonalité avant un recadrage, l'histogramme sera influencé par les parties qui seront coupées. Je pourrait  bien sûr me concentrer sur la surface finale de l'image en faisant abstraction de la partie à couper mais l'histogramme me donnera une indication perturbante.

[asak]

Oui, ... mais pas tout à fait.

Il y a un ordre logique à l'application des différents outils et la modification de cet ordre peut avoir (certes, à la marge) des conséquences sur le résultat final.
Un exemple :
Si je commence à appliquer les réglages de tonalité avant un recadrage, l'histogramme sera influencé par les parties qui seront coupées. Je pourrait  bien sûr me concentrer sur la surface finale de l'image en faisant abstraction de la partie à couper mais l'histogramme me donnera une indication perturbante.

Mais c'est bien d'avoir l'histogramme en temps réel.
Photoshop et destructif ?
Quand on peut embarquer plusieurs xmp différent sur un brut identique ou sur des brut différents  et qui permet de revenir en arriére à tout moment.
C'est plutôt la façon d'utiliser et d'enregistrer qui est destructive.
On peut vouloir travailler un jpg de téléphone par exemple et de ne pas être destructif le travailler de la même manière qu'un brut.
Photoshop véloce dans ses déplacement d'images certainement; mais son utilisation il n'est pas véloce du tout applique certains filtres sur tes fichiers et tu comprendras qu'il faut des machines extraterrestres. 

[Samoreen]

A moins que Lightroom, pour demander aussi longtemps, fasse simultanément, lui, autre chose...

Calculer l'aperçu et adapter la structure de l'image qui n'est pas faite a priori pour être entrée dans un dématriceur.

Comme l'a dit Verso92 ci-dessus, partir d'un JPEG ou d'un TIFF dans un dématriceur n'est pas d'un intérêt évident. C'est juste une facilité qui permet de finaliser les réglages sur une image en retour d'un plugin ou d'un programme externe (en fait, c'est la même chose). Ça permet aussi de traiter dans LR une image qui sort d'un scanner. Mais ce n'est pas la destination première du programme qui est de développer des RAWs et pas de traiter des bitmaps.

Donc encore une fois, la comparaison ne fait pas sens. Je peux entretenir ma pelouse avec une tondeuse à gazon et arracher mes poils de barbe récalcitrants avec une pince à épiler. Mais si j'utilise la pince à épiler pour égaliser mon gazon, je ne vais pas lui reprocher d'être plus lente que la tondeuse.

[tenmangu81]

Bon, une question tout de même. Quid des "corrections locales" effectuées dans LR ou C1 ? Peuvent-elles toujours être considérées comme "paramétriques" ?

[Samoreen]

Bon, une question tout de même. Quid des "corrections locales" effectuées dans LR ou C1 ? Peuvent-elles toujours être considérées comme "paramétriques" ?

Absolument. Il suffit pour s'en convaincre de regarder le XMP d'une image à laquelle sont appliquées des corrections locales. On y trouve facilement la définition de la ou des correction(s) et la description cartographique de la ou des zone(s) affectée(s). Le volume de texte généré explique pourquoi la mise à jour automatique des XMPs contenant de nombreuses corrections locales peut ralentir un système de puissance modérée: il faut de plus en plus de temps pour écrire et interpréter le texte du code XML correspondant.