D800E / C1 Linear - Profil(s) ICC pour Capture One

[Miaz3]

Je pensais pour la lecture. Alors c'est plus dédié à la vidéo, mais vous allez comprendre pas mal de choses.
Les secrets de l'image vidéo de Philippe Bellaïche.
Livre destiné aux étudiants bts dans l'audiovisuel. Il en est à sa 10eme éditions, perso je l'ai toujours sous le coude.

Certains passage sont velu, ceci dit vous pouvez le picorer aussi, hein

Edit : de se que j'ai sous le coude, le reste sont que des livres Anglophone.

[matopho]

Bonsoir,

.....
Edit : de se que j'ai sous le coude, le reste sont que des livres Anglophone.

Je lis couramment l'anglais, alors je suis intéressé.

Que pensez-vous de :

Color Management & Quality Output: Working with Color from Camera to Display to Print

Colour Reproduction in Electronic Imaging Systems: Photography, Television, Cinematography.

Ce sont les deux plus récents que j'ai trouvé.

Merci

[Verso92]

Je pense qu'il faut plus voir le FF comme un terme, devenu un standard dans le milieu dans la photographie contemporaine. Faut dire qu'aujourd'hui avec le "tout numérique"...
On pourrait dire "format 35mm" aussi (à ne pas confondre avec le "35mm film") couramment utilisé dans le milieu de la vidéo.

Concernant le "bitmap", ça dépend ou l'on se place
Disons que pour un artiste, graphiste une bitmap est compris comme un format d'image (.bmp/.pbm voir ppm).
Alors qu'un développeur lui y voit une image matricielle.
Bref, un type qui te parle de "bitmap" ou lieu de "photo développée",  tu sait d'où il viens

Full Frame, je sais d'où ça vient : quand sont apparus les APN (24x36) dont le capteur exploitait le cercle image des objectifs. Aujourd'hui, ce terme est vide de sens, la plupart du temps.

Bitmap, c'est pour moi une image matricielle (par opposition à vectorielle), comme tu le dis. Je n'ai jamais compris pourquoi ce terme est associé aujourd'hui à une image développée...

[Miaz3]

 [at] matopho :
Je ne connaissais pas, merci. J'en ai 2-3 mais il sont axés vidéos :
Digital Cinematography: Fundamentals, Tools, Techniques, and Workflows
The HDRI Handbook
Digital Compositing for Film and Video

[at] Verso92 :
Perso, la première fois que j'ai vu l'association bitmap > image développée c'est ici.
Dans mon métier, j'ai le cul entre les deux chaises (compositing et developpement) et il n'y a que les dev qui parle de bitmap...et encore le terme bitmap reste générique.
ça peux être un raw, une sortie de moteur de calcul, un master, des stills,  ect... bref une image quoi.

[Verso92]

[at] Verso92 :
Perso, la première fois que j'ai vu l'association bitmap > image développée c'est ici.
Dans mon métier, j'ai le cul entre les deux chaises (compositing et developpement) et il n'y a que les dev qui parle de bitmap...et encore le terme bitmap reste générique.
ça peux être un raw, une sortie de moteur de calcul, un master, des stills,  ect... bref une image quoi.

Oui, ce vocabulaire est assez étonnant...

Dans le domaine du traitement d'image (comprendre reconnaissance automatique de formes, tracking...), ce n'est pas le cas.

[Miaz3]

Tout dépend ou l'on se place, pour un dev, programmeur c'est (et restera) une image matricielle.
Prenons l'exemple du tracking.
L'utilisateur (graphiste ou non) qui fait du tracking, pour lui c'est faire du tracking sur une séquences d'image.
Alors que pour le développeur qui a codé une partie de ce moteur, pour lui et dans son jargon (car il faut être précis), le moteur de tracking analyse une image matricielle.

bref,

[tipo29]

Merci à tous pour les références littéraires.

Le truc de bien avec un profil perso et une exposition bien calée avec un Expodisc mais adaptée à une réponse linéaire sous Capture One, c'est qu'il n'y a plus besoin de toucher aux réglages d'Exposition/Contraste/Luminosité/Saturation/HDR(Hautes lumières/Ombres), les Niveaux et l'Editeur de couleurs, ce qui nous donne tout le temps et la liberté de jouer avec la balance des couleurs et la courbe luma.

C'est cool.

[paul.AU]

Peut-être parce que vos valeurs ne sont pas linéaires à la vision.
Linéaires c'est L 1,2, 3,4,5... 100 en L*a*b*. Lab étant construit sur les travaux de munsel, travaux empiriques.
Gamma 1ou gamma linéaire c'est encore autre chose. Vous mélangez tout.

Pour apporter une (grosse) correction à ce point, je me suis emmelé les pinceaux.

Le fichier brut du capteur est linéaire -> c'est gamma1.
La correction gamma se fait par le type de réponse choisi en amont du profil (avec le profil icc approprié pour C1 uniquement -repro art pour bicc input-). Si le profil est linéaire, ->L*, l'étagement de vos valeurs tonales est parfaite et conforme au LAB.
Ici vous le voyez à l'écran dans C1 ou ACR, et enfin vous indiquez l'espace de sortie qui vous convient.
En choisissant un espace de sortie, vous choisissez donc un profil RVB (avec son propre gamma -qd je dis gamma ca peut etre aussi une courbe srgb ou L*, pour etre encore plus précis).
Avec les espaces "traditionnels", cette opération encode en RVB non linéairement (et l'écran décode à l'envers les infos rvb).
Encoder les infos selon l'étagement de la vision et non plus celui des données brutes mathématiques du capteur permet de donner plus d'infos d'encodage dans les basses lumières, que nous différencions bien, donc pour qu'il n'y ait pas de saute de valeurs, ou postérisation)
Donc du coup, c'est pour ca que votre rampe de gris en rvb n'est pas linéaire. (à moins de lui assigner un profil en gamma1 (vous suivez toujours ?)
De plus, avec ces espaces de travail traditionnels qui sont donc gamma encodés (1,8/2,2/srgb/L*), c'est bien plus aisé de travailler sous ces espaces pour l'utilisateur (bon histogramme, parfait pour L*), même si les corrections seraient plus "justes" dans un espace gamma1, notamment pour la bdb par exemple. (mais à priori vous l'avez déjà faites avant de passer en rvb).

[Verso92]

Le fichier brut du capteur est linéaire -> c'est gamma1.

Ouf... un point que j'ai compris (et avec lequel je suis d'accord...) !

;-)

Encoder les infos selon l'étagement de la vision et non plus celui des données brutes mathématiques du capteur permet de donner plus d'infos d'encodage dans les basses lumières, que nous différencions bien, donc pour qu'il n'y ait pas de saute de valeurs, ou postérisation)

C'est là que j'ai plus de mal...

L'encodage "inverse" n'est-il pas là pour compenser la non linéarité de l'écran, tout simplement ?

On voit bien que doubler le niveau d'entrée du signal de l'écran ne double pas le niveau de luminance émis...

[paul.AU]

Pleins d'infos là :
http://www.photo-lovers.org/color.shtml.fr

[tipo29]

Merci paul.AU pour le lien, mais ça me dépasse un peu