Forum Chasseur d'Images - www.chassimages.com

Bonsoir.
J'aimerais savoir si un fichier au format tif (16 bits) présente la même latitude de retouche qu'un fichier au format raw (12 ou 14 bits), que celui-ci soit du Dng, de l'Arw, du Cr2, etc.
Par exemple: une image, réduite en Jpg, présente une dynamique moins étendue que cette même image au format Raw. Cette même image, convertie en Tif, offre-t-elle la même plage dynamique qu'en Raw ?
(Laissons de côté le fait que les fichiers au format Tif sont volumineux).
Merci.

Citation de: Bélisaire le Avril 03, 2016, 21:42:34
J'aimerais savoir si un fichier au format tif (16 bits) présente la même latitude de retouche qu'un fichier au format raw (12 ou 14 bits), que celui-ci soit du Dng, de l'Arw, du Cr2, etc.

Non.
Un fichier TIFF est une image finalisée, développée.

Un fichier RAW contient les données "brutes", et doit être développé.

Citation de: Bélisaire le Avril 03, 2016, 21:42:34
Par exemple: une image, réduite en Jpg, présente une dynamique moins étendue que cette même image au format Raw. Cette même image, convertie en Tif, offre-t-elle la même plage dynamique qu'en Raw ?

L'image Jpeg ne gagnera strictement rien à être convertie en TIFF, même 16 bits. Ou, du moins, la casse sera peut-être amoindrie lors de certains traitements.
Anecdotique.

Oui. Mais prenons un fichier Raw, qui présente, par exemple, des contrastes prononcés. Je le convertis en tif. Aurais-je sur ces deux images la même latitude de post-traitement ?

Je n'ai pas été clair avec l'exemple du jpg. Mon intention n'est pas de convertir du jpg en tif. Je faisais simplement le constat que le jpg a une marge de manoeuvre moins importante en post-traitement.

Citation de: Bélisaire le Avril 03, 2016, 21:59:21
Oui. Mais prenons un fichier Raw, qui présente, par exemple, des contrastes prononcés. Je le convertis en tif. Aurais-je sur ces deux images la même latitude de post-traitement ?

Non.

Merci.

Citation de: Bélisaire le Avril 03, 2016, 21:59:21
Oui. Mais prenons un fichier Raw, qui présente, par exemple, des contrastes prononcés. Je le convertis en tif. Aurais-je sur ces deux images la même latitude de post-traitement ?

Citation de: Verso92 le Avril 03, 2016, 23:23:30
Non.

Je ne vois pas pourquoi le fichier tiff aurait une dynamique moindre que celle du raw avec un codage sur 16 bits ???

A mon avis, la conversion raw (14 bit) -> tiff (16 bit), tout comme la conversion raw -> dng (16 bit) ne doit pas entraîner de dégradation.

Mais je suis prêt à me voir démontrer le contraire si l'argumentation est étayée ! ;D

Ce qu'il faut comprendre, c'est qu'une image RAW contient des données "brutes" de la PdV, à savoir une valeur de luminance pour chaque pixel, associée à son filtrage couleur (rouge, vert ou bleu).
Un certain nombre d'opérations (BdB, saturation, contraste, luminosité, etc) seront calculées sur ces valeurs "brutes" associée à la matrice (Bayer, souvent). L'image sera donc construite "en une fois", si j'ose dire, sans dégradations successives.

L'image en TIFF est déjà développée ("construite", figée, alors que le RAW est une image en devenir). Chaque opération (saturation, contraste, luminosité, etc) sera appliquée à l'image successivement, générant à chaque fois des dégradations, à l'inverse du RAW.
Tout traitement numérique amène son lot de dégradations sur l'image (c'est d'ailleurs pour ça qu'on travaille en 16 bits, pour limiter la casse). En simplifiant un peu, le RAW ne subit qu'une dégradation lors de son développement (sauf pour les traitements purement bitmap), alors que le TIFF en subit une à chaque opération (qui ne peut être que bitmap).

Citation de: jaric le Avril 03, 2016, 23:50:04
Je ne vois pas pourquoi le fichier tiff aurait une dynamique moindre que celle du raw avec un codage sur 16 bits ???

Je ne parlais pas, en l'occurrence, de dynamique...

Citation de: jaric le Avril 03, 2016, 23:50:04
A mon avis, la conversion raw (14 bit) -> tiff (16 bit), tout comme la conversion raw -> dng (16 bit) ne doit pas entraîner de dégradation.

La conversion RAW --> TIFF entraine bien évidemment des dégradations, par principe, mais elle est difficilement quantifiable, le RAW n'étant pas une image finalisée.
RAW --> DNG, c'est juste un transcodage du RAW dans un autre format de fichier, rien de plus.

Citation de: Verso92 le Avril 04, 2016, 00:01:06
Je ne parlais pas, en l'occurrence, de dynamique...

Alors, je n'ai pas compris à quoi correspondait ton 'non'.

Citation de: jaric le Avril 04, 2016, 00:02:54
Alors, je n'ai pas compris à quoi correspondait ton 'non'.

C'était en réponse à la question ci-dessous :

Citation de: Bélisaire le Avril 03, 2016, 21:59:21
Aurais-je sur ces deux images la même latitude de post-traitement ?

Citation de: Verso92 le Avril 04, 2016, 00:04:24
C'était en réponse à la question ci-dessous :

Alors j'avais bien compris, la latitude de post traitement est le reflet direct de la dynamique du fichier, ou, dit autrement, du nombre de ses niveaux de quantification.
PS : bien entendu, le passage du raw 14 bit au tiff 16 bit n'apporte rien, il n'y a pas d'ajout d'information (les deux LSB sont mis à zéro en général).

Pas exactement. Le niveau de quantification est la précision que tu donnes a la mesure du signal. Mais si le signal a été dégradé, il restera dégradé quel que soit le niveau de quantification avec lequel du analyse cette dégradation.

J'ai un temps pensé que le RAW et le TIF 16 bit avaient le meme niveau d'information, mais il est vrai qu'il y a des cas ou le passage de l'un a l'autre efface des information utiles.

Citation de: jaric le Avril 04, 2016, 00:08:37
Alors j'avais bien compris, la latitude de post traitement est le reflet direct de la dynamique du fichier, ou, dit autrement, du nombre de ses niveaux de quantification.

Pour prendre un exemple concret de latitude de P/T sans rapport direct avec la dynamique : la BdB.
Une image RAW prise avec une BdB inadéquate pourra être corrigée en un clic de souris en une image à la colorimétrie parfaite, pour peu que l'illuminant soit constant sur toute l'image. Ce ne sera pas le cas, bien sûr, avec un TIFF, même 16 bits...

Désolé, mais je ne vois pas pourquoi la BdB se corrigerait moins facilement en tiff.

Un exemple : lorsque je scanne mes films (positifs ou négatifs), je les sors du scanner en tiff et passe par ACR pour les corrections exactement comme je fais avec mes NEF, et avec la même efficacité (enfin presque, je n'ai pas 14 bits significatifs, mais cela n'a pas vraiment d'importance quand l'original est argentique).

Citation de: jaric le Avril 04, 2016, 00:19:01
Désolé, mais je ne vois pas pourquoi la BdB se corrigerait moins facilement en tiff.

Si tu ne vois pas, je ne peux plus grand chose pour toi, désolé...
(et puis, c'est l'heure d'aller me coucher : école demain !)

Citation de: Franciscus Corvinus le Avril 04, 2016, 00:13:37
J'ai un temps pensé que le RAW et le TIF 16 bit avaient le meme niveau d'information, mais il est vrai qu'il y a des cas ou le passage de l'un a l'autre efface des information utiles.

Pas si tu conserves le même nombre de bits (a fortiori si tu passes de 14 à 16).

Citation de: Verso92 le Avril 04, 2016, 00:22:16
Si tu ne vois pas, je ne peux plus grand chose pour toi, désolé...

Pour rester dans le déni  ;D, tu n'as pas dû traiter de tiff dans Camera Raw ou Lightroom.

Citation de: jaric le Avril 04, 2016, 00:24:27
Pour rester dans le déni  ;D, tu n'as pas dû traîter de tiff dans Camera Raw ou Lightroom.

Devant tant de contre-sens accumulés en si peu de temps, je vais me coucher... bonne nuit !

Citation de: Verso92 le Avril 04, 2016, 00:25:30
Devant tant de contre-sens accumulés en si peu de temps, je vais me coucher... bonne nuit !

Ah ah, tu abandonnes lâchement !  ::)

Bonne nuit tout de même !  ;)

Citation de: Verso92 le Avril 03, 2016, 23:54:36
Ce qu'il faut comprendre, c'est qu'une image RAW contient des données "brutes" de la PdV, à savoir une valeur de luminance pour chaque pixel, associée à son filtrage couleur (rouge, vert ou bleu).

Un certain nombre d'opérations (BdB, saturation, contraste, luminosité, etc) seront calculées sur ces valeurs "brutes" associée à la matrice (Bayer, souvent). L'image sera donc construite "en une fois", si j'ose dire, sans dégradations successives.

L'image en TIFF est déjà développée ("construite", figée, alors que le RAW est une image en devenir). Chaque opération (saturation, contraste, luminosité, etc) sera appliquée à l'image successivement, générant à chaque fois des dégradations, à l'inverse du RAW.

Tout traitement numérique amène son lot de dégradations sur l'image (c'est d'ailleurs pour ça qu'on travaille en 16 bits, pour limiter la casse). En simplifiant un peu, le RAW ne subit qu'une dégradation lors de son développement (sauf pour les traitements purement bitmap), alors que le TIFF en subit une à chaque opération (qui ne peut être que bitmap).

