Vélocité de Photoshop

[Bélisaire]

Bonjour. Quelqu'un sait-il comment Photoshop se débrouille pour avoir un affichage si véloce ? Quelle que soit son poids (aujourd'hui un panorama tif de plus d'un giga), on peut balader l'image d'un bord à l'autre de l'écran, à 100% (affichage parfait instantané), avec une fluidité incroyable, qu'on ne retrouve dans aucun autre logiciel, Lightroom y compris, y compris lorsque l'aperçu 1:1 a été créé. Les autres logiciels devraient s'en inspirer. Pourquoi le cousin Lightroom ne bénéficie-t-il pas du même moteur ?

[Verso92]

Je dirais que l'intégralité de l'image est en mémoire, et que scroller dans la photo n'est qu'un décalage des données contenues en mémoire...

[Bélisaire]

Merci. J'avais songé à un truc comme ça. Ça rend bien des services lors des retouches ponctuelles, alors que dans d'autres logiciels, c'est la galère.

[ChatOuille]

Je le pense aussi mais je demande aussi pourquoi les autres logiciels ne font pas pareil.

[Verso92]

Je le pense aussi mais je demande aussi pourquoi les autres logiciels ne font pas pareil.

Je pense que tous les logiciels qui manipulent des images bitmap font pareil...

[Samoreen]

on peut balader l'image d'un bord à l'autre de l'écran, à 100% (affichage parfait instantané), avec une fluidité incroyable, qu'on ne retrouve dans aucun autre logiciel, Lightroom y compris, y compris lorsque l'aperçu 1:1 a été créé. Les autres logiciels devraient s'en inspirer. Pourquoi le cousin Lightroom ne bénéficie-t-il pas du même moteur ?

Je crois que nous allons rééditer la même sempiternelle explication... 

Comparer PS et LR sur ce point, n'a tout simplement pas de sens. 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.

De plus, PS, puisqu'il travaille sur une bitmap, peut bénéficier à plein d'un certain nombre de mécanismes de gestion mémoire comme les fichiers mappés en mémoire (MMF - Memory Mapped Files) qui permettent de voir même un très gros fichier comme un simple tampon en évitant des opérations d'entrée/sortie au niveau de l'application et en les déléguant aux couches basses du système. LR peut aussi utiliser ces mécanismes mais de par son mode de fonctionnement, il en tirera moins profit, le calcul étant prépondérant dans LR.

[Samoreen]

C'est donc un calcul beaucoup plus intensif qu'un travail destructif sur une bitmap.

Citation de ma définition du terme "destructif" donnée dans un autre fil:

Je pense qu'il y a une mauvaise compréhension de ce que signifie le terme "destructif" dans ce contexte. Il y a un aspect séquentiel à prendre en compte. Quand on dit que les manipulations sur une bitmap sont destructives, cela signifie que si j'applique des corrections avec un outil A puis d'autres corrections avec un outil B, je ne peux plus revenir sur ce que j'ai fait avec l'outil A sans annuler d'abord ce que j'ai fait avec l'outil B car la structure de la bitmap a été modifiée. Mes données de base ont changé.

Si je travaille en mode paramétrique sur un RAW, je peux revenir sur les modifications effectués avec l'outil A sans toucher à ce que j'ai fait avec l'outil B. Ces réglages n'ont en fait pour conséquence que l'enregistrement de paramètres en mémoire ou dans un catalogue mais pas la modification des données sous-jacentes qui restent toujours inchangées. Quand on travaille sur un RAW, il ne faut pas oublier que l'image est recalculée à chaque modification d'un paramètre en reprenant en compte l'ensemble des paramètres.

Avec une bitmap, on applique une modification sans tenir compte de ce qui a été fait avant. C'est cela l'aspect destructeur. Sous Photoshop, le problème peut être atténué avec l'utilisation de filtres et de calques dynamiques mais en fait, cela revient pratiquement à faire du paramétrique et à travailler sur plusieurs bitmaps en même temps.

[Samoreen]

Autre citation d'un de mes posts dans un fil plus ancien:

