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 ?
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...
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.
Je le pense aussi mais je demande aussi pourquoi les autres logiciels ne font pas pareil.
Citation de: ChatOuille le Avril 16, 2016, 18:18:59
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...
Citation de: Bélisaire le Avril 16, 2016, 11:53:30
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... ;D
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.
Citation de: Samoreen le Avril 16, 2016, 18:46:53
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.
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.
Mais PS avec les objets dynamique et les calques de réglage ce n'est pas destructeur non plus . Si ?
Citation de: OuiOuiPhoto le Avril 16, 2016, 19:40:35
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 ;D
Citation de: voxpopuli le Avril 16, 2016, 19:58:21
Et là je prends les cahouettes ;D
Prend moi une biere en passant s'il te plait :D
Citation de: OuiOuiPhoto le Avril 16, 2016, 19:40:35
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".
Citation de: Samoreen le Avril 16, 2016, 21:59:05
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 ;)
Citation de: OuiOuiPhoto le Avril 16, 2016, 23:13:18
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
CitationComparer 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 ?
Citation de: Miaz3 le Avril 17, 2016, 10:56:52
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)...
Citation de: Miaz3 le Avril 17, 2016, 10:56:52
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.
Citation de: OuiOuiPhoto le Avril 16, 2016, 23:13:18
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).
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).
Citation de: Samoreen le Avril 17, 2016, 11:32:21
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
CitationJe ne vois pas ce qu'il y a de curieux...
J'aurai du raccourcir la citation :
CitationComparer 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...
CitationPas 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... (http://rawtherapee.com/shared/obsolete/RawTherapeeManual_4.0.11_fr.pdf) (page 11)
Citation de: Miaz3 le Avril 17, 2016, 13:16:27
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... (http://rawtherapee.com/shared/obsolete/RawTherapeeManual_4.0.11_fr.pdf) (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).
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.
Citation de: Miaz3 le Avril 17, 2016, 13:16:27
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.
Citation de: Miaz3 le Avril 17, 2016, 13:16:27
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.
Citation de: voxpopuli le Avril 17, 2016, 13:35:55
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.
[at] Verso92 :
CitationJe 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 :
CitationLR 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 :
CitationNon. Pas de doc Adobe.
D'accord.
CitationVous 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 :
CitationIl 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 (http://www.nukepedia.com/written-tutorials/concatenation-of-transforms-in-nuke/).
[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.
Citation de: Miaz3 le Avril 17, 2016, 16:34:59
[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 ;)
Citation de: Miaz3 le Avril 17, 2016, 14:36:09
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.
[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 ;)
Citation de: Miaz3 le Avril 17, 2016, 16:34:59
[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...
[at] Samoreen :
Ça va un peu loin pour pas grand-chose...
Ce que je voulais savoir, c'était ça :
CitationPS 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...
Citation de: Miaz3 le Avril 17, 2016, 20:41:03
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.
Citation de: Miaz3 le Avril 17, 2016, 20:41:03
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.
Citation de: Miaz3 le Avril 17, 2016, 20:41:03
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.
Citation de: Miaz3 le Avril 17, 2016, 20:41:03
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.
CitationJe 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.
CitationNavré, 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 :
CitationPour 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).
Citation de: Verso92 le Avril 17, 2016, 13:24:51
...
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
Citation de: jipT le Avril 18, 2016, 12:16:50
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.
Citation de: jipT le Avril 18, 2016, 12:16:50
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...
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.
Citation de: Gérard_M le Avril 18, 2016, 21:56:02
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.
?
Traitement paramétrique.
Peu importe l'original il ne sera pas modifié, les traitements sont enregistrés sous forme de métadonnées.
Citation de: Verso92 le Avril 18, 2016, 20:46:26
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.
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 !
Citation de: Samoreen le Avril 18, 2016, 23:24:01
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.
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...
Citation de: voxpopuli le Avril 17, 2016, 13:35:55
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.
Citation de: gigi4lm le Avril 19, 2016, 10:08:11
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.
Citation de: Bélisaire le Avril 19, 2016, 08:39:05
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.
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" ?
Citation de: tenmangu81 le Avril 19, 2016, 19:03:06
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.
Citation de: Verso92 le Avril 18, 2016, 20:46:26
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...
En fait LR ne sauvegarde pas le jpg mais les paramètres de réglage dans le catalogue (et dans une section xmp du jpg si l'option est activée) donc on peut ouvrir et modifier le jpeg à l'envie sans dégrader le fichier. Il y a qu'a l'export qu'un nouveau jpg pourra être généré en prenant en compte les réglages.
En photoshop, on peut faire pareil si on sauvegarde/travaille le fichier dans un autre format (PS/TIFF) mais pas si on sauvegarde/travaille l'image en jpg
Citation de: jipT le Avril 20, 2016, 11:31:17
En fait LR ne sauvegarde pas le jpg mais les paramètres de réglage dans le catalogue (et dans une section xmp du jpg si l'option est activée) donc on peut ouvrir et modifier le jpeg à l'envie sans dégrader le fichier. Il y a qu'a l'export qu'un nouveau jpg pourra être généré en prenant en compte les réglages.
En photoshop, on peut faire pareil si on sauvegarde/travaille le fichier dans un autre format (PS/TIFF) mais pas si on sauvegarde/travaille l'image en jpg
Bin si, il suffira d'enregistrer l'image avec un nom différent en jpg. ;D C'est d'ailleurs ce que je fais (je pars du RAF) car je considère qu'un produit final (image jpg) est lié au support sur lequel il sera vu et certains paramètres seront différents de la version originale (netteté, espace de couleurs, taille ...). J'ai donc plusieurs images jpg du même original selon sa destination
Et je me demande d'ailleurs si ça ne va pas plus vite dans photoshop en faisant comme ça ... (je me raccroche au thème du fil) :D
Après chacun fait comme y veut : RAW->PSD->JPG, JPG->JPG, RAW->JPG ... voire regénérer un jpg à partir RAW du boitier quand c'est possible ...
Le seul intérêt dans le cas de LR ou CS avec les filtres dynamiques est de pouvoir modifier les paramétrages des corrections réalisées.
Hélas certains confondent encore filtre dynamique et objets dynamique
https://helpx.adobe.com/fr/photoshop/using/create-smart-objects.html (https://helpx.adobe.com/fr/photoshop/using/create-smart-objects.html)
Tout comme employer le terme bitmap de photoshop :D
Citation de: asak le Avril 24, 2016, 14:24:46
Hélas certains confondent encore filtre dynamique et objets dynamique
Il y a peu de confusion possible puisque filtre dynamique implique objet (calque) dynamique. Tout filtre appliqué à un objet dynamique devient de facto un filtre dynamique (s'il supporte cette fonctionnalité) et tout filtre appliqué à un calque non dynamique transforme ce calque en objet dynamique par utilisation du menu "Convertir pour les filtres dynamiques", sinon ça ne sera jamais un filtre dynamique.
C'est donc une confusion de langage relativement admissible. Même si un objet dynamique n'implique pas nécessairement l'utilisation d'un filtre dynamique, dans le cadre de cette discussion particulière, les 2 concepts sont liés.
Quant à l'utilisation du terme bitmap à propos de Photoshop, je crois que la distinction entre bitmap en tant que type de représentation et bitmap en tant que format de fichier (.bmp) a été faite (message #33).
Citation de: Samoreen le Avril 24, 2016, 14:51:16
Quant à l'utilisation du terme bitmap à propos de Photoshop, je crois que la distinction entre bitmap en tant que type de représentation et bitmap en tant que format de fichier (.bmp) a été faite (message #33).
Juste une remarque en passant : ce terme
bitmap, dans le sens qui lui est donné aujourd'hui, m'a toujours surpris.
Dans les années 90, j'avais suivi des cours sur le traitement d'image (orienté reconnaissance automatique de forme, pas retouche photo), et le formateur avait insisté sur les deux types d'images existant :
bitmap et
vectoriel.
A l'époque, le terme
bitmap n'avait pas la connotation qu'on lui donne aujourd'hui (associé à une image développée)...
Citation de: Verso92 le Avril 24, 2016, 20:48:04
A l'époque, le terme bitmap n'avait pas la connotation qu'on lui donne aujourd'hui (associé à une image développée)...
C'est vrai encore maintenant non ? Un bitmap c'est juste une image constituée d'une matrice de points colorés. Enfin pour moi ;)
Ce n'est pas lié au fait que l'image soit développée, mais plutôt deux familles de formats bien distinct : l'image matricielle et/ou l'image vectorielle.
Après là ou personnellement j'ai plus du mal, c'est dire que photoshop est un logiciel bitmap, alors que l'on peut faire du vectoriel avec...
Mais en même temps, c'est la définition d'une image avec des pixels ;)
Ceci dit, il est rare, surtout sur un forum photo de parler d'image vectorielle...après certains utilisent souvent le terme bitmap pour définir une étape d'un processus aussi et c'est là ou ça porte à confusion.
grillé par le OuiOui :D
Citation de: OuiOuiPhoto le Avril 24, 2016, 22:09:51
C'est vrai encore maintenant non ? Un bitmap c'est juste une image constituée d'une matrice de points colorés. Enfin pour moi ;)
Colorés ou pas, là n'est pas la question.
Ce que je veux dire, c'est qu'à l'époque, une image
bitmap était définie comme une image de type "carte de points" (à l'opposé de
vectorielle).
Aujourd'hui, on considère que l'image
bitmap est une image "développée" (alors que celle contenue dans le fichier RAW est aussi
bitmap, par définition...).
Un peu le même genre de confusion, dans l'esprit, qui a fini par faire appeler le 24x36 "plein format"...
Image mode niveau de gris image mode bitmap c est une image BW
Citation de: Verso92 le Avril 24, 2016, 23:09:56
Colorés ou pas, là n'est pas la question.
Ce que je veux dire, c'est qu'à l'époque, une image bitmap était définie comme une image de type "carte de points" (à l'opposé de vectorielle).
Aujourd'hui, on considère que l'image bitmap est une image "développée" (alors que celle contenue dans le fichier RAW est aussi bitmap, par définition...).
Un peu le même genre de confusion, dans l'esprit, qui a fini par faire appeler le 24x36 "plein format"...
Oui à l'époque Illustrator était un logiciel de dessin de type vectoriel et photoshop de type bitmap. Bon maintenant tout est dans tout et inversement. A croire que c'était la même boite qui avait les 2 produits.
Citation de: Miaz3 le Avril 24, 2016, 22:20:29
Ce n'est pas lié au fait que l'image soit développée, mais plutôt deux familles de formats bien distinct : l'image matricielle et/ou l'image vectorielle.
Après là ou personnellement j'ai plus du mal, c'est dire que photoshop est un logiciel bitmap, alors que l'on peut faire du vectoriel avec...
Rappelons que dans la discussion qui a fait suite au post original de ce fil, il s'est agi de comparer ce qui se passe dans un logiciel comme Photoshop
pour les photos (
qui sont rarement enregistrées en vectoriel, si je ne me trompe - ou bien j'ai loupé une nouvelle génération d'APNs?) et un dématriceur où le type de représentation n'est pas une bitmap au sens générique habituel du terme.
[at] Samoreen :
Je n'ai jamais dit le contaire.
J'ai bien mentionné que :
CitationAprès là ou personnellement j'ai plus du mal, c'est dire que photoshop est un logiciel bitmap
C'est tout ;)
Comme Verso92 l'explique ça porte à confusion d'utiliser le mot "bitmap" à toutes les sauces.
CitationMais en même temps, c'est la définition d'une image avec des pixels
Mais ça et c'est sans aucun doute, du à l'expérience de chacun. En tout cas c'est quelque chose que je côtoie quotidiennement.
Je suis infographiste (à la base) mais je fait aussi du développement et quand je bosse avec d'autres infographistes je vais plus parler de "logiciel de retouche" que de logiciel bitmap.
Inversement, quand je fait du dev je parle plus de logiciel bitmap que de logiciel de retouche...
Ce qui, peut-être, prête aussi à confusion, est que l'image affichée par un dématriceur sur un écran ne peut être que bitmap, au sens où ce sont bien des pixels colorés qui sont affichés.
Citation de: tenmangu81 le Avril 25, 2016, 10:59:36
Ce qui, peut-être, prête aussi à confusion, est que l'image affichée par un dématriceur sur un écran ne peut être que bitmap, au sens où ce sont bien des pixels colorés qui sont affichés.
+1
Citation de: tenmangu81 le Avril 25, 2016, 10:59:36
Ce qui, peut-être, prête aussi à confusion, est que l'image affichée par un dématriceur sur un écran ne peut être que bitmap, au sens où ce sont bien des pixels colorés qui sont affichés.
Ne pas oublier qu'on parle de photoshop.
Mode Bitmap
Ce mode utilise une des deux valeurs chromatiques (noir ou blanc) pour représenter les pixels dans une image. Les images en mode Bitmap sont appelées images 1 bit en mode point, car leur profondeur est de 1.
Alors faux amis ???
Citation de: tenmangu81 le Avril 25, 2016, 10:59:36
Ce qui, peut-être, prête aussi à confusion, est que l'image affichée par un dématriceur sur un écran ne peut être que bitmap, au sens où ce sont bien des pixels colorés qui sont affichés.
C'est vrai aussi avec un logiciel traitant les images vectorielles. L'image affichée par Illustrator sur écran est elle aussi une image bitmap. Comment peut il en être autrement ?
Citation de: Verso92 le Avril 24, 2016, 20:48:04
Dans les années 90, j'avais suivi des cours sur le traitement d'image (orienté reconnaissance automatique de forme, pas retouche photo), et le formateur avait insisté sur les deux types d'images existant : bitmap et vectoriel.
A l'époque, le terme bitmap n'avait pas la connotation qu'on lui donne aujourd'hui (associé à une image développée)...
C'est parce qu'à cette époque, on côtoyait encore les 2 types de périphériques. Bitmaps (raster) et vectoriels. Le 1er ordinateur que j'ai utilisé en 1979 avait encore un écran à balayage cavalier (vectoriel).
Les polices de caractère qu'on utilise maintenant sont pratiquement toutes vectorielles, mais dans l'eprom du bios de ton pc, il y encore surement la forme bitmap de la table ascii.
On est donc passé de vectoriel , à bitmap, puis on est revenu à vectoriel en quelques décennies :)
Citation de: asak le Avril 25, 2016, 12:46:32
Ne pas oublier qu'on parle de photoshop.
Mode Bitmap
Ce mode utilise une des deux valeurs chromatiques (noir ou blanc) pour représenter les pixels dans une image. Les images en mode Bitmap sont appelées images 1 bit en mode point, car leur profondeur est de 1.
Alors faux amis ???
Citation de: gigi4lm le Avril 25, 2016, 12:47:09
C'est vrai aussi avec un logiciel traitant les images vectorielles. L'image affichée par Illustrator sur écran est elle aussi une image bitmap. Comment peut il en être autrement ?
Je faisais référence à la différence entre une "image" RAW et une image bitmap. Le fichier RAW est développé et affiché en bitmap sur l'écran, et chaque ajustement nécessite un nouveau calcul de l'image à afficher.
Citation de: tenmangu81 le Avril 25, 2016, 13:37:27
Je faisais référence à la différence entre une "image" RAW et une image bitmap.
Ce que je voulais dire, c'est que le RAW est aussi une image
bitmap, et que cette différenciation (ce changement de sens) est apparue somme toute récemment...
Citation de: Verso92 le Avril 25, 2016, 13:43:44
Ce que je voulais dire, c'est que le RAW est aussi une image bitmap, et que cette différenciation (ce changement de sens) est apparue somme toute récemment...
D'accord, bien sûr. Un RAW est aussi un bitmap dans la mesure où il s'agit d'une matrice dont les termes sont des valeurs physiques (nombre de photons mesurés). On parle bien d'ailleurs de "dématriceur" :) Bitmap veut dire textuellement une carte de bits.....
Citation de: Samoreen le Avril 17, 2016, 13:55:26
Non. Pas de doc Adobe....
Il me semble qu'il y a pourtant toutes les informations dans le dng sdk d'adobe pour esayer de voir la facon dont procède lightroom et le module raw de photoshop.
https://www.adobe.com/support/downloads/dng/dng_sdk.html
Si j'ai bien compris le process est le suivant :
1- Dematricage, linéarisation et black substraction.
2- passage dans l'espace CIE XYZ en prenant en compte la balance des blancs choisie.
3- correction des couleurs (propre à l'appareil par le profile).
4- passage dans l'espace RIMM RGB.
A mon avis, seul un changement de balance des blanc va obliger lightroom à repartir du presque début. Toutes les autres opérations se font après l'étape 4, mais ca ne reste que mon avis...
Citation de: frmfrm le Avril 25, 2016, 15:05:35
Il me semble qu'il y a pourtant toutes les informations dans le dng sdk d'adobe pour essayer de voir la façon dont procède Lightroom et le module raw de photoshop.
Bonjour,
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.
À moins que je loupe quelque chose d'essentiel...
Citation de: Samoreen le Avril 25, 2016, 15:41:54
À moins que je loupe quelque chose d'essentiel...
Oui , télécharger le sdk et le lire ;)
Citation de: frmfrm le Avril 25, 2016, 15:05:35
A mon avis, seul un changement de balance des blanc va obliger lightroom à repartir du presque début. Toutes les autres opérations se font après l'étape 4, mais ça ne reste que mon avis...
Tant qu'Adobe ne viendra pas nous voir, nous en resterons aux suppositions. Cependant...
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.
Citation de: Samoreen le Avril 25, 2016, 15:57:01
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
Citation de: frmfrm le Avril 25, 2016, 16:34:54
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.
Citation de: Samoreen le Avril 25, 2016, 16:55:09
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.
Citation de: Samoreen le Avril 25, 2016, 17:01:06
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+
Citation de: frmfrm le Avril 25, 2016, 17:44:52
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... ::)
Citation de: frmfrm le Avril 25, 2016, 17:44:52
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.
Citation de: Samoreen le Avril 25, 2016, 17:01:06
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.
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:
Citation de: Samoreen le Avril 25, 2016, 15:41:54
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.
Citation de: frmfrm le Avril 26, 2016, 00:59:48
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.
Citation de: tenmangu81 le Avril 26, 2016, 10:06:19
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 :) .
Citation de: Samoreen le Avril 26, 2016, 10:20:54
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.
Citation de: frmfrm le Avril 26, 2016, 12:32:14
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?
Citation de: Samoreen le Avril 26, 2016, 14:09:02
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.
Je rends les armes.
Citation de: frmfrm le Avril 26, 2016, 12:32:14
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).