Tu te trompes la dessus. On peut traiter un tiff 16 bits, et meme un JPEG 8 bits de facon non destructrive en appliquant toutes les operations simultanement. Rawtherapee fait ca par exemple, le traitements se fait sur 96bits.

Je ne sais pas precisement ce qu'on perd en traitant un tiff 16 bits plutot qu'un RAW. Ca depend surtout du developpement RAW->tiff prealable bien sur, mais en appliquant un profil "neutre", je dirais que la difference est pas enorme.

Citation de: spinup le Avril 04, 2016, 00:56:16
Tu te trompes la dessus. On peut traiter un tiff 16 bits, et meme un JPEG 8 bits de facon non destructrive en appliquant toutes les operations simultanement. Rawtherapee fait ca par exemple, le traitements se fait sur 96bits.

Je ne connaissais pas cette possibilité (je parlais de traitement bitmap "standard", genre Photoshop).

Citation de: spinup le Avril 04, 2016, 00:56:16
Je ne sais pas precisement ce qu'on perd en traitant un tiff 16 bits plutot qu'un RAW. Ca depend surtout du developpement RAW->tiff prealable bien sur, mais en appliquant un profil "neutre", je dirais que la difference est pas enorme.

Il n'est pas question d'affirmer que la différence est énorme. Juste que la faiblesse des APN "Bayer" étant le dématriçage (voir la différence avec le Foveon pour s'en rendre compte), toute opération faite avant le dématriçage plutôt qu'après ne peut être que bénéfique...

Citation de: Verso92 le Avril 04, 2016, 08:31:33
Je ne connaissais pas cette possibilité (je parlais de traitement bitmap "standard", genre Photoshop).

Le principe du traitement par calques est d'eviter ca non?
Il me semble que l'approche "bitmap" traité avec operations successives n'est pas la facon dont on est censé utiliser photoshop.

Citation de: jaric le Avril 04, 2016, 00:19:01Désolé, mais je ne vois pas pourquoi la BdB se corrigerait moins facilement en tiff.

Alors fais cette expérience. Règle l'enregistrement des photos dans ton boîtier en RAW + JPG. Prends diverses photos en balance des blanc erronée (notamment, tungstène en extérieur sous un beau soleil et lumière du jour en intérieur sous lampes halogène ou tungstène). Fais les corrections BdB sur le RAW et sur le JPG et tu verras la différence. ;)

Citation de: Nerva le Avril 04, 2016, 11:31:13
Alors fais cette expérience. Règle l'enregistrement des photos dans ton boîtier en RAW + JPG. Prends diverses photos en balance des blanc erronée (notamment, tungstène en extérieur sous un beau soleil et lumière du jour en intérieur sous lampes halogène ou tungstène). Fais les corrections BdB sur le RAW et sur le JPG et tu verras la différence. ;)

Je n'ai jamais parlé du jpeg, mais du tiff !
Le jpeg est limité à 8 bits/couche, soit 256 niveaux, ce qui est très insuffisant pour effectuer un traitement propre de l'image. La conversion en jpeg ne doit être réalisée qu'à la toute fin du processus, pour l'archivage de l'image.

Pour Verso, je ne pense pas que le traitement avant ou après dématriçage change quoi que ce soit lorsque tous les calculs internes de tous les logiciels actuels s'effectue sur 64 bits (spinup parle de 96 bits, mais ça ne doit pas être fréquent non plus...) et que bien sûr, on ne dégrade pas l'image en tronquant son nombre de bits au cours du processus.

Et si différence il y a, je suis preneur d'un dossier comparatif mettant en évidence cet effet !

Que ce soit le JPG ou le TIF ça ne fait pas grande différence. Comme certains te l'ont déjà expliqué, ces images sont finies et le réglage de BdB est "incrusté" en elles, contrairement au RAW. C'est bien entendu corrigeable mais ça fait des dégâts lorsque la colorimétrie est très décalée, chose inexistante en RAW.

Citation de: spinup le Avril 04, 2016, 00:56:16
Je ne sais pas precisement ce qu'on perd en traitant un tiff 16 bits plutot qu'un RAW. Ca depend surtout du developpement RAW->tiff prealable bien sur, mais en appliquant un profil "neutre", je dirais que la difference est pas enorme.

Idéalement, il faudrait un profil totalement linéaire, et surtout un point noir égal à celui du raw (est-ce le cas dans les logiciels ?)

Pour la BdB, il me semble que c'est plus difficile en tiff d'avoir un rendu naturel car la courbe tonale a été appliquée, et encore plus si le profil colorimétrique de dématriçage est pointu (cad pas juste une matrice linéaire).
Mais bon, si le but est juste de régler "à l'oeil" et qu'on maîtrise très bien son outil de retouche, ça marche peut-être aussi ?

Citation de: Nerva le Avril 04, 2016, 11:58:15
Que ce soit le JPG ou le TIF ça ne fait pas grande différence. Comme certains te l'ont déjà expliqué, ces images sont finies et le réglage de BdB est "incrusté" en elles, contrairement au RAW. C'est bien entendu corrigeable mais ça fait des dégâts lorsque la colorimétrie est très décalée, chose inexistante en RAW.

Ton intervention me rassure : je commençais à croire que j'avais rêvé...  ;-)

Citation de: Nerva le Avril 04, 2016, 11:58:15
Que ce soit le JPG ou le TIF ça ne fait pas grande différence. Comme certains te l'ont déjà expliqué, ces images sont finies et le réglage de BdB est "incrusté" en elles, contrairement au RAW. C'est bien entendu corrigeable mais ça fait des dégâts lorsque la colorimétrie est très décalée, chose inexistante en RAW.

Ce sont des affirmations sans fondement à mon avis. J'aimerais vraiment qu'on m'explique en quoi appliquer un réglage sur le tiff diffère de celui du RAW.
Parce que pour moi, traiter avant ou après dématriçage ne fait guère de différence si on n'apporte pas de 'bruit' de calcul. Et qu'on ne m'avance pas des termes comme BdB "incrustée" dans le tiff vs le raw, car ça n'a aucun fondement techniquement parlant !

La seule chose qui pourrait induire une différence (toujours à mon avis, bien sûr, je ne prétends pas avoir la science infuse) est, comme l'a souligné Fred, si on effectue des transformations suivant des profils qui s'éloignent trop de la linéarité.

Citation de: jaric le Avril 04, 2016, 12:57:29
La seule chose qui pourrait induire une différence (toujours à mon avis, bien sûr, je ne prétends pas avoir la science infuse) est, comme l'a souligné Fred, si on effectue des transformations suivant des profils qui s'éloignent trop de la linéarité.

Et le fait que la courbe tonale a été appliquée avec la BdB initiale : est-il possible d'éviter les dérives de couleurs en changeant la BdB ? (vraie question, je ne pratique pas trop PS)

Je n'ai jamais eu en tous cas de difficultés à régler aux petits oignons la BdB sur mes scans en tiff, et pourtant l'équilibre tonal était parfois sérieusement malmené avec le vieillissement des négatifs (voire même parfois de certaines diapos).
J'ai même trouvé l'opération aussi efficace que avec les raw.

Jaric
Je te propose donc de faire une correction à partir de ces deux photos plein format issues d'un Pentax KR réglé en enregistrement RAW + JPG :

http://imgbox.com/kzkcg62H (http://imgbox.com/kzkcg62H)
http://imgbox.com/sy1j8eFc (http://imgbox.com/sy1j8eFc)

- La première est un JPG (je ne peux pas charger des TIF plein format sur un serveur d'images public, mais si tu penses que ça peut faire une grande différence sur le rattrapage d'une BdB fortement décalée, je peux te la charger sur un serveur de partage après un export TIF 16 bits, ce qui va peser lourd) exporté de Lightroom à partir d'un format RAW, BdB (à peu près) réglée correctement.
- La seconde est un JPG direct.

A la prise de vue, la BdB était réglée sur "Lumière artificielle" alors que la photo à été prise au flash, dans une boîte à lumière, ce qui explique donc la forte dominante bleue.

Alors, si tu penses vraiment qu'il n'y a aucune différence, essaie d'obtenir le rendu de la photo 1 sans dégradations à partir de la photo 2. Perso je n'y suis pas arrivé, ni dans LR ni dans PS. ;)

Note : tu parles beaucoup de scans mais à ma connaissance, aucun boîtier ne propose des sorties directes en TIF, que ce soit en 8 ou 16 bits.

Vouloir comparer les tiff issus d'un scanner aux raw d'un APN n'a pas beaucoup de sens : le scanner est construit autour d'un illuminant constant (ou à peu près), les apn doivent faire face à des illuminants très variables (de 2000°K à 6/8000...).

La correction de la colorimétrie d'une diapo vieillissante ne relève pas directement de la correction de la BdB, vu que la BdB d'un scanner est fixe. Après, on peut évidemment s'en servir, mais c'est du rattrapage, pas du traitement basique "propre".   

Citation de: Nerva le Avril 04, 2016, 14:13:26
Note : tu parles beaucoup de scans mais à ma connaissance, aucun boîtier ne propose des sorties directes en TIF, que ce soit en 8 ou 16 bits.

Mon vieux Coolpix 4500 peut enregistrer en Tiff  ;)

Citation de: Nerva le Avril 04, 2016, 14:13:26
Note : tu parles beaucoup de scans mais à ma connaissance, aucun boîtier ne propose des sorties directes en TIF, que ce soit en 8 ou 16 bits.

Si, bien sûr !
Mon Coolpix 990 le proposait, mais les Nikon D8x0 également (TIFF 8 bits).

