|
[A700] CRaw vs RAWSi je recoupe la citation Dyxum reprise par Urgon ci-dessus et ce que j'ai lu ailleurs je retiens que le codage c-raw est:
a) De longueur fixe. Chaque ligne/bloc de 8 pixel est représenté au départ par 12x8= 96bits. Après calculs ils deviennent 64bits enrégistés dans le fichier c-raw. b) Il y a compression. Donc perte car on ne peut pas toujours ramener 96 bits à 64 bits sans en perdre quelques uns. 
c) Le codage est peut-ĂŞtre fait sur des deltas.
j'arrive pas à comprendre la différence entre la transcend et l'extreme 4.
Si la transcend arrive à tenir les 5 ips...y'a pas de raison qu'elle ne le fasse que pendant 2 secondes (environ 10 images). Si elle tient 5 ips elle tient 5 ips point barre. La limitation venant allant du buffer....mais la aucune raison d'avoir une différence entre l'extreme 4 et la transcend....puisque le boitier shoote maxi 5 ips...et que les 2 cartes tiennent 5 ips... Bref, qui peut m'expliquer pourquoi l'extreme 4 tiendrait 5 ips en CRaw sur 21 photos tandis que la transcend ne tiendrait que sur 11 photos.... Comme indiqué, l'extrême IV fait 2GO et la transcend est de capacité supèrieure (8GO); les petites cartes étant en théorie toujours plus rapides.
Ensuite l'extrême IV est garantie 40 MO/s en écriture. La pub commerciale l'annonce comme la plus "rapide du monde". Le buffer arrive à saturation au bout de X photos car la vitesse d'écriture n'est pas égal d'une carte à l'autre. Il serait intéressant de faire le même test avec une sandisk Extrême IV de 8GO pour voir si la différence vient vraiment des dernières générations de carte et (ou) de la capacité de stockage de celles-ci. Mero: tu veux deux bionz pour le flagship? Remarques, cela ne peut pas faire de mal que ce soit pour le Craw, le DRO, la tenue en rafale, le codage sur 14 bits...Je le note dans mon fil.
Le vingt-et-unième siècle sera numérique ou ne sera pas!
Ben non, pas forcément!
Ben si, heureusement Je donne un exemple trivial: "abcdefghijklmnopqrstuvwxyz" : cela fait 26 caractères "l'alphabet" cela fait 10 caractères, et représente exactement la même chose Tout l'art de la compression est de trouver une façon plus habile, plus courte, de coder la même signification. Exemple un peu plus photographique: une ligne d'une photo représentant un ciel tout bleu très saturé. Tu as le choix entre répéter 3000 et quelques fois la séquence (0,0,240), ou de coder :"30xx fois (0,0,240)". Un tel codage peut être sans perte. Coder la différence entre deux pixels réduit en général la quantité de bits, car deux pixels voisins dans une image de la vraie vie ont en général des valeurs peu différentes: la différence des valeurs utilise donc moins de bits que la valeur absolue de chacun d'eux. Dans mon exemple théorique d'une plage bleue uniforme, tu n'auras par ex. qu'à coder la première valeur, puis des différences nulles. Si la variation est faible: par ex. 235,238,237,244.... pour la valeur du bleu, tu n'auras à coder que 235, puis +3,-1,+7... ce qui occupe moins de place que les chiffres initiaux. Les valeurs entre 0 et 255 se codent sur 8 bits. Si tu admets que les différences ne dépassent jamais 64, tu peux coder sur seulement 6 bits: tu as une compression d'un quart sans perdre l'information. Reste que sur des différences - rares- excédant 64, il faut trouver une astuce si on veut une compression sans perte. Par ex. un code d'exception, qui te permet de coder une différence plus forte. Cela réduit la compression globale, car à cet endroit précis tu auras besoin de plus de bits, mais si ces fortes différences (contours notamment) sont très minoritaires dans l'image, le gain global reste proche de 25% SRT101, 9xi, D7, D9, Z3, NEX 5N (+viseur), D5D, Alpha 700, Alpha 900 et pas mal de cailloux qui se montent dessus.
Viseur optique... what else? Passer pour un idiot aux yeux d'un imbécile est une volupté de fin gourmet JR565 écrit:
"Si la variation est faible: par ex. 235,238,237,244.... pour la valeur du bleu, tu n'auras à coder que 235, puis +3,-1,+7... ce qui occupe moins de place que les chiffres initiaux." Oui et un bleu uniforme contient une information nulle depuis Shannon. En plus court, je disais: "c) Le codage est peut-être fait sur des deltas." Mais des algorithmes de ce type on peut en inventer plein. Nul doute que celui utilisé dans c-raw à déja été démonté par ceux qui doivent vivre de leurs logiciels.
Oui c'est juste, OK!  SRT101, 9xi, D7, D9, Z3, NEX 5N (+viseur), D5D, Alpha 700, Alpha 900 et pas mal de cailloux qui se montent dessus.
Viseur optique... what else? Passer pour un idiot aux yeux d'un imbécile est une volupté de fin gourmet
On est d'accord,. Le problème bien évidemment c'est que dans un boitier, il faut un algorithme a priori unique, qui va être en moyenne performant sur les images statistiquement les plus courantes prises par le photographe lambda.. C'est ce qui n'est pas simple. Je reste un peu surpris par le fait que Sony n'aurait pas pu gérer les grandes différences (en admettant que c'est ce type de compression qu'ils ont choisi) pour faire un craw sans perte, alors que ces algorithmes sont quant même peu consommateurs de puissance de calculs (moins que d'autres plus élaborés, basés sur une analyse du contenu du fichier par ex.) et qu'ils affirment par ailleurs en DRO avancé auto applliquer des courbes adaptées à 1200 zones différentes de l'image... Mais bon, je ne maîtrise pas ces questions pratiques d'implémentation industrielle dans un boitier et de limites de capacité de traitemlent d'un Bionz... SRT101, 9xi, D7, D9, Z3, NEX 5N (+viseur), D5D, Alpha 700, Alpha 900 et pas mal de cailloux qui se montent dessus.
Viseur optique... what else? Passer pour un idiot aux yeux d'un imbécile est une volupté de fin gourmet Le cRaw semble être à débit constant (il suffit de vérifié que tous vos cRaw sont de la même taille), ce qui voudrait bien dire que c'est avec perte, on ne peux pas savoir "à l'avance" l'entropie de l'image. Si ce que j'ai lu sur dyxum est vrai, je pense que c'est plus compliqué qu'un codage par différence (c'est fait par blocs), mais aussi suffisamment simple pour ne pas prendre trop de ressources. En simplifiant on doit pouvoir se permettre de coder des écarts de niveaux supérieurs à 8 bits, tant qu'il y en a pas trop dans le bloc.
Par contre Sony affirme que la différence est suffisamment infime pour que les erreurs soient complètement négligeables devant les erreurs de dematricage et ça, je veux bien le croire. Sony : A700 - 16-105 KM : D5D, 18-70, M 24-85/3.5-4.5
M42 : Mamiya 28/2.8, CZJ Flektogon 35/2.4, Mamiya 55/1.8, Helios 44-2 58/2, Jupiter 9 85/2, Tair 11A 135/2.8, CZJ Sonnar135/3.5 Tamron Adaptall2 : 24/2.5, 28/2.5, 90/2.5, 200/3.5 Volé ... Reste Rokkor : 35/1.8, 58/1.4 | Nikkor : 85/2 adaptés en MA Nex 6, SEL 16-50, Sigma 30/2.8, Sigma 19/2.8, SEL 50/1.8
La différence RAW/cRAW est très nette en rafale lente : à 3 im/s avec une Lexar UDMA, la rafale en cRAW n'est limitée que par la taille de la carte
Qui est en ligne ?Utilisateurs parcourant ce forum : Aucun utilisateur inscrit et 3 invités  |
|
TOUJOURS 