Page FB inaccessible

[Tonton-Bruno]

J'ai posé la question à ChatGPT qui m'a conseillé d'utiliser  diagrams.net.
Je viens d'essayer. C'est simple et efficace. je vais l'utiliser tout de suite.

[Tonton-Bruno]

Voila le schéma que je propose.

[seba]

Tu pars d'un fichier JPG mais c'est valable pour n'importe quel type de fichier.

[Tonton-Bruno]

Oui, c'est valable pour tout type de fichier. Je voulais dire qu'en cas de fichier JPG, le raccourci qui consiste à dire "vous voyez le fichier JPG" me paraît acceptable.

Ce que je reprocherais à Nat, c'est de ne pas insister sur le fait que la chose la plus importante, c'est l'étape de développement qui doit se faire dans un espace couleur aussi grand que possible, sur 16 ou 32 bits.

C'est la même chose en vidéo. que l'on tourne en H265 8 bits, H265 10 bits, H265 10 bits Log, RAW 12 bits ou RAW 12 bits Log, ce qui est important, c'est de faire l'étalonnage couleur dans un espace couleur 16 bits, tout en contrôlant son travail sur l'écran le plus faible (REC.709 8 bits) parce que quoi qu'on fasse, ce sera celui le plus souvent utilisé.

[seba]

Oui, c'est valable pour tout type de fichier. Je voulais dire qu'en cas de fichier JPG, le raccourci qui consiste à dire "vous voyez le fichier JPG" me paraît acceptable.

Si elle disait ça...
Mais elle dit que quel que soit le type de fichier, c'est un jpg qui est affiché à l'écran.

[Tonton-Bruno]

C'est parce qu'elle a en tête l'application d'un profil linéaire au fichier RAW, au lieu de la courbe gamma 2.2 et c'est là que sa simplification devient abusive.

[Verso92]

Si elle disait ça...
Mais elle dit que quel que soit le type de fichier, c'est un jpg qui est affiché à l'écran.