Et donc, à ma connaissance, je ne les connaissais pas. ;)

Citation de: Nerva le Avril 04, 2016, 14:13:26
Jaric
Je te propose donc de faire une correction à partir de ces deux photos plein format issues d'un Pentax KR réglé en enregistrement RAW + JPG :

http://imgbox.com/kzkcg62H (http://imgbox.com/kzkcg62H)
http://imgbox.com/sy1j8eFc (http://imgbox.com/sy1j8eFc)

- La première est un JPG (je ne peux pas charger des TIF plein format sur un serveur d'images public, mais si tu penses que ça peut faire une grande différence sur le rattrapage d'une BdB fortement décalée, je peux te la charger sur un serveur de partage après un export TIF 16 bits, ce qui va peser lourd) exporté de Lightroom à partir d'un format RAW, BdB (à peu près) réglée correctement.
- La seconde est un JPG direct.

A la prise de vue, la BdB était réglée sur "Lumière artificielle" alors que la photo à été prise au flash, dans une boîte à lumière, ce qui explique donc la forte dominante bleue.

Alors, si tu penses vraiment qu'il n'y a aucune différence, essaie d'obtenir le rendu de la photo 1 sans dégradations à partir de la photo 2. Perso je n'y suis pas arrivé, ni dans LR ni dans PS. ;)

Note : tu parles beaucoup de scans mais à ma connaissance, aucun boîtier ne propose des sorties directes en TIF, que ce soit en 8 ou 16 bits.

Salut Nerva,
J'ai fait ce que tu as proposé avec tes deux jpeg et voici les résultats :
Avec le jpeg 2 direct boîtier, je n'ai réussi comme toi qu'à simplement approcher les couleurs de l'image traitée en raw. On voit qu'il manque manifestement une palettes de tons, quelles que soient les manipulations effectuées.
J'ai alors ouvert dans Camera Raw l'image en mode 16 bits, et là j'ai pu facilement obtenir un résultat en tous points identiques au jpeg1 !

Concernant ta remarque sur la sortie tiff du scanner, j'utilise vuescan (avec win7 64 bits, les logiciels constructeurs ne marchent plus et sont de toutes façons bien inférieurs) que j'ai configuré pour sortir des tiff 48 bits. Ce n'est pas le scanner qui détermine ce paramètre !

C'est un dialogue de sourds, jaric est persuadé que le tif vaut un raw.
Pas grave...
Il a cas tester...

Citation de: brebmika le Avril 05, 2016, 14:41:57
C'est un dialogue de sourds, jaric est persuadé que le tif vaut un raw.
Pas grave...
Il a cas tester...

C'est juste qu'un Tiff c'est une image et qu'un Raw c'est un bizarre brouillon monochrome, sauf Foveon ou tri-ccd. De ce bizarre truc capté derrière une matrice de Bayer (ou version améliorée à la sauce Fuji par exemple) on va "développer" et tirer une image. Les possibilités, les variables sont bien plus étendues que depuis un Tiff même 16 bits.

Même si je ne comprends pas tout (points techniques), je saisis le «suc» du fil, et je suis très content de vous lire.

Jaric
Je voudrais bien voir la photo pour faire une comparaison.

Les RAW du Pentax KR sont en 14 bits. Les images que j'ai mises en liens sont des JPG, donc en 8 bits/primaire. Qu'elles soient ensuite ouvertes ou converties en 16 bits ou même davantage, je ne vois pas comment cette ouverture ou conversion en 16 bits aurait pu enrichir les nuances disponibles de la photo JPG, et par conséquent, l'utilité de la manoeuvre. ::)

Citation de: Nerva le Avril 05, 2016, 16:32:51
Jaric
Je voudrais bien voir la photo pour faire une comparaison.

Les RAW du Pentax KR sont en 14 bits. Les images que j'ai mises en liens sont des JPG, donc en 8 bits/primaire. Qu'elles soient ensuite ouvertes ou converties en 16 bits ou même davantage, je ne vois pas comment cette ouverture ou conversion en 16 bits aurait pu enrichir les nuances disponibles de la photo JPG, et par conséquent, l'utilité de la manoeuvre. ::)

Les Raw du Pentax sont en 1 x 14 bits (monochrome avant dématriçage) et le Jpeg en 3 x 8 bits. On pourrait croire que 3 x 8 c'est mieux qu'une fois 14 ; juste que ce n'est pas du tout la même chose et que la comparaison ne rime à rien.

Citation de: Inka le Avril 05, 2016, 16:59:16
Les Raw du Pentax sont en 1 x 14 bits (monochrome avant dématriçage) et le Jpeg en 3 x 8 bits.

C'est ce que j'ai écrit (8 bits/primaire). Mais je ne vois toujours pas par quelle magie ouvrir une image 8 bits en 16 bits pourrait lui fournir des nuances qu'elle ne possède pas.

Citation de: Nerva le Avril 05, 2016, 17:18:49
C'est ce que j'ai écrit (8 bits/primaire). Mais je ne vois toujours pas par quelle magie ouvrir une image 8 bits en 16 bits pourrait lui fournir des nuances qu'elle ne possède pas.

Passer en 16 bits/couche n'apporte rien tant que l'on ne touche pas à l'image, lors de retouches cela peut être utile pour avoir de meilleurs transitions et une meilleure base pour repasser en 8 bits/couche.

Citation de: Inka le Avril 05, 2016, 15:05:10
C'est juste qu'un Tiff c'est une image et qu'un Raw c'est un bizarre brouillon monochrome, sauf Foveon ou tri-ccd.

Dans un raw, il manque des informations, mais un jpeg peut aussi avoir une reduction des infos de chrominance.

Je crois qu'un raw c'est une image qui est dans l'état scène referred.
Un srgb ou adobeRGB c'est une image qui est dans l'état display referred ( ou output referred je ne sais plus ).

Il me semble que sur color.org, il y a un profile qui permet de générer un tif dans l'état scene refered.

Citation de: frmfrm le Avril 05, 2016, 18:40:41
Dans un raw, il manque des informations [...]

Par principe, non.
Elles sont toutes là, bien sûr, avec la richesse max permise par l'appareil : d'un côté les valeurs de luminance de chaque photosite, de l'autre, les informations de filtrage (RVB) permettant de construire l'image (dans le cas des APN à matrice de Bayer ou assimilée).

Mais, toutes choses étant égales par ailleurs, tout développement du RAW entraine une perte d'informations (il ne peut pas en être autrement), quelquefois sensible et irréversible dans le cas de moirage, par exemple.

Citation de: frmfrm le Avril 05, 2016, 18:40:41
Dans un raw, il manque des informations, mais un jpeg peut aussi avoir une reduction des infos de chrominance.

Je crois qu'un raw c'est une image qui est dans l'état scène referred.
Un srgb ou adobeRGB c'est une image qui est dans l'état display referred ( ou output referred je ne sais plus ).

Il me semble que sur color.org, il y a un profile qui permet de générer un tif dans l'état scene refered.

Gné ?

C'est quoi ce charabia technico/anglo/geek ?

Depuis quand il manquerait des informations dans un raw ?
Parce que s'il en manque dans un raw, alors tous les tiff/jpeg qui en sont TOUS issus (même si on ne fait que du jpeg direct) sont des squelettes, des ombres de fichiers image... 

Citation de: Verso92 le Avril 05, 2016, 19:50:07
Par principe, non.

Il manque des valeurs RGB et c'est du à la technologie si un filtre de bayer est utilisé.

Ma remarque était juste en réponse à la phrase citée qui faisait une distinctions entre les raws issus des capteurs tri-ccd ou foveons et les autres.

Citation de: gerarto le Avril 05, 2016, 19:53:26
Gné ?

C'est quoi ce charabia technico/anglo/geek ?

C'est parce que je pense que si j'effectue une traduction de certains termes à ma manière, tu auras moins de facilité pour trouver des infos sur google.

Mais j'ai l'impression que tu sais deha pleins de choses et que c'est po la peine :)

Citation de: frmfrm le Avril 05, 2016, 20:21:32
Il manque des valeurs RGB et c'est du à la technologie si un filtre de bayer est utilisé.

Ma remarque était juste en réponse à la phrase citée qui faisait une distinctions entre les raws issus des capteurs tri-ccd ou foveons et les autres.

OK... mais la comparaison porte sur RAW vs TIFF. Dans tous les cas, sur un Bayer, il y a une interpolation colorimétrique.
Après, le Foveon ne souffre pas de ce genre de limitations, mais en a bien d'autres, et des plus sévères...

Citation de: Verso92 le Avril 05, 2016, 21:08:59
mais la comparaison porte sur RAW vs TIFF.

Mais j'en parle aussi par la suite :)

Un raw c'est une image, c'est pas un truc innommable parce que c'est pas issu d'un foveon.
Cette image est à une étape.

Si tu la passes par lightroom et que tu génères un tif en srgb, elle sera à une autre étape.

Maintenant, si tu passes ton tif srgb en quadri, et que tu génères nouveau tif, elle sera encore dans une étape différente.

Sur color.org il y a un profile pour générer un tif dès la 1ere étape avec une réponse des tons linéaire. Est-ce que ce tif sera très différent d'un raw ?

Citation de: frmfrm le Avril 05, 2016, 22:58:39
Mais j'en parle aussi par la suite :)

Un raw c'est une image, c'est pas un truc innommable parce que c'est pas issu d'un foveon.
Cette image est à une étape.

Si tu la passes par lightroom et que tu génères un tif en srgb, elle sera à une autre étape.

Maintenant, si tu passes ton tif srgb en quadri, et que tu génères nouveau tif, elle sera encore dans une étape différente.