PS travaille toujours sur une (ou plusieurs) bitmap(s) qu'il modifie à l'envi en fonction des outils utilisés. LR est outil paramétré non destructif qui ne modifie pas l'image de base mais enregistre des commandes qui sont simulées à l'écran et qui seront appliquées à l'image uniquement au moment de l'export. Avec un tel mécanisme, il est impossible de reproduire tout ce que l'on peut faire sur une bitmap en mode destructif. Sauf à disposer d'une puissance machine et d'une capacité mémoire qui ne seront pas à l'ordre du jour avant très, très longtemps.

Il suffit de voir comment LR commence à peiner dès que l'on multiplie de manière exagérée le nombre de corrections, de masques de retouche locale, etc. , même sur une machine très puissante, pour se rendre compte que cette limite existe bel et bien. LR est d'abord un dématriceur (de haut niveau) mais ça n'ira pas beaucoup plus loin. D'autres ont d'ailleurs pris une position plus radicale sur ce sujet : DxO limite clairement les fonctions de DOP à celles d'un dématriceur et refuse d'y ajouter des fonctions qui ne font pas partie du job comme la retouche locale par exemple. Je l'ai un moment regretté, je commence à trouver que c'est un choix assez pertinent, finalement. Chacun son boulot.

[OuiOuiPhoto]

Mais PS avec les objets dynamique et les calques de réglage ce n'est pas destructeur non plus . Si ?

[voxpopuli]

Mais PS avec les objets dynamique et les calques de réglage ce n'est pas destructeur non plus . Si ?

Et là je prends les cahouettes 

[OuiOuiPhoto]

Et là je prends les cahouettes 

Prend moi une biere en passant s'il te plait

[Samoreen]

Mais PS avec les objets dynamique et les calques de réglage ce n'est pas destructeur non plus . Si ?

Voir ci-dessus la définition de "destructif".

[OuiOuiPhoto]

Voir ci-dessus la définition de "destructif".

cela signifie que si j'applique des corrections avec un outil A puis d'autres corrections avec un outil B, je ne peux plus revenir sur ce que j'ai fait avec l'outil A sans annuler d'abord ce que j'ai fait avec l'outil B  C'est quoi pour toi un outil ? Car avec les objets dynamiques et les Filtres dynamiques je peux faire par exemple un Color FX puis un Analog FX. Si je veux changer le Color FX je n'ai pas besoin d'annuler l'Analog FX. L'analog FX se réapliquera en prenant en compte le changement sur le Color FX. J'ai pris Analog et Color FX mais le principe est le même avec tout ce que tu peux régler sur l'image. Et d'ailleurs a ce moment la Photoshop perd un poil de sa vélocité

Aller je reprend une bière

[voxpopuli]

cela signifie que si j'applique des corrections avec un outil A puis d'autres corrections avec un outil B, je ne peux plus revenir sur ce que j'ai fait avec l'outil A sans annuler d'abord ce que j'ai fait avec l'outil B  C'est quoi pour toi un outil ? Car avec les objets dynamiques et les Filtres dynamiques je peux faire par exemple un Color FX puis un Analog FX. Si je veux changer le Color FX je n'ai pas besoin d'annuler l'Analog FX. L'analog FX se réapliquera en prenant en compte le changement sur le Color FX. J'ai pris Analog et Color FX mais le principe est le même avec tout ce que tu peux régler sur l'image. Et d'ailleurs a ce moment la Photoshop perd un poil de sa vélocité

Aller je reprend une bière

Oui, mais dans quel ordre ?

Je passe aux pistaches

[OuiOuiPhoto]

Oui, mais dans quel ordre ?

Ok. Compris

[Miaz3]

Comparer PS et LR sur ce point, n'a tout simplement pas de sens. 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.

Tiens, curieux ça. Tu aurai une doc de adobe qui explique tout ça ?

[Verso92]

Tiens, curieux ça.

Je ne vois pas ce qu'il y a de curieux...
Une image bitmap est une image construite, finalisée, qui a une existence propre : chaque pixel a ses valeurs RVB associées, sur 8 ou 16 bits de profondeur.