De toute façon, elle mélange tout (c'est un sacré bordel dans sa tête !).

Pour un forumeur lambda, pas (trop) grave... pour un formateur professionnel, c'est plus gênant !

[frmfrm]

C'est parce qu'elle a en tête l'application d'un profil linéaire au fichier RAW, au lieu de la courbe gamma 2.2 et c'est là que sa simplification devient abusive.

Juste en passant rapidement car j'ai plusieurs fers au feu

Je ne sais pas ce qu'elle dit ... ni toi non plus , mais :

Un profil dcp ou autre linéaire de C1 n'est pas purement linéaire car c'est compliqué de travailler dans un gamma 1.0 avec des outils pas adaptés.

Un profil dcp linéaire est linéaire perceptuellement cad qu'il n'a pas de courbe en S, mais certains outils ( et la représentation de l'histo ) travaillent bien dans un gamma proche de 2.2

[Pierock]

Juste en passant rapidement car j'ai plusieurs fers au feu

Je ne sais pas ce qu'elle dit ... ni toi non plus , mais :

Un profil dcp ou autre linéaire de C1 n'est pas purement linéaire car c'est compliqué de travailler dans un gamma 1.0 avec des outils pas adaptés.

Un profil dcp linéaire est linéaire perceptuellement cad qu'il n'a pas de courbe en S, mais certains outils ( et la représentation de l'histo ) travaillent bien dans un gamma proche de 2.2

Tu es projectionniste ?

[frmfrm]

Tu es projectionniste ?

Non, j'suis retraité depuis le début de l'année ...

Tu peux pas savoir tout ce que j'ai en liste d'attente depuis des années

[Pierock]

Non, j'suis retraité depuis le début de l'année ...

Tu peux pas savoir tout ce que j'ai en liste d'attente depuis des années

C'est sûr que je ne peux pas connaitre ton agenda, néanmoin cela fait 3/4 interventions que je lis de ta part qui fait référence à diffusion/projection.

[jenga]

Oui, c'est valable pour tout type de fichier. Je voulais dire qu'en cas de fichier JPG, le raccourci qui consiste à dire "vous voyez le fichier JPG" me paraît acceptable.

Le schéma en #2253 laisser penser que le jpg dépend du profil de l'écran de l'ordi utilisé pour le développement. Ce n'est pas le cas, le fichier ne dépend que du fichier d'entrée et des modifications effectuées, pas du dispositif de visualisation.

Ensuite, je ne suis pas sûr que la "compression JPG" soit nécessairement précédée d'une "conversion sRGB 8bits". La compression débute par une transformation de l'espace d'entrée en YCbCr (permettant un meilleur compromis qualité visuelle / compression), mais la norme n'impose pas l'espace d'entrée (profondeur de codage et courbe de tonalités).

On peut très bien, par exemple, (je le fais souvent) exporter un jpg embarquant un profil linéaire.

[Pierock]

Le schéma en #2253 laisser penser que le jpg dépend du profil de l'écran de l'ordi utilisé pour le développement. Ce n'est pas le cas, le fichier ne dépend que du fichier d'entrée et des modifications effectuées, pas du dispositif de visualisation.

Ensuite, je ne suis pas sûr que la "compression JPG" soit nécessairement précédée d'une "conversion sRGB 8bits". La compression débute par une transformation de l'espace d'entrée en YCbCr (permettant un meilleur compromis qualité visuelle / compression), mais la norme n'impose pas l'espace d'entrée (profondeur de codage et courbe de tonalités).

On peut très bien, par exemple, (je le fais souvent) exporter un jpg embarquant un profil linéaire.

Oui comme le propos critiqué de Nath Sakura, les propos photos et vidéos avec et sur le schéma sont simplifiés à outrance.

[Tonton-Bruno]

On peut très bien, par exemple, (je le fais souvent) exporter un jpg embarquant un profil linéaire.

Tu peux préciser ?
Je ne suis pas certain de comprendre ce que tu veux dire lorsque tu parles de profil linéaire.

Pour le premier point d'interrogation, c'est en effet une erreur. La flèche devrait partir de l'engrenage, et pas de la sortie écran.

Pour le second point d'interrogation, je suppose que tu veux dire qu'on n'est pas obligé de convertir dans l'espace sRGB, ce qui est exact, mais dans ce cas , on perd la compatibilité universelle.

EDI j'ai modifié mon schéma

[frmfrm]

On peut très bien, par exemple, (je le fais souvent) exporter un jpg embarquant un profil linéaire.

On peut le faire, mais je crois que ce n'est pas forcement recommandé

Je crois avoir lu que l'on a utilisé/choisi une OETF (opto-electronic transfer function) non linéaire pour uniformiser l'effet du bruit à différents niveaux de luminosité. ( Et pas parce que la réponse d'un écran CRT est non linéaire comme le mentionne NS ).

J'ai aussi lu que l'OETF a été choisie initialement pour s'approcher de la perception humaine non linéaire.

Enfin, je crois que le choix d'un encodage 8 bits non linéaire est à peu près valable pour un périphérique avec un contraste d'environ 100:1 ( CRT ou impression papier). Sur certains écrans c'est un peu limite et on doit ajouter du bruit dans les dégradés pour éviter d'avoir du banding.

[Pierock]

On peut le faire, mais je crois que ce n'est pas forcement recommandé

Je crois avoir lu que l'on a utilisé/choisi une OETF (opto-electronic transfer function) non linéaire pour uniformiser l'effet du bruit à différents niveaux de luminosité. ( Et pas parce que la réponse d'un écran CRT est non linéaire comme le mentionne NS ).

J'ai aussi lu que l'OETF a été choisie initialement pour s'approcher de la perception humaine non linéaire.

Enfin, je crois que le choix d'un encodage 8 bits non linéaire est à peu près valable pour un périphérique avec un contraste d'environ 100:1 ( CRT ou impression papier). Sur certains écrans c'est un peu limite et on doit ajouter du bruit dans les dégradés pour éviter d'avoir du banding.

C'est pourquoi tout ne s'applique pas en photo et en vidéo. Je ne vais pas m'apesentir sur la gestion des espaces de couleurs ecran/impression, qui sont maitrisés par la plupart des photographes avancés.
 
Et en vidéo, le REC709 a été définit à l'époque des écrans cathodique et des processeurs 8 bits.

Donc 50 ans plus tard, en Vidéo on parle de PQ (Perceptual Quantizer) pour l'OETF qui nous ramène avec les nouvelles normes à une compatibilité REC 709 mais nous permet de bénéficier des nouvelles technologies (HLG (Hybrid Log Gamma, norme ITU-R BT.2100).
Et en vidéo on est en gamma 2.4.

[bruno-v]

Tu pars d'un fichier JPG mais c'est valable pour n'importe quel type de fichier.

Oui, rajouter une étape décompression/décodage permet d'introduire le fait que cette étape introduit des erreurs et des corrections.
Même un traitement sans perte introduit des approximations, de même que le choix du type de rendu, il y en plusieurs -> ils génèrent des parfois des différences parfois visibles (selon le sujet)
a+

[jenga]

Cette partie de mon message:

On peut très bien, par exemple, (je le fais souvent) exporter un jpg embarquant un profil linéaire.

a provoqué à juste titre vos réponses:

On peut le faire, mais je crois que ce n'est pas forcement recommandé

Tu peux préciser ?
Je ne suis pas certain de comprendre ce que tu veux dire lorsque tu parles de profil linéaire.

(...) je suppose que tu veux dire qu'on n'est pas obligé de convertir dans l'espace sRGB, ce qui est exact, mais dans ce cas , on perd la compatibilité universelle.

En fait, je le fais souvent... par erreur.

J'édite mes photos en espace de travail linéaire 32 bits flottants parce que:

• Gimp (je ne sais pas pour PS) fait tous ses traitements en interne dans ce mode, quel que soit l'espace de travail; si l'espace de travail est différent cela nécessite des conversions internes aller et retour à chaque opération, ce qui ralentit le travail.
  La motivation pour cela est que tout mode non linéaire produit des erreurs ("erreur de gamma") dès qu'on fait des additions/multiplications (tampons, filtres, modes de calques, modifications géométriques, etc.).
  
• le codage en flottant donne davantage de représentation aux faibles valeurs: il y a autant de nombres flottants entre 0,1 et 0,2 qu'entre 0,2 et 0,4, entre 10 et 20, entre 20 et 40, entre 100 et 200, etc. (environ 8 millions de valeurs dans chacun de ces intervalles), ce qui tombe très bien.
  En effet, comme le dit frmfrm, il est utile d'adopter un codage donnant davantage de représentation aux faibles valeurs, pour mieux gérer le bruit et s'adapter à la sensibilité de la vision humaine: le codage en flottant est donc parfait pour cela, il n'y a pas d'intérêt de ce point de vue à avoir en plus un espace de travail non linéaire.
  
• en 32 bits flottant, on peut faire des dizaines d'opérations sans ajouter de bruit de discrétisation, ce qui n'est pas le cas en 8 ou même 16 bits. Les processeurs étant optimisés pour le flottant, c'est même plus rapide sur ma machine (qui n'a rien d'une bête de course).
  

Bien sûr, le profil de l'espace de travail correspondant au codage utilisé (linéaire), l'image est vue avec les bonnes tonalités et couleurs pendant l'édition, la gestion couleurs étant là pour ça.

Et donc, quand j'exporte bille en tête en jpg, je me retrouve avec un jpg à profil linéaire, ce qui n'est bien sûr pas recommandé pour le codage en entiers 8 bits du jpg, puisqu'alors les faibles intensités ne bénéficient pas d'une sur-représentation.

A première vue, le fait d'avoir un jpg linéaire ne change rien à l'affichage puisque le profil embarqué dans le fichier correspond bien au contenu; en général, je me rends compte de l'erreur avec certains logiciels qui affichent les vignettes sans gérer la couleur, celles des fichiers en jpg linéaire paraissant alors très sombres.

C'est un exemple de la perte de compatibilité universelle dont tu parles, TTB: dès qu'un jpg n'est pas en profil sRGB, il est mal affiché par les logiciels qui ne gèrent pas la couleur.