Sur color.org il y a un profile pour générer un tif dès la 1ere étape avec une réponse des tons linéaire. Est-ce que ce tif sera très différent d'un raw ?

Je ne comprends pas trop où tu veux emmener la discussion... si tu développes ton RAW avec un profil linéaire et que tu l'exportes tel quel en TIFF, tu obtiendras un TIFF linéaire (avec un gamma = 1).
Rien à voir avec la discussion...

Citation de: jaric le Avril 04, 2016, 12:57:29
Ce sont des affirmations sans fondement à mon avis. J'aimerais vraiment qu'on m'explique en quoi appliquer un réglage sur le tiff diffère de celui du RAW.
Parce que pour moi, traiter avant ou après dématriçage ne fait guère de différence si on n'apporte pas de 'bruit' de calcul. Et qu'on ne m'avance pas des termes comme BdB "incrustée" dans le tiff vs le raw, car ça n'a aucun fondement techniquement parlant !

Au contraire la différence est fondamentale.

Pour illustrer les différences entre les deux imaginez que vous souhaitez colorer du lait : vous mettez du bleu dans le lait mais ça ne vous plait pas alors vous le jetez et recommencez avec du lait pur et cette fois vous mettez du rouge. Le lait sera teinté en rouge sans résidus de bleu. C'est ce que permet de faire le RAW car après chaque opération l'image est intégralement recalculée à partir de sa base complètement neutre (le lait pur).

Le TIFF lui est obligatoirement enregistré (une première fois) à partir d'une version calculée du RAW, il ne peut jamais être une base neutre. Il serait comme le lait teinté de bleu dans lequel on ira verser du rouge ensuite. Quoi qu'on fasse, il contiendra toujours des résidus de bleu, et bien qu'à force de rajouter du rouge on finisse par s'approcher de la même teinte, elle ne sera jamais aussi précise que celle du RAW.

Citation de: LeFujiste le Avril 05, 2016, 23:37:54
Au contraire la différence est fondamentale.

Pour illustrer les différences entre les deux imaginez que vous souhaitez colorer du lait : vous mettez du bleu dans le lait mais ça ne vous plait pas alors vous le jetez et recommencez avec du lait pur et cette fois vous mettez du rouge. Le lait sera teinté en rouge sans résidus de bleu. C'est ce que permet de faire le RAW car après chaque opération l'image est intégralement recalculée à partir de sa base complètement neutre (le lait pur).

Le TIFF lui est obligatoirement enregistré (une première fois) à partir d'une version calculée du RAW, il ne peut jamais être une base neutre. Il serait comme le lait teinté de bleu dans lequel on ira verser du rouge ensuite. Quoi qu'on fasse, il contiendra toujours des résidus de bleu, et bien qu'à force de rajouter du rouge on finisse par s'approcher de la même teinte, elle ne sera jamais aussi précise que celle du RAW.

C'est tellement évident que ça m'étonne un peu (sans animosité aucune envers jaric, hein !) qu'on puisse remettre en cause ce genre de fondamentaux...
Le RAW est en quelque sorte une image latente, pour évoquer l'argentique. Le TIFF (Jpeg, etc) est une image développée.

Citation de: frmfrm le Avril 05, 2016, 22:58:39
Sur color.org il y a un profile pour générer un tif dès la 1ere étape avec une réponse des tons linéaire. Est-ce que ce tif sera très différent d'un raw ?

Si le profil est réellement entièrement linéaire (tons et profil des couleurs ?) et a le même point noir que le raw, il reste différent d'un raw pour les opérations de "correction" comme le débruitage, qui peuvent bénéficier de la connaissance des données brutes avec un bon algorithme.

Mais en effet pour la BdB & Cie ce n'est probablement pas moins bon, ces opérations sont de toute façon probablement réalisées après le dématriçage à proprement parler.

D'un autre côté, le raw est fait pour ça, et les logiciels sont assez confortables, ce qui n'est pas le cas de l'utilisation d'un Tiff linéaire :-)

Ce profil est compatible avec quels logiciels de développement des raw ?

Citation de: fred134 le Avril 06, 2016, 00:04:14
Mais en effet pour la BdB & Cie ce n'est probablement pas moins bon, ces opérations sont de toute façon probablement réalisées après le dématriçage à proprement parler.

Tu es sûr de ce que tu avances ?

Citation de: Verso92 le Avril 06, 2016, 00:09:54
Tu es sûr de ce que tu avances ?

Non, j'ai écrit "probablement", c'est juste une hypothèse logique : les algos de dématriçage sur le RGGB sont une chose (je ne vois pas ce que la BdB apporte à ce stade, mais on peut toujours imaginer une astuce à implémenter - mais ce n'est pas probable :-), et ce qui survient derrière est probablement basé sur le RGB "pleine déf" (suis-je clair ?) issu du dématriçage.

A l'appui de cette "logique", les temps de recalcul des aperçus LR selon ce que l'on change... mais ce ne sont que des indices. Perso, c'est comme ça que je ferais a priori, mais je ne suis sûr de rien, soyons clair :-)

Citation de: fred134 le Avril 06, 2016, 00:23:11
Non, j'ai écrit "probablement", c'est juste une hypothèse logique : les algos de dématriçage sur le RGGB sont une chose (je ne vois pas ce que la BdB apporte à ce stade, mais on peut toujours imaginer une astuce à implémenter), et ce qui survient derrière est probablement basé sur le RGB "pleine déf" (suis-je clair ?) issu du dématriçage.

Je dirais ton que ta "logique" m'échappe... dans des discussussions récentes sur Capture One, il semblerait bien que ce soit justement l'inverse.

Citation de: fred134 le Avril 06, 2016, 00:23:11
A l'appui de cette "logique", les temps de recalcul des aperçus LR selon ce que l'on change... mais ce ne sont que des indices. Perso, c'est comme ça que je ferais a priori, mais je ne suis sûr de rien, soyons clair :-)

Je ne pratique pas LR.
Le rafraichissement de l'image affichée par Capture One quand tu changes un réglage de BdB, de courbe, etc, n'est pas quantifiable à l'échelle humaine : c'est instantané (et heureusement : sinon, ce serait quasi inutilisable)...

Citation de: Verso92 le Avril 06, 2016, 00:28:28
Le rafraichissement de l'image affichée par Capture One quand tu changes un réglage de BdB, de courbe, etc, n'est pas quantifiable à l'échelle humaine : c'est instantané (et heureusement : sinon, ce serait quasi inutilisable)...

Dans LR aussi, cela semble plutôt confirmer que ces opérations sont basées sur une représentation intermédiaire (genre RGB linéaire), et non sur la reprise des opérations de dématriçage.

Ton exemple va tout à fait dans le sens de mon hypothèse :-) Je suis surpris que tu penses l'inverse...?

Citation de: fred134 le Avril 06, 2016, 00:39:54
Dans LR aussi, cela semble plutôt confirmer que ces opérations sont basées sur une représentation intermédiaire (genre RGB linéaire), et non sur la reprise des opérations de dématriçage.

Ton exemple va tout à fait dans le sens de mon hypothèse :-) Je suis surpris que tu penses l'inverse...?

Oui, mon exemple n'est pas bon : il est tout à fait possible que l'image affichée ne soit qu'une représentation intermédiaire.
Ce que je voulais dire, c'est que les changements sur un certain nombre d'outils des logiciels de développement RAW sont de type paramétrique*. L'image sera vraisemblablement complètement recalculée lors de l'export (comprendre que le dématriçage sera refait avec les nouvelles valeurs de ces outils).
*Apparemment, ce ne serait pas le cas, par contre, avec les outils qui induisent des déformations géométriques (redimensionnement, correction de la distorsion, des perspectives, etc).

Citation de: Verso92 le Avril 06, 2016, 08:09:22
Ce que je voulais dire, c'est que les changements sur un certain nombre d'outils des logiciels de développement RAW sont de type paramétrique*. L'image sera vraisemblablement complètement recalculée lors de l'export (comprendre que le dématriçage sera refait avec les nouvelles valeurs de ces outils).

*Apparemment, ce ne serait pas le cas, par contre, avec les outils qui induisent des déformations géométriques (redimensionnement, correction de la distorsion, des perspectives, etc).

Oui, c'est aussi comme ça dans LR. (Même si un aperçu 100% est disponible, l'export refait tout le calcul. Probablement entre autres parce qu'un certain nombre d'opérations sont directement appliquées à la représentation RGB, qui n'est donc plus le RGB "primaire" issu du dématriçage - celui-ci n'étant d'ailleurs probablement pas conservé en mémoire.)

Ce que tu écris ne va pas à l'encontre de ce que j'écrivais plus haut, au contraire amha (mais ça reste une hypothèse).

Pour ton astérisque, je n'ai pas compris ce que tu voulais dire ? Ces opérations sont forcément paramétriques, elles sont réversibles et n'altèrent pas le raw...

Citation de: fred134 le Avril 06, 2016, 09:52:57
Oui, c'est aussi comme ça dans LR. (Même si un aperçu 100% est disponible, l'export refait tout le calcul. Probablement entre autres parce qu'un certain nombre d'opérations sont directement appliquées à la représentation RGB, qui n'est donc plus le RGB "primaire" issu du dématriçage - celui-ci n'étant d'ailleurs probablement pas conservé en mémoire.)

Ce que tu écris ne va pas à l'encontre de ce que j'écrivais plus haut, au contraire amha (mais ça reste une hypothèse).

Pour ton astérisque, je n'ai pas compris ce que tu voulais dire ? Ces opérations sont forcément paramétriques, elles sont réversibles et n'altèrent pas le raw...