Si tu ajoutes 5 points de rouge à cette image bitmap, par exemple, elle est transformée en conséquence.
Quand du développes un RAW avec un dématriceur, ce n'est que la visualisation à l'écran du développement qui est changée (en aucun cas les valeurs originales du RAW, bien sûr). Ce n'est qu'au moment de l'exportation pour créer l'image bitmap que cette correction de 5 points de rouge deviendra effective.
En d'autres termes, sous Photoshop il faut revenir en arrière pour annuler la correction qui a été apportée à l'image. En RAW, il faut juste décocher la correction qui n'a pas encore été appliquée à l'image (juste à la pré-visualisation de celle-ci, une sorte de "simulation" de ce qu'elle sera une fois exportée)...

[Samoreen]

Tiens, curieux ça. Tu aurai une doc de adobe qui explique tout ça ?

Pas besoin de doc, c'est la base du processus de dématriçage que ce soit pour LR ou DxO Optics Pro ou autre.

Supposons une simple modification du curseur "hautes lumières". Ce seul réglage implique de refaire l'ensemble du calcul d'interpolation pour la reconstitution des 2 composantes couleur manquantes pour chaque pixel. Si ce n'était pas le cas, ça irait aussi vite que pour une bitmap (dans PS ou autre) et surtout, on aurait les mêmes possibilités de récupération pour les JPEG et les TIFF que pour les RAW. Or on sait bien que ce n'est pas le cas.

Si on fait une bien meilleure récupération sur les RAW, c'est que l'on recommence le calcul de dématriçage à chaque fois. Ce qui est impossible sur les JPEG et les TIFF puisque le dématriçage a déjà été fait de manière définitive (soit dans l'appareil, soit dans un logiciel de manipulation de bitmap - PS, plugin, etc.) et que l'on ne peut plus revenir dessus (on ne dispose plus des données de départ - on ne peut plus faire autre chose que les dégrader encore et encore à chaque modification).

C'est bien là la différence majeure entre dématriçage et édition de bitmap. Dématricer, c'est appliquer dans un certain ordre un ensemble de paramètres stockés de manière externe à l'image de manière à produire une bitmap affichable à l'écran ou exportable dans un JPEG ou un TIFF. Si on change un des ces paramètres, on doit recommencer le calcul.

[Samoreen]

cela signifie que si j'applique des corrections avec un outil A puis d'autres corrections avec un outil B, je ne peux plus revenir sur ce que j'ai fait avec l'outil A sans annuler d'abord ce que j'ai fait avec l'outil B  C'est quoi pour toi un outil ? Car avec les objets dynamiques et les Filtres dynamiques je peux faire par exemple un Color FX puis un Analog FX. Si je veux changer le Color FX je n'ai pas besoin d'annuler l'Analog FX. L'analog FX se réapliquera en prenant en compte le changement sur le Color FX.

Un outil, c'est n'importe quel réglage.

Comme je l'ai déjà expliqué, l'utilisation des filtres dynamiques n'est pas l'équivalent d'un dématriçage non destructif. La comparaison n'est pas valide. Les objets et filtres dynamiques dans PS, ce n'est ni plus ni moins que de la duplication de bitmaps. On continue de travailler en mode destructif (tel que je l'ai décrit plus haut) mais sur des bitmaps différentes (qui sont recombinées pour l'affichage). Le retour en arrière n'est possible que parce que l'on stocke en mémoire différents états des données (comme pour n'importe quel mécanisme d'undo/redo).

[Samoreen]

Si ça peut aider, j'ai une autre explication plus technique du terme destructif (en général très mal compris). J'avais posté ça sur le forum C1:

En édition de bitmap, on travaille avec une succession d'états finis réversibles uniquement en séquence inverse par une opération d'undo (sauf dans Photoshop avec les filtres dynamiques, voir ci-dessus - référence au texte ci-dessous entre crochets).

[Sous Photoshop, le problème peut être atténué avec l'utilisation de filtres et de calques dynamiques mais en fait, cela revient pratiquement à faire du paramétrique et à travailler sur plusieurs bitmaps en même temps.]

En mode paramétrique, les données sont dans un état indéfiniment stable et les corrections produisent au fur et à mesure, à l'aide du moteur de dématriçage et du moteur de visualisation, une virtualisation à l'écran de ce que sera l'état transformé une fois que l'ensemble des paramètres sera appliqué pour la production d'un autre ensemble de données stockées indépendamment des données initiales.

C'est d'ailleurs pour cela qu'il est imprudent de considérer que ce que l'on voit à l'écran dans un dématriceur est le reflet exact de ce qui sortira dans un fichier de sortie au format TIFF ou JPEG ou de ce qui sera imprimé (mes tirages sont toujours meilleurs que ce que je vois sur mon écran).

[OuiOuiPhoto]

comme pour n'importe quel mécanisme d'undo/redo

D'ailleur c'est assez visible. Dans mon exemple Color FX et Analog FX si je fais le moindre changement a un des deux il ya  plain de trucs qui se passent avant de pouvoir avoir l'image finale visible

[Miaz3]

Je ne vois pas ce qu'il y a de curieux...

J'aurai du raccourcir la citation :

Comparer PS et LR sur ce point, n'a tout simplement pas de sens. PS et consorts travaillent sur une bitmap de manière destructive.

Donc je réitère ma question, as-tu une doc technique qui explique ça ?
Je ne cherche pas la petite bête, je cherche juste à savoir d'où tu tiens cette information car je n'ai rien trouvé de tel sur internet. Même sur le Adobe labs il n'en parle pas.
Ceux qu'y utilisent DcRAW peuvent comprendre comment le pixmap fonctionne et ses limitations, mais cela étant on ne sais pas comment PS ou LR le gère...

Pas besoin de doc, c'est la base du processus de dématriçage que ce soit pour LR ou DxO Optics Pro ou autre.

Bien sur que non, chaque logiciel à sont propre flux de travail. Sinon il n'y aurai aucunes utilitées de choisir tel ou tel logiciels s'ils avaient tous la même "façon" de procéder.
Exemple avec Rawtherapee qui à sa propre méthode de pre-dématricage en 32 bits float... (page 11)

[Verso92]

Bien sur que non, chaque logiciel à sont propre flux de travail. Sinon il n'y aurai aucunes utilitées de choisir tel ou tel logiciels s'ils avaient tous la même "façon" de procéder.
Exemple avec Rawtherapee qui à sa propre méthode de pre-dématricage en 32 bits float... (page 11)

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

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

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.

Dans Photoshop ou tout autre éditeur bitmap c'est bien différent (je ne parle pas du module de dématricage ACR évidemment). Dans un logiciel bitmap C'est l'opérateur qui décide de l'ordre dans lequel s'effectueront les opérations selon la disposition des calques. Et le résultat du calcul s'appuie sur le résultat du calcul précédent d'ou le côté destructeur comme évoqué par Samoreen.

Pour les plugins Nik Software c'est la même chose y compris dans les calques dynamiques. La séquence recommandée par Nik  (de mémoire)
- dfine
- raw pre sharpener
- viveza
- colorefex/silverefex/analogefex/hdrefex(pour moi c'est un des 4)
- sharpener

Pour l'observer il suffit de partir de la même image en appliquant les mêmes filtres dans une séquence différente sur deux calques et ensuite de les comparer par différence ou exclusion.

Ces filtres ne sont pas obligatoires seul l'ordre de ces filtres est important quand ils sont utilisés.

Et la vélocité de calcul en prend un coup avec un empilement de filtres nik dans un calque dynamique. Il recalcule chaque filtre selon l'ordre dans lequel on les a ajoutés.

[Samoreen]

J'aurai du raccourcir la citation :Donc je réitère ma question, as-tu une doc technique qui explique ça ?

Non. Pas de doc Adobe. Je me suis simplement éduqué par la lecture de nombreux ouvrages et mon expérience d'ingénieur software m'a aidé à comprendre ce qui se passait lors d'un dématriçage.

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

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. Dans le cas de la matrice de Bayer, le problème de départ est identique : il s'agit de calculer par interpolation, pour chaque pixel, les 2 composantes couleur manquantes. Chaque logiciel réalise cette interpolation à sa manière. Pour le reste et en particulier pour la façon dont se déroule un développement paramétrique en comparaison avec l'édition d'une bitmap, c'est la même chose pour tout le monde.