[A900] Différence entre RAW et cRAW !

[ear_78]

Bah... Si la compression occasionne beaucoup de pertes surement mais je ne crois pas que cela soit le cas.

[jr56]

Dans ce cas, non, car s'il y avait beaucoup de pertes, tu le verrai sur les 50x75.

Ceci dit j'en étais resté au fait que personne ne semblait savoir quel algorithme de compression précis était utilisé par Sony (mais mes souvenirs datent des discussions lors de la sortie de l'alpha 700).

[Goldensilk]

Pour ma part j'utlisais Camera raw, alors pour ne pas changer mes petites habitudes, j'ai mis à jour en v4.6, et ça s'ouvre niquel!

Pas beaucoup joué avec les courbes, la seule chose que je n'ai pas compris, c'est que je me suis servi de la fonction Dynamique (que je découvre également ^^), avec un +3 je crois de mémoire, et là sur l'écran de mon appareil les zones sombre etaient plus clair et inversement!
Par contre en ouvrant le RAW dans camera RAW, bien elle redevenait sombre comme si le RAW annulait les réglage pris sur mon appareil...

Je vais peut-être installer les logiciel Sony... ^^

[Flash]

comme si le RAW annulait les réglage pris sur mon appareil...

Ces réglages ne s'appliquent que lorsque tu shootes en JPG, c'est une sorte de "post-traitement" automatique au niveau du boitier. (à l'écran c'est toujours une vignette JPG que tu vois, jamais ton RAW)
Le RAW, c'est pas une image mais les données bruttes du capteur (avant tout traitement) donc sans tous ces réglages de boitier. Pour faire court la seule chose qui inflence les données RAW c'est le triplet Sensibilité ISO, Ouverture et Vitesse; tout les reste c'est du "gadget" pour le JPG.
Donc ce comportement est normal.

[mero]

Avec idc, il me semble que tu dois par défaut retrouver les réglages de l'appareil pour les jpeg, mais pas sûr...

[bulbe13]

Bah... Si la compression occasionne beaucoup de pertes surement mais je ne crois pas que cela soit le cas.

tu tires donc tes 50x75 a partir de craw

[ear_78]

J'en ai fait pour vérifier si c'était destructif ! Je n'ai rien constaté...

[bulbe13]

ok ! une fois que mon ordi aura passé la révision des 100.000 (2x1To en raid...) je passerais au RAW...

[stingray]

Ceci dit j'en étais resté au fait que personne ne semblait savoir quel algorithme de compression précis était utilisé par Sony (mais mes souvenirs datent des discussions lors de la sortie de l'alpha 700).

Si si JR on le connais.
Je m'était farcit le code de dcraw pour décoder l'algo, mais ce brave Dave Coffin code vraiment trop "à sa façon" (mes amis informaticiens utiliseraient ici un terme bien plus grossier), et j'ai abandonné.
Entre temps d'autres s'y sont mis et il y a un fil la dessus sur dyxum.
J'avais la vérif sur dcraw et fait une traduction :

La compression se fait par groupe de 16 pixels.
on code le pixel qui a la plus grande valeur sous 11 bit + sa position sur 4 bits, pareil pour le pixel qui a la plus petite valeur (soit 30 bits pour ces deux pixels), les autres pixels sont codé en 7 bit mais le poids de ces 7 bits dépend de la différence entre la valeur min et max. ça fait 128 bits en tout pour les 16 pixels.

[Xapi]

et euh du coup un tel algo fait que c'est potentiellement destructif dans quel cas de figure ?
je suis pas sûr d'avoir tout bien compris, ça veut dire que certains pixels sont codés sur seulement 7 bits MAIS que ces 7 bits sont placés par rapport à une référence ce qui fait que ce n'est pas vraiment comme si on n'avait que 7 bits pour couvrir la plage entière de la dynamique, c'est bien ça ?

[stingray]

Bien sur que c'est destructif (c'est un algo avec pertes) et d'autant plus qu'il y a une forte dynamique dans tes 16 pixels que tu codes. De plus, en craw ton codage n'est même pas en 12 bits mais en 11 bits (ça c'est pour les accros du 14 bits )
Prenons un exemple, tes 16 pixels en 12 bits sont :
3, 341, 238, 469
3889, 1541, 2034, 1652
3892, 2112, 1479, 2321
120, 105, 2509, 625

Le plus petit est 3 qui en 11 bits va devenir 1 (si on repasse en 12 bits on aura en fait 2)
Le plus grand est 3892 qui en 11 bits va donner 1946 (3892 en 12 bits)
La différence entre les deux en 12 bits vaut 3890. Avec 7 bits on code 128 valeurs, 3890/128 = 30,39. Donc on va prendre comme poids des 7 bits de codage la puissance de 2 supérieure soit 32.

Ensuite on code les autres valeurs :

341 --codage--> (341-3)/32 = 10 --decodage--> 2+10*32 = 322 (le 2 correspond au code de la plus petite valeur des 16 pixels de départ)
238 --codage-->(238-3)/32 = 7 --decodage--> 2+7*32 = 226
469 --codage-->(469-3)/32 = 14 --decodage-->2+14*32 = 450
3889 --codage-->(3889-3)/32 = 121 --decodage-->2+121*32 = 3874
etc ....

Plus la différence entre la plus petite et la plus grande valeur des 16 pixel est faible, plus le codage est bon. Il sera parfait (mais en 11 bits) si la différence est inférieure à 256.

[mero]

Si je comprends bien, sting me corrigera, mais si tu as beaucoup de détails avec un écart de dynamique énorme entre min et max local (16 pixels, ça fait pas beaucoup...), tu as un risque de perte, mais il faut utiliser de l'optique qui tue.

[mero]

Bon.... ben il a été plus rapide....

Sur un a700, pas sûr qu'on y perde quoi que ce soit à coder sur 11bits, sur l'a900, ça se discute, mais à réserver il me semble quand même pour de très grands tirages...

[stingray]

En pratique, il doit y avoir très peu de zones dans l'image ou tu as une perte significative.
La ou cela doit surement jouer c'est si l'on remonte beaucoup l'expo au développement. Ca serait une chose à vérifier.

[Xapi]

Et si tu pars d'une photo correctement exposée à 99%, mais avec des zones grillées pour lesquelles tu choisis finalement de baisser l'expo (quitte à reprendre l'expo en retouche locale là où il faut), c'est pareil ?

Je pose la question car j'ai une de mes photos de vautours qui n'est pas grillée mais qui présente un aspect très étrange au dématriçage : c'est grillé avec l'expo par défaut, pas grave je vais sous-ex au dématriçage, effectivement l'histo revient dans les clous et il y a du détail car je vois bien le détail des plumes sur la zone supposée grillée mais.... ça apparait au final en niveaux de gris sur la zone de HL, a pu de couleur couic disparu, vraiment bizarre
C'était avec IDCv2, je n'ai pas redématricé avec LR2 au retour de vacances, donc on ne peut pas éliminer un problème de dématriçage non plus, mais ceci allié à la difficulté de développer l'ensemble de cette série vautour, m'a fait me poser la question du "à quel point l'aspect destructif est réel dans les cas de transition ombre/lumière très marquée" ce qui est très souvent le cas en animalier sur les piafs notamment.

[mero]

Essaye avec rawtherapee.