Ce que je veux dire, c'est que j'imagine qu'un certain nombre d'opérations sont certainement faites de façon globale, avant dématriçage (je ne vois pas l'intérêt, par exemple, de faire une BdB sur des données dégradées par le dématriçage, alors que les données "brutes" sont disponibles).
Par contre, les opérations comme le redimensionnement ou les corrections de perspective, etc, sont faites, apparemment, sur l'image bitmap (dématricée, donc).

Citation de: Verso92 le Avril 06, 2016, 10:17:56
Ce que je veux dire, c'est que j'imagine qu'un certain nombre d'opérations sont certainement faites de façon globale, avant dématriçage (je ne vois pas l'intérêt, par exemple, de faire une BdB sur des données dégradées par le dématriçage, alors que les données "brutes" sont disponibles).

Par contre, les opérations comme le redimensionnement ou les corrections de perspective, etc, sont faites, apparemment, sur l'image bitmap (dématricée, donc).

Avons nous la même définition de "dématriçage" ? Pour moi, c'est l'opération consistant à reconstituer une image RGB pleine définition (3 couleurs par pixel), à partir de l'image RGGB "éparse" (1 couleur par pixel) de départ.

Pour moi, la BdB, le profil colorimétrique, etc, s'appliquent forcément après cette reconstitution.

Sinon, ça reviendrait à faire des combinaisons linéaires (voire non-linéaires) entre des RGGB qui ne sont pas situés au même point de l'image...? ? ?

Citation de: fred134 le Avril 06, 2016, 11:16:19
Avons nous la même définition de "dématriçage" ? Pour moi, c'est l'opération consistant à reconstituer une image RGB pleine définition (3 couleurs par pixel), à partir de l'image RGGB "éparse" (1 couleur par pixel) de départ.

Oui.

Citation de: fred134 le Avril 06, 2016, 11:16:19
Pour moi, la BdB, le profil colorimétrique, etc, s'appliquent forcément après cette reconstitution.

Sinon, ça reviendrait à faire des combinaisons linéaires (voire non-linéaires) entre des RGGB qui ne sont pas situés au même point de l'image...? ? ?

Je ne vois pas en quoi ce serait gênant (c'est, par principe, lié à la structure de type Bayer)...
La seule information fiable, c'est l'info de luminance et la couleur du photosite (R, V ou B). Le reste n'est que du calcul (interpolation).

Citation de: fred134 le Avril 06, 2016, 11:16:19
Avons nous la même définition de "dématriçage" ? Pour moi, c'est l'opération consistant à reconstituer une image RGB pleine définition (3 couleurs par pixel), à partir de l'image RGGB "éparse" (1 couleur par pixel) de départ.

Pour moi, la BdB, le profil colorimétrique, etc, s'appliquent forcément après cette reconstitution.

Sinon, ça reviendrait à faire des combinaisons linéaires (voire non-linéaires) entre des RGGB qui ne sont pas situés au même point de l'image...? ? ?

Bonjour,
Je reviens vers vous après une journée et je vois que le débat a bien progressé !
Je cite Fred car il résume bien l'idée que j'ai également sur le "dématriçge", qui est un bien grand mot pour dire simplement 'calcul des couleurs manquantes à partir des photosites adjacents'.
Excusez-moi si j'apparais troller, mais je ne vois toujours pas pourquoi cela donnerait au raw un statut privilégié. Comme dit Fred, toutes les opérations sur l'image doivent bien s'effectuer après la transformation du raw qui en tant que tel n'est pas exploitable.

Quant au rapport 8 bits / 16 bits, je dis simplement que si on veut modifier un jpeg, on a tout intérêt avant de commencer à transformer l'image en 48 bits afin de minimiser les dégradations apportées (pour s'en convaincre, il suffit de comparer les histogrammes avant/après dans les deux situtations).

Vite, reprenez vos explications, j'aspire à accéder à la Connaissance !  ;D

Citation de: Verso92 le Avril 06, 2016, 11:27:48
Je ne vois pas en quoi ce serait gênant (c'est, par principe, lié à la structure de type Bayer)...

La seule information fiable, c'est l'info de luminance et la couleur du photosite (R, V ou B). Le reste n'est que du calcul (interpolation).

Si tu faisais des combinaisons linéaires (pour simplifier) sur tes RVVB, avant le dématriçage, pour calculer par exemple des R'V'V'B' modifiés par la BdB :
- quelle info R et B utilises-tu pour calculer le V' d'un pixel V par exemple ? C'est déjà du dématriçage.
- tu floutes ton image en faisant ces calculs, ce sont des interpolations spatiales.
- ça me parait ardu de faire ça sans perdre d'info (de manière réversible), mais il faudrait y réfléchir pour être sûr...
- il est beaucoup plus simple de dématricer les RVVB capteur (où l'on peu appliquer les algos qui distinguent luminance et chrominance, détecter des gradients, etc), puis de faire les opérations de transformation de couleur sur du RGB (3 couleurs par pixel).

Ma réponse est trop courte, désolé, je dois y aller mais complèterai plus tard. J'essayerai de décrire un peu le dématriçage et de te retrouver quelques liens sur le sujet.

Citation de: fred134 le Avril 06, 2016, 11:16:19
Pour moi, la BdB, le profil colorimétrique, etc, s'appliquent forcément après cette reconstitution.

Je pense aussi enfin au moins pour lightroom.

Lightroom fonctionne de la facon suivante:

1- Dematricage
2- passage des valeurs RGB en valeurs XYZ,
3- conversion dans l'espace RIMM (gamma 1)
4- affichage a l'ecran et de le l'histogramme de l'espace RIMM mais avec un gamma 2.2

Toutes les autres opérations se font après.

Le profil dont je parlait plus haut est un RIMM avec gamma 1 donc si tu génères un tif qui a ce niveau, tu n'es pas loin de ce que fait lightroom.

Enfin, a mon avis, effectuer une correction de bdb avant dematricage n'a aucun sens :)

Citation de: frmfrm le Avril 06, 2016, 13:54:16
Enfin, a mon avis, effectuer une correction de bdb avant dematricage n'a aucun sens :)

+1 :-)

Pour compléter un peu ma réponse plus haut : disons qu'on passe de pixels rvvb (1 couleur au choix par pixel) à des pixels RVB dématricés (3 couleurs par pixel) mais sans transformation des couleurs - donc toujours les 3 couleurs "brutes capteur".
Voilà en gros le principe pour un pixel "r", tel que je l'ai compris :
- on garde la valeur "r" du pixel (R=r), et on interpole V et B à partir du voisinage rvvb ;
- en utilisant pour les interpolations l'hypothèse que la chrominance varie peu localement, tant qu'on ne change pas d'objet (plein d'algos possibles, je ne sais pas ce qui est utilisé dans le commerce).

Bien sûr les algos sont complexes et cherchent à optimiser la netteté tout en minimisant les artéfacts (je ne suis pas du tout expert et de toute façon il y a des algos propriétaires - il peut éventuellement y avoir une astuce qui utilise l'info d'une BdB très différente de "jour" pour optimiser quelque chose, mais je dis ça juste pour être complet).

Je ne vois donc pas le sens de faire des transformations de couleur sur les valeurs rvvb avant leur dématriçage en RVB (à supposer que ce soit possible, ce qui ne me parait pas évident). Mais bon, comme déjà dit je ne suis pas expert :-)

Un lien relativement simple, et pas forcément très complet : http://tx.technion.ac.il/~rc/Demosaicing_algorithms.pdf
(faites une recherche sur "demosaicing algorithm" pour trouver plus d'infos)

Citation de: frmfrm le Avril 06, 2016, 13:54:16
Enfin, a mon avis, effectuer une correction de bdb avant dematricage n'a aucun sens :)

Là, je ne vois pas bien pourquoi, a priori... le dématriçage en lui-même (comprendre l'association à chaque pixel des deux valeurs primaires manquantes suivant un algorithme plus ou moins sophistiqué) n'apporte aucune information supplémentaire (juste construire une image humainement visible).

Citation de: Verso92 le Avril 06, 2016, 17:44:15
Là, je ne vois pas bien pourquoi, a priori... le dématriçage en lui-même (comprendre l'association à chaque pixel des deux valeurs primaires manquantes suivant un algorithme plus ou moins sophistiqué) n'apporte aucune information supplémentaire (juste construire une image humainement visible).

Bon, j'ai fait quelques recherches sur Internet, mais ce n'est pas facile de trouver une publication qui détaille les étapes avant et/ou après dématriçage...

J'en ai quand même trouvé une (voir lien en fin de post), que je vous résume ici :
--> Traitements pré-dématriçage :

1 - Corrections des erreurs dues à l'objectif
    - Vignettage,
    - correction du noir,
    - Correction des défauts isolés.

2 - Réduction du bruit statique

3 - Balance des blancs

4 - Correction de l'exposition
--> Dématriçage
--> Traitements post-dématriçage

1 - Réduction du bruit colorimétrique

2 - Correction des couleurs

3 - Correction échelle de tons & Gamma

4 - Détection des contours & amélioration du contraste

http://iut-gmp.univ-lille1.fr/fichiers/LPVI/couleur.pdf

Citation de: Verso92 le Avril 06, 2016, 20:28:59
Bon, j'ai fait quelques recherches sur Internet, mais ce n'est pas facile de trouver une publication qui détaille les étapes avant et/ou après dématriçage...

Oui, tu as évidemment raison pour la BdB ! (et en plus j'étais au courant, mea maxima culpa ! :-)

Pour une raison quelconque, dans cette discussion j'ai toujours pensé "matrice de transformation colorimétrique" quand on parlait de BdB (probablement parce que ça revient à ça en Tiff), alors que ce n'est évidemment pas la même chose : de ce que j'ai vu (ex dcraw, ou l'explication succincte DxO), la BdB est implémentée comme un gain sur les canaux rvvb, et donc en effet avant dématriçage. Alors que le profil colorimétrique (par lequel j'étais obnubilé) est évidemment après.
Mes excuses et merci pour ta recherche...

Citation de: Verso92 le Avril 06, 2016, 20:28:59
J'en ai quand même trouvé une (voir lien en fin de post), que je vous résume ici :

Il y a quand même des choses étonnantes dans ce papier, tu l'as lu   ???

Sinon, je ne vois pas ce qu'appliquer la balance des blancs avant dématriçage peut apporter.

Par contre je pense que si tu effectues la bdb avant, tu risques de créer des problèmes pour obtenir un dématricage efficace.

Si tu effectues une bdb tungstène vers couleur du jour, certains pixels bleus et verts risquent de "déborder".

Tu perds des informations alors qu'il n'en a déja pas beaucoup.

Citation de: frmfrm le Avril 07, 2016, 09:46:51
Il y a quand même des choses étonnantes dans ce papier, tu l'as lu   ???
Sinon, je ne vois pas ce qu'appliquer la balance des blancs avant dématriçage peut apporter.
Par contre je pense que si tu effectues la bdb avant, tu risques de créer des problèmes pour obtenir un dématricage efficace.
Si tu effectues une bdb tungstène vers couleur du jour, certains pixels bleus et verts risquent de "déborder".

Je n'ai pas encore eu le temps de vraiment lire le papier cité par Verso, mais pour la BdB c'est le principe retenu dans les mesures DxO de la matrice des couleurs, et surtout on voit ça par exemple dans le code de dcraw (j'avais jeté un oeil rapide, par curiosité). Il y a un équilibrage des canaux raw (avec remise à l'échelle pour éviter de déborder les limites numériques je pense), avant le dématriçage. Et ça me parait tout à fait logique, afin de "corriger" dans une certaine mesure l'influence de l'illuminant, avant les transformations.

Encore une fois, désolé d'avoir écrit l'inverse hier, c'est parce que je pensais "profil colorimétrique" (la BdB comme une transformation matricielle, à la mode Tiff pour renouer avec le sujet), ce qui serait absurde avant dématriçage...

Il peut effectivement y avoir une remise à niveau des valeurs car il n'y a pas de pixel à 0 dans le raw.

Il me semble que certains pixels d'un capteur ne sont pas exposés et que la lecture de leur valeur te permet de ramener à 0, mais tu ne perds pas d'information comme dans une balance des blancs.

Sinon effectivement une balance des blancs peut s'effectuer par calcul matriciel. Dans les cas simples une matrice diagonale est utilisée, dans d'autres , c'est un peu plus compliqué.

Question peut-être stupide : Peut-on enregistrer un raw en raw ?
Je veux dire garder  un raw après modif. au format raw. Autrement dit faire autre chose que du traitement paramétrique.
ACR, LR c'est du paramétrique. DPP pour raw CR2 canon propose bien d'enregistrer en cr2 après modif. Mais si vous ouvrez l'image CR2 dans LR on retrouve les reglages LR du raw initial.
Enregistrer sous en tif, psd, jpeg : on passe à autre chose et on bloque les valeurs RVB.
B_M

Citation de: B_M le Avril 07, 2016, 11:58:17
Question peut-être stupide : Peut-on enregistrer un raw en raw ?
Je veux dire garder  un raw après modif. au format raw. Autrement dit faire autre chose que du traitement paramétrique.

A ma connaissance, non.
Les données du RAW original ne sont jamais transformées. Quand on enregistre un NEF après modifications en NEF avec Capture Nx2, par exemple, les données images "brutes" ne sont pas changées. C'est juste les scripts correspondant aux traitements effectués qui sont enregistrés en plus dans le fichier.

Citation de: jaric le Avril 03, 2016, 23:50:04
Je ne vois pas pourquoi le fichier tiff aurait une dynamique moindre que celle du raw avec un codage sur 16 bits ???

A mon avis, la conversion raw (14 bit) -> tiff (16 bit), tout comme la conversion raw -> dng (16 bit) ne doit pas entraîner de dégradation.

confusion entre le contenu (l'information) et le contenant (dans quoi on la met, ou comment on la code)   :D

Quand on développe un raw (et qu'on le passe en n'importe quoi d'autre, tiff ou jpeg ou autre), on ne va pas forcément gratter le fond des basses lumières. Donc tout ce qui, dans le raw, est sous un certain niveau passe en noir pur dans le tiff et est perdu. Même chose dans les hautes lumières, et notamment dans la réserve du raw (selon l'appareil on peut aller gratter assez haut). Bref, quand on développe un raw on met le noir et le blanc où on veut, et ça ne représente qu'une partie de tous les niveaux de lumière enregistrés dans le raw. Il y a donc perte d'information. Ce qui n'est évidemment pas le cas en raw=>dng puisque le dng c'est du raw, simplement enregistré d'une certaine manière (format de fichier) définie par adobe.

Secondo, on peut très bien développer un raw en tassant le max de dynamique dans la plage disponible d'un jpeg (entre 0 et 255), et développer le même raw en ne gardant qu'une zone réduite des niveaux en tiff 16 bits (entre 0 et 65535). Et alors quel est celui qui a la plus grande dynamique ? Le jpeg bien sûr ;D
Le nombre de bits ne concerne que la précision de codage de l'information de chaque pixel (photosite), étant entendu que quand on passe de 14 à 16 évidemment les 2 bits supplémentaires n'ont pas sens, d'ailleurs sur beaucoup d'appareils le ou les derniers bits sur les 14 du raw n'ont pas de sens non plus (ce n'est que du bruit). Par exemple, un D5 a la même dynamique en 12 bits qu'en 14.

:)

Citation de: astrophoto le Avril 07, 2016, 14:59:28
confusion entre le contenu (l'information) et le contenant (dans quoi on la met, ou comment on la code)   :D

Quand on développe un raw (et qu'on le passe en n'importe quoi d'autre, tiff ou jpeg ou autre), on ne va pas forcément gratter le fond des basses lumières. Donc tout ce qui, dans le raw, est sous un certain niveau passe en noir pur dans le tiff et est perdu. Même chose dans les hautes lumières, et notamment dans la réserve du raw (selon l'appareil on peut aller gratter assez haut). Bref, quand on développe un raw on met le noir et le blanc où on veut, et ça ne représente qu'une partie de tous les niveaux de lumière enregistrés dans le raw. Il y a donc perte d'information. Ce qui n'est évidemment pas le cas en raw=>dng puisque le dng c'est du raw, simplement enregistré d'une certaine manière (format de fichier) définie par adobe.

Secondo, on peut très bien développer un raw en tassant le max de dynamique dans la plage disponible d'un jpeg (entre 0 et 255), et développer le même raw en ne gardant qu'une zone réduite des niveaux en tiff 16 bits (entre 0 et 65535). Et alors quel est celui qui a la plus grande dynamique ? Le jpeg bien sûr ;D
Le nombre de bits ne concerne que la précision de codage de l'information de chaque pixel (photosite), étant entendu que quand on passe de 14 à 16 évidemment les 2 bits supplémentaires n'ont pas sens, d'ailleurs sur beaucoup d'appareils le ou les derniers bits sur les 14 du raw n'ont pas de sens non plus (ce n'est que du bruit). Par exemple, un D5 a la même dynamique en 12 bits qu'en 14.

:)

Si je comprends bien, la loi de conversion raw -> tiff, même si elle est linéaire, ne conserve pas nécessairement la dynamique du raw initial. Cette particularité est-elle propre à chaque algorithme de dématriçage (par là, j'entends fixé par le concepteur du logiciel) et peut-on agir sur l'échelle de transcodage ?

Citation de: jaric le Avril 07, 2016, 16:08:50
Si je comprends bien, la loi de conversion raw -> tiff, même si elle est linéaire, ne conserve pas nécessairement la dynamique du raw initial. Cette particularité est-elle propre à chaque algorithme de dématriçage (par là, j'entends fixé par le concepteur du logiciel) et peut-on agir sur l'échelle de transcodage ?

encore une fois, confusion : ça n'a rien à voir avec un quelconque "algo de dématriçage". Quand tu choisis tes paramètres de développement du raw (expo, tons clairs et foncés, blancs et noirs, contraste et même saturation etc.), tu choisis de fait la plage de valeurs (ou niveaux) qui vont "rentrer" dans ton image développée (avant même de l'enregistrer en tiff ou en quoi que ce soit d'autre), en éliminant ce qui est à l'extérieur de cette plage (et en premier lieu tout ce qui est en-dessous du noir et au-dessus du blanc).
:)

OK, merci, tu m'as convaincu !  :)

Citation de: astrophoto le Avril 07, 2016, 16:19:49
... en éliminant ce qui est à l'extérieur de cette plage (et en premier lieu tout ce qui est en-dessous du noir et au-dessus du blanc).

Oui, à ce propos sais-tu s'il existe des soft ("mainstream") qui permettent d'exporter un développement vraiment linéaire et avec comme point noir le 0 (ou l'offset) du raw ? (Avec LR, j'ai l'impression que même le "linéaire" n'en est pas vraiment.)

Avec Lightroom, tu peux télécharger DNG_profile_Editor et créer un profile avec une réponse linéaire.

Ensuite, dans lightroom, sous étalonnage de l'appareil photo, tu choisis :

processus 2010 et en profile , le profile que tu as créé.

Enfin, dans les tonalités, tu mets tous les curseurs à zéro et contrôle que les courbes de tonalités sont bien plates.

Tu devrais pouvoir obtenir tout ce qu'il y a dans le raw. ( ou presque pour ne pas relancer le débat :) )

Citation de: frmfrm le Avril 07, 2016, 09:46:51
Il y a quand même des choses étonnantes dans ce papier, tu l'as lu   ???

C'est un peu "scolaire", effectivement... mébon, c'est la seule publication que j'ai trouvée hier pour illustrer les traitements effectués avant/après dématriçage.
Mais je serais preneur d'autres publications montrant ces différentes étapes (avec des schémas illustrant les différentes étapes, par exemple)...

Citation de: frmfrm le Avril 07, 2016, 18:06:06
Avec Lightroom, tu peux télécharger DNG_profile_Editor et créer un profile avec une réponse linéaire.
...

Merci, c'est ce que j'utilise en effet (à la base, pour avoir un profil perso). Et je trouve le profil "linéaire" parfois utile, mais depuis qu'un intervenant m'a fait la remarque, j'ai vérifié et comme lui je doute que ce soit réellement linéaire. D'où ma question...

Sinon, pour faire la boucle avec ce qui a été dit, dans ce lien l'auteur essaye d'utiliser dcraw avec l'option "sans BdB" (donc pas de gains différents sur les canaux raw) et une sortie en Tiff avec un rendu linéaire et point noir = celui du raw.
Ensuite, il règle sa BdB dans Photoshop sur le Tiff. Ce qui revient en théorie au même, à partir du moment où tout est réellement linéaire, y compris l'espace de travail PS.
L'ennui, c'est que des artéfacts apparaissent, la méthode d'interpolation (lors du dématriçage) marchant mieux sur une image "équilibrée".
http://www.guillermoluijk.com/tutorial/dcraw/index_en.htm

NB : ici l'essai consiste à ne pas équilibrer du tout les canaux, ce qui est extrême. Il faudrait voir en utilisant par ex la BdB "jour" pour une image "tungstène"...

Citation de: fred134 le Avril 07, 2016, 20:51:41
Merci, c'est ce que j'utilise en effet (à la base, pour avoir un profil perso). Et je trouve le profil "linéaire" parfois utile, mais depuis qu'un intervenant m'a fait la remarque, j'ai vérifié et comme lui je doute que ce soit réellement linéaire. D'où ma question...

Choisir la version de processus 2010 est aussi important car elle est à mon avis plus linéaire que la 2012, mais c'est peut être ce que tu fais déja.
Comment fais-tu pour constater la non linéarité.

Sinon, merci pour ton lien que je lirai en détail et avec intéret et je présente aussi mes excuses à Verso92.

Citation de: frmfrm le Avril 07, 2016, 22:25:56
Choisir la version de processus 2010 est aussi important car elle est à mon avis plus linéaire que la 2012, mais c'est peut être ce que tu fais déja.
Comment fais-tu pour constater la non linéarité.

Merci, j'essayerai, je ne savais pas que 2010 était plus linéaire.
J'avais fait plusieurs essais, je ne me souviens plus de tout mais entre autres j'avais mesuré la rampe de gris d'une colorchecker.

Citation de: fred134 le Avril 07, 2016, 17:41:20
Oui, à ce propos sais-tu s'il existe des soft ("mainstream") qui permettent d'exporter un développement vraiment linéaire et avec comme point noir le 0 (ou l'offset) du raw ? (Avec LR, j'ai l'impression que même le "linéaire" n'en est pas vraiment.)

C'est pour faire quoi ?  ???

Les astronomes font ça (presque) tous les jours, avec des softs astro (certains gratuits d'autres payants) qui travaillent dans des formats spécifiques ou propriétaires (équivalents de psd pour PS, sauf qu'il ne s'agit pas de calques). On a besoin de faire certaines opérations de traitement avant tout développement du raw, donc sur les données vraiment brutes (pas de dématriçage, linéarité, intégralité de la plage de valeurs...)

:)

Citation de: astrophoto le Avril 08, 2016, 09:01:58
C'est pour faire quoi ?  ???

Rien d'aussi compliqué ou scientifique ! :-)

Mais en repro je me suis aperçu que les couleurs étaient souvent plus fidèles en évitant les courbes de tonalité (logique - et possible quand la dynamique du sujet rentre dans la repro). Plus précisément en réglant uniquement le point noir et le point blanc. Idéalement j'aimerais pouvoir retrouver une pente de 1, mais je ne sais pas faire avec LR + PS, je fais à l'oeil.

Et depuis, j'utilise le développement linéaire des fois en paysage, par exemple pour avoir du détail "naturel" dans les hautes lumières (en restant linéaire dans cette zone).

Citation de: Verso92 le Avril 07, 2016, 19:21:13
Mais je serais preneur d'autres publications montrant ces différentes étapes (avec des schémas illustrant les différentes étapes, par exemple)...

A défaut, dans un genre un peu plus "roots" que des schémas, le code de dcraw est public : http://www.cybercom.net/~dcoffin/dcraw/

J'avais trouvé ça relativement lisible (juste pour comprendre les étapes, je n'ai pas cherché à entrer trop dans les détails), alors que je n'ai pas fait de développement depuis la St Glin-Glin. Mais ça demande évidemment un background en informatique (c'est du C).

Citation de: fred134 le Avril 08, 2016, 11:39:59
... Idéalement j'aimerais pouvoir retrouver une pente de 1, mais je ne sais pas faire avec LR + PS, je fais à l'oeil.

Bon, j'ai modifié un bout de programme pour pouvoir générer un fichier raw avec des patchs régulièrements espacés.

Avec lightroom, utiliser le moteur 2010, comme précisé plus haut, mais utiliser le profile Adobe standard et pas un profile linéaire.

Transférer  la photo dans photoshop en srgb.

Sous photoshop, créer un profile srgb linéaire.

Convertir l'image srgb issue de lightroom vers le srgb linéaire.

On obtient un truc comme ci-dessous :

Toujours avec le même raw, mais cette fois ci développé avec dpp.

Dans dpp V3, sortie en mode linéaire, puis attribution du (et pas conversion vers) profile srgb linéaire.

Il y a plus de bandes :)

CitationOui, à ce propos sais-tu s'il existe des soft ("mainstream") qui permettent d'exporter un développement vraiment linéaire et avec comme point noir le 0 (ou l'offset) du raw ? (Avec LR, j'ai l'impression que même le "linéaire" n'en est pas vraiment.)

Dcraw te permet de sortir une image linéaire, mieux que acr.
Les options (flags) (http://www.cybercom.net/~dcoffin/dcraw/dcraw.1.html) sont simple d'utilisations.
Pas besoin de compiler le programme, il existe des versions déjà compilées x86 & x64 (http://www.fastpictureviewer.com/downloads/#links).
Le seul "soucis" avec dcraw se sont les formats portable graphique utilisés pour la sortie (ppm, pgm, pam). Tout comme bon nombres de logiciel d'image il sont limité à 16bits int.
http://mikeboers.com/blog/2013/11/07/linear-raw-conversions
http://www.mit.edu/~kimo/blog/linear.html

Sous Lr, c'est plus "tricky" dans le sens ou il faut passer par des .dcp, faisant office de LUT.

Citation de: Miaz3 le Avril 18, 2016, 22:47:11
Dcraw te permet de sortir une image linéaire, mieux que acr.
Les options (flags) (http://www.cybercom.net/~dcoffin/dcraw/dcraw.1.html) sont simple d'utilisations.
...
Sous Lr, c'est plus "tricky" dans le sens ou il faut passer par des .dcp, faisant office de LUT.

Merci, ce n'est pas très "mainstream" mais c'est une bonne idée, je vais tenter ça à l'occasion (l'ennui, c'est qu'il va falloir aussi chercher et comprendre les profils couleur pour dcraw...)

Dans LR, j'utilise en effet des .dcp produits par DNG Profile Editor, c'est bien ce dont tu parles ?

Citation de: frmfrm le Avril 18, 2016, 21:02:11
Dans dpp V3, sortie en mode linéaire, puis attribution du (et pas conversion vers) profile srgb linéaire.

Merci, trouves-tu que DPP est plus linéaire que LR (avec profil de haddock) ?
Il faudra que je réessaye, j'avais fait le choix de rester dans LR, mais c'était peut-être une erreur et juste de la commodité...

Citation de: fred134 le Avril 19, 2016, 00:27:10
Merci, trouves-tu que DPP est plus linéaire que LR (avec profil de haddock) ?

Les deux process décrits plus haut arrivent à un résultat linéaires. Si tu copies les 2 exemples du dessus dans photoshop, dans l'histogramme, les raies correspondantes aux plages sont (pratiquement) équidistantes.

Maintenant, je trouve que le mode linéaire de dpp ne permet pas de capturer toutes les infos du raw.

Enfin, lightroom travaille dans un espace linéaire , par contre il affiche sont histo de façon non linéaire, mais tu devrais peut-être essayer d'inverser tes néga couleurs sans sortir de lightroom.

CitationMerci, ce n'est pas très "mainstream"

C'est un choix  ;)

Citationje vais tenter ça à l'occasion (l'ennui, c'est qu'il va falloir aussi chercher et comprendre les profils couleur pour dcraw...)

Au cas ou, il y a quelques interfaces graphiques (GUI frontend) dont le fameux Ufraw basé sur dcraw.
Mais aussi quelques -uns sur la toile. (http://www.google.fr/#q=Dcraw+gui+front+end)

Sinon concernant les profils de couleurs avec dcraw, tu peux t'inspirer du lien que j'ai donné plus haut :
http://mikeboers.com/blog/2013/11/07/linear-raw-conversions

CitationDans LR, j'utilise en effet des .dcp produits par DNG Profile Editor, c'est bien ce dont tu parles ?

Oui voila, c'est bien ça. Au delà du profil calibré à ton APN. Tu peux aussi l'utiliser en temps que LUT.
Exemple chez vision color avec visionLOG (http://www.vision-color.com/visionlog/)

Un profil dcp 100% linéaire ?
Et c'est là ou c'est "tricky" car si on veut "maitriser" son flux et avoir un profil dcp linéaire et propre à sont APN c'est pas simple (surtout sur les épaules et pied de courbes cf: voir lien plus haut de Mike Boers).
En tout cas si tu veux plus d'infos et comprendre comment le .dcp fonctionne je te conseil de lire les instructions de cet outil  (http://dcptool.sourceforge.net/Introduction.html)développé par  Sandy McGuffog (http://chromasoft.blogspot.fr/) histoire d'en comprendre un peu plus.

Bonne continuation,

Merci pour vos infos, frmfrm et Miaz3, je vais prendre le temps de bien regarder ça...:-)

Citation de: Miaz3 le Avril 19, 2016, 09:30:29
En tout cas si tu veux plus d'infos et comprendre comment le .dcp fonctionne je te conseil de lire les instructions de cet outil  (http://dcptool.sourceforge.net/Introduction.html)développé par  Sandy McGuffog (http://chromasoft.blogspot.fr/) histoire d'en comprendre un peu plus.

Sur le site de sandy mcGuffog, il y a des informations qui laissent à penser que sur lightroom, la balance des blancs n'est pas effectuée avant le dématricage ;)

Sinon j'ai oublier de mentionner comment créer un srgb linéaire sous photoshop cs2.

   Ouvrir le menu color settings.

   Dans le working spaces RGB, choisir le type Custom RGB.

   Une fenêtre s'ouvre,

      Choisir un gamma de 1.0, les primaires HDTV et l'illuminant D65.

      Valider.

Puis rechanger le working space RGB et choisir l'option save RGB qui créera un profil icc qui va bien...

Citation de: frmfrm le Avril 18, 2016, 19:43:15
Avec lightroom, utiliser le moteur 2010, comme précisé plus haut, mais utiliser le profile Adobe standard et pas un profile linéaire.
Transférer  la photo dans photoshop en srgb.
Sous photoshop, créer un profile srgb linéaire.
Convertir l'image srgb issue de lightroom vers le srgb linéaire.

En réponse à ton dernier post (sur l'espace srgb linéaire), je reprends celui-ci...

Pas besoin amha de passer en sRGB. J'exporte mon image développée dans LR (avec un profil linéaire) en ProphotoRGB 16 bits (on peut transférer directement dans PS d'ailleurs). Dans PS, je convertis en ProphotoRGB "linéaire" (gamma 1) avant de faire les réglages de niveaux.

Une question au passage : je ne comprends pas quand tu dis utiliser le profil Adobe standard ? Tu n'utilises pas un profil linéaire créé avec DNG Profile Editor ? (sur la base colorimétrique de Adobe Standard par exemple)

Citation de: fred134 le Avril 19, 2016, 17:53:45
Pas besoin amha de passer en sRGB. J'exporte mon image développée dans LR (avec un profil linéaire) en ProphotoRGB 16 bits (on peut transférer directement dans PS d'ailleurs). Dans PS, je convertis en ProphotoRGB "linéaire" (gamma 1) avant de faire les réglages de niveaux.

Oui, c'est juste que j'aime bien le srgb ;)

Citation de: fred134 le Avril 19, 2016, 17:53:45
Une question au passage : je ne comprends pas quand tu dis utiliser le profil Adobe standard ? Tu n'utilises pas un profil linéaire créé avec DNG Profile Editor ? (sur la base colorimétrique de Adobe Standard par exemple)

Parce que je n'obtiens pas une réponse linéaire à partir d'un profil linéaire créé avec DNG profile Editor.

Ci-dessous ce que j'obtiens. Les bandes ne sont plus équidistantes sur toute la plage.

Citation de: frmfrm le Avril 18, 2016, 19:43:15
Bon, j'ai modifié un bout de programme pour pouvoir générer un fichier raw avec des patchs régulièrements espacés.

J'ai redécouvert le processus 2010, grâce à toi :-) Faut que je creuse, bien sûr, et ce n'est que pour des usages particuliers...

Aurais-tu éventuellement la gentillesse de mettre à disposition un raw "rampe" ? Si possible, s'étalant sur 14 EV de dynamique pour voir ce que fait LR sur toutes les données ?
C'est une très bonne idée cette rampe virtuelle, et ce serait en effet le plus simple pour comprendre quels réglages employer.

C'est de ça dont tu parle ?
(http://www.jeremy-bepoix.fr/assets/download/post14_LIN.jpg)
postérizé en 14 nuances.tif (http://www.jeremy-bepoix.fr/assets/download/post14_LIN.tif)
postérizé en 16 nuances.tif (http://www.jeremy-bepoix.fr/assets/download/post16_LIN.tif)

Citation de: Miaz3 le Avril 19, 2016, 20:46:08
C'est de ça dont tu parle ?

Presque, mais il ne s'agit pas de fichier tif, mais de raws.
Steph, je te fais un wetransfer des cr2 sur l'adresse email de ton site web car je n'ai pas de site perso où héberger les fichiers.

Il y a 2 raws, un en tungstene et l'autre en lumiere du jour.

C'est à la base des raws de 5D donc sur 12 bits.

Pour point noir j'ai choisi la valeur 0x0083 et pour point blanc la valeur 0x0fff, J'ai choisi le point noir pour dpp, mais le point blanc est peut être un peu trop fort pour lightroom.

Pour lightroom, je peux utiliser un point noir à 0, ca ne le gène pas. Si tu veux d'autres valeurs de noir et blanc, je pourrais te refaire des raws après demain.

Mince, fred pas steph ;)

Ça me semblais étrange comme demande, dans ce cas là elle ne peut pas être "virtuelle"  ;)

Citation de: frmfrm le Avril 19, 2016, 21:22:48
Fred, je te fais un wetransfer des cr2 sur l'adresse email de ton site web car je n'ai pas de site perso où héberger les fichiers.
...
Pour point noir j'ai choisi la valeur 0x0083 et pour point blanc la valeur 0x0fff, J'ai choisi le point noir pour dpp, mais le point blanc est peut être un peu trop fort pour lightroom.
Pour lightroom, je peux utiliser un point noir à 0, ca ne le gène pas. Si tu veux d'autres valeurs de noir et blanc, je pourrais te refaire des raws après demain.

Merci beaucoup, bien reçu !

L'offset du 5D est à 128 (0x0080) sur mes fichiers de 5D, mais ça ne doit pas changer grand-chose pour voir les "courbes de développement". Merci, je regarde et ferai un retour. (NB : LR crame en effet le blanc mais c'est intéressant.)

Miaz, le terme "virtuelle" était peut-être mal choisi, je voulais juste dire que c'est de l'image de synthèse, et pas une vraie photo d'une rampe...

CitationMiaz, le terme "virtuelle" était peut-être mal choisi, je voulais juste dire que c'est de l'image de synthèse, et pas une vraie photo d'une rampe...

Alors c'est le matin hein, mais comment un raw de 5D puisse faire des image de synthese ?

[at] frmfrm:
C'est bien des shoot de ramp que tu as fait ?

Je crois que je ne suis pas sur la même longueur d'onde.

Citation de: Miaz3 le Avril 20, 2016, 08:24:48
Alors c'est le matin hein, mais comment un raw de 5D puisse faire des image de synthese ?
[at] frmfrm:
C'est bien des shoot de ramp que tu as fait ?

Citation de: frmfrm le Avril 18, 2016, 19:43:15
Bon, j'ai modifié un bout de programme pour pouvoir générer un fichier raw avec des patchs régulièrements espacés.

;-)

ha oué ?! mais j'ai toujours du mal à saisir de pouvoir générer un raw qui ne provient pas d'un capteur.

[at] frmfrm :
Par curiosité surtout, si tu as le temps d'expliquer ta méthode (les grandes lignes).

merci,

Citation de: Miaz3 le Avril 20, 2016, 14:07:52

Par curiosité surtout, si tu as le temps d'expliquer ta méthode (les grandes lignes).

Ben j'ai trouvé les sources d'un programme qui permet de décompresser les données d'un raw et surtout de les recompresser et de les ré-écrire dans le fichier d'origine.

Le site n'existe plus mais on le retrouve sur archive.org.
http://web.archive.org/web/20140219063611/http://wildtramper.com/sw/cr2/cr2.html

Le truc a été de prendre la main entre la décompression et la recompression, de générer un bitmap de rampe, de le substituer aux données du raw initial et de forcer la réécriture dans un nouveau fichier.

Sinon fred, j'ai oublié de mentionner que les rampes rouges, vertes et bleues sont tronquées (mais pas la noir et blanc).

Arbitrairement, j'ai effectué une division des valeurs par 8 ( soit un décalage de 3 bits vers la droite ).

Sans cela, les couleurs sont désaturée à l'extrémité des rampes rouges, vertes et bleues et les histos sont plus difficiles à lire.

Même en insérant une ramp les données ne peuvent pas "réagir" comme si tu avait pris une photo d'un ramp ?!
Car peu importe l'origine, si les metas ne correspondes pas au bitmap de ramp le résultat s'en retrouvera faussé. De même que la plage du capteur, le bruit, la répartition de la luminance...

Donc au final que ce soit un tif, raw, exr peu importe.