taille capteur FF et Aps-c, les effets

Là, je sais pas te répondre.

En plus je n'ai pas le 1DX et j'avoue ne jamais avoir regardé sur mes autres boîtiers.

Une question bête, quel que soit le boîtier, quand on met une CF, le compteur de vues restantes varie selon la sensibilité isos affichée, plus on met un iso élevé et moins il prévoit de vues possibles, donc, c'est que les fichiers à hauts isos pésent plus lourd.

Je dis ça à tout hasard, utilises tu les mêmes sensibilités ou, tout joyeux du nouveau joujou, tu abuses des hauts isos?

c'est une théorie hein, j'en sais pas plus que ça sur ce sujet.

Non même pas ..La je parle pour le "tout venant "
Franchement je ne comprends pas ? ??

Je vais regarder de plus prêt ce soir car j ai fait deux jours de "reportage" avec des prises de vue en journée et aussi en soirée.
J avais fait cette même couverture photographique l année dernière avec mon 7D. .donc des éléments de comparaison vraiment fiable.
Par contre j'ai pu faire certaines photos que je n avais pas pu faire l année dernière grâce à cette possibilité de monter en sensibilité.
Heureusement quand même au prix du bout ...
Très content aussi de mon filtre de protection sur mon 150-600 car j aurais pleuré pour retirer les éclaboussures de boue sur la lentille frontale. Par contre je vais passer du temps à nettoyer boîtier et télé. ..

La visée d'un 7d est déjà vraiment tres agreable.
Je confirme sans l'expliquer ... mes fichiers sont 20 à 50 % plus gros en CR2 avec mon 1D que mon 7D avec toujours 5184 X 3456 ......

Citation:

---

Envoyé par francoistn

Non même pas ..La je parle pour le "tout venant "
Franchement je ne comprends pas ? ??

---

Là, je peux répondre à la question. Juste parce que du jpeg, j'en fais depuis trente ans... et que donc je me suis intéressé au problème de l'algorithme expressément à cause du poids des fichiers.

Donc pour résumer:

- Peu importe d'où qu'elles viennent, deux images de 18 mpx ont exactement la même taille numérique. En RVB: 18 millions x 8 (bit de codage par canal on ne parle pas du Raw de base qui peut faire 14 bit) x 3 (R, V & B). Soit 54 Mégaoctets, ou 432 millions de binons (en français, bit en anglais)
En CMYK on multiplie par 4 au lieu de 3.

- Tout commence à s'agiter avec le jpg.
Le principe de base du jpg (je ne vais pas en rappeler l'histoire, hein, ça se trouve sur internet), est de créer des rectangles (pour mémo, un carré reste un rectangle, donc 2 x 2 pixels, c'est aussi un rectangle) dont les valeurs sont proches afin de réduire le nombre de zone à coder.

Le taux de compression définit la latitude de la zone de rectangle ou la différence tolérée entre deux pixels pour qu'ils puissent faire partie d'un même rectangle.

A compression zéro, il ne peut pas y avoir de différence, les pixels d'un même rectangle doivent avoir exactement la même valeur, donc pas de perte à la décompression.
Dès qu'on augmente la compression, on augmente la tolérance et les rectangles s'agrandissent. A la décompression, on ne récupère évidemment pas les valeurs d'origine qui ont été modifiées par l'algorithme, c'est définitif.
Dès le premier degré de compression, l'algorithme tolère une différence entre deux pixels jointifs et agrandit des rectangles. Il y a donc déjà compression destructive à 9 au lieu de 10.

Alors pourquoi, deux images de même taille compressées au même taux peuvent avoir des poids différents?

Eh, bien, c'est très simple. Parce que les images ne sont pas identiques.

Deux images différentes à compression zéro vont donner deux fichiers jpg de poids différent. Et là, tout dépendra des zones unies. Imaginons un ciel bleu avec des nuages, l'algorithme va y trouver des rectangles unis de bleu, de blanc ou de gris.
Prenons par exemple une feuille blanche photographiée avec un éclairage uniforme. Il est possible que dans l'absolu, l'algorithme ne détecte qu'une seule valeur et donc un seul rectangle uniforme.

Autre exemple et test facile à faire, photographier dans le noir total. Ce fichier noir, donnera pareil. Et là la génération de bruit par le capteur va déterminer des rectangles additionnels correspondant aux points de bruit et alourdir le fichier en jpg au prorata inverse de la compression.
Un point de bruit va définir un rectangle. Selon le taux de compression, ce point de bruit va être englobé ou non dans un rectangle plus grand mais probablement pas, car les points de bruit sont très éloignés des valeurs courantes de l'image.

Autre exemple, une photo de paysage avec des feuillages très détaillés. Compliqué pour l'algorithme d'y trouver des rectangles plus grands qu'un ou deux pixels de côté. Donc, le fichier sera plus lourd. La qualité de l'optique permettant de discriminer les détails de l'image et donc la netteté du feuillage aura une incidence directe sur le poids du fichier jpg.

L'optique et le capteur, par leur capacité discriminante, joueront un rôle aussi important que le taux de compression de l'algorithme dans le poids du fichier jpg.
CQFD.

Sur un N&B, si on rajoute un peu de grain, il prends vite deux ou trois méga en JPG

Citation:

---

Envoyé par Balilaï

Sur un N&B, si on rajoute un peu de grain, il prends vite deux ou trois méga en JPG

---

Bel exemple.

Citation:

---

Envoyé par SRT100

L'optique jouera un rôle aussi important que le taux de compression de l'algorithme dans le poids du fichier jpg.

---

Tu peux expliciter ? Car mis à part une influence indirecte en lien avec l'arrière plan plus flou pour une optique utilisée à grande ouverture, donc plus facilement "compressible" qu'un arrière plan détaillé, je ne vois pas comment...

Bonjour,

Citation:

---

Envoyé par briceos

Tu peux expliciter ? Car mis à part une influence indirecte en lien avec l'arrière plan plus flou pour une optique utilisée à grande ouverture, donc plus facilement "compressible" qu'un arrière plan détaillé, je ne vois pas comment...

---

Avec un objectif plus piqué, plus de détail, plus de contraste et micro contraste => plus difficile à compresser donc la taille augmentera

Bonjour,

Citation:

---

Envoyé par francoistn

Je confirme sans l'expliquer ... mes fichiers sont 20 à 50 % plus gros en CR2 avec mon 1D que mon 7D avec toujours 5184 X 3456 ......

---

D'apres les courbes DxO entre 7D et 1DX on gagne de 1 à 2 bits sur les courbes des tons et des couleurs (en fonction des isos), plus de tons ou plus de variations de couleurs possibles donnent plus d'informations différentes à stocker, la aussi un peu plus difficile à compresser donc le jpeg intégré devrait être plus gros.

Le capteur du 7D a un peu plus de pixel que le 1Dx ;)

Oui on est sur le même raisonnement. Ça reste une conséquence indirecte car les raccourcis sont rapides à faire. On ne peut pas dire par exemple qu'on aura des JPGs plus volumineux parce qu'on aura monté telle ou telle optique. Ça dépend surtout de l'image et de la sensibilité utilisée.

Citation:

---

Envoyé par briceos

Oui on est sur le même raisonnement. Ça reste une conséquence indirecte car les raccourcis sont rapides à faire. On ne peut pas dire par exemple qu'on aura des JPGs plus volumineux parce qu'on aura monté telle ou telle optique. Ça dépend surtout de l'image et de la sensibilité utilisée.

---

Pas aussi sur que toi, à "image" identique même boitier, sur trépied, mêmes réglages mais 2 optiques différentes plus ou moins piquées (ou 2 versions d'une même optique) ou plus ou moins neutre en colorimétrie (Canon et Tamron), sans parler de transmissions différentes, etc ... Tout ce qui pourra entrainer des variations dans ton images pourra avoir une influence sur la compression et donc la taille.

Pour une même "image" (même boitier, même paramètres, ...), je pense sérieusement qu'une optique considérée plus piquée fournira une image plus grossse qu'une optique moins piquée.

Ne dissociez pas.

Optique, capteur, ISO, tout a un effet sur le jpg.

Plus d'ISO, plus de bruit, plus gros fichier.

Citation:

---

Envoyé par briceos

Tu peux expliciter ? Car mis à part une influence indirecte en lien avec l'arrière plan plus flou pour une optique utilisée à grande ouverture, donc plus facilement "compressible" qu'un arrière plan détaillé, je ne vois pas comment...

---

Là, tu expliques toi-même le problème.

Plus de détails, plus de pixels différents, plus de rectangles à coder, plus gros fichier.

On parle bien toujours de comparer deux images de même taille.

Effectivement j avais remarqué que plus le fichier est détaillé plus il est lourd. .je me suis retrouvé régulièrement avec des jpg de plus de 10 Mo avec mon 7D en cas de photos sans grande partie de ciel ou gros bokeh ...
Yvnod77 : ces 1 à 2 bit sur les couches de tons doivent influer .. par contre 7d et 1dx même nombre de pixel.c est le 7d2 qui est plus fourni.

Ce que je veux dire par là, c'est que par rapport aux ISOs utilisés ou à la complexité des textures de la scène, la qualité de l'optique doit vraiment jouer à la marge.

Et pour les raws?

Je vais essayer de trouver deux photos assez ressemblante et je vous donnerai le poids en CR2 donc sans passage par le jpg.
J ai été obligé de me racheter une carte mémoire car j ai vraiment manqué de saturé celle que j avais ... deux facteurs aussi le dessus. . Et cas un peu particulier. .. reportage avec rafale et des images très détaillées

En théorie, idem, la compression du RAW même non destructrice est plus difficile pour des zones détaillées par rapport à des zones avec des aplats de couleurs.

Oui bien sure ..un raw d une image détaillée est plus lourde qu une photo avec une grande partie de ciel ..

Pour les jpg , je l avais depuis longtemps ..Certaines photos de mon 450d dépassait les 7mo, rares mais ça arrivait

Donc c'est bien lié à la quantité d'infos et peut-être aux algos?

et entre un mem objo a pleine ouverture (voir ferme d'un cran ou 2 pour ameliorer le pique) et le meme utilise a l'hyperfocale ?

Citation:

---

Envoyé par Mnemmeth

et entre un mem objo a pleine ouverture (voir ferme d'un cran ou 2 pour ameliorer le pique) et le meme utilise a l'hyperfocale ?

---

Grosse différence de poids ... mes premières vraiment grosses photos étaient des photos prises à 10 mm à la distance hyper focale. . Zone de netteté très grande sur un parterre d herbe donc rempli de détails

Merci aux contributeurs qui participent à ce sujet très intéressant, j'ai appris plein de choses :punk:

Citation:

---

Envoyé par Thomas Anderson

Et pour les raws?

---

j'ai prêté mon bouquin sur les raws à un possesseur de 5D2 qui ne me l'a jamais rendu. Donc, je ne sais pas quel type de compression le raw utilise, mais je peux chercher.

Non destructrice, cette compression est selon les sources détaillées trouvées sur le net de type jpg. Donc compression minimum, ce qui n'empêche pas de gagner pas mal de place. Cela réduit donc la compression aux seuls pixels identiques.

Si les Raws n'étaient pas compressé, ils seraient énormes, vu la profondeur du pixel en 14 bit. A l'inverse, la compression profite de la dynamique. Quand vous regardez l'histogramme, les zone vides à droite et à gauche sont facilement compressibles.

Pour info, les fax que tout le monde a connu, il y a quelques années opéraient un peu de la même façon. A chaque ligne scannée, le fax envoyait un message du genre: "10 points blancs, 7 points noirs, 2 points blancs, 1 point noir, 12 points blancs, etc."
C'étaient donc des lignes et pas des rectangles, mais le principe est le même.

Ta phrase est contradictoire. La compression des RAWs est effectivement non destructrice, mais donc pas de type JPG. C'est plutôt du LZW comme les ZIP.

Citation:

---

Envoyé par briceos

Ta phrase est contradictoire. La compression des RAWs est effectivement non destructrice, mais donc pas de type JPG. C'est plutôt du LZW comme les ZIP.

---

Non.
Le jpeg n'est pas nécessairement destructeur. Selon les programmes la compression va de 1 à 10 ou de 1 à 12, le chiffre le plus grand est sans destruction de données.

Désolé pour le texte jaune, c'est pour distinguer les sources. ;))

###############
Pas de soucis ca aide a la lisibilite du texte ;-)
###############

Voici ce que dit le site Canon:

Lossless and lossy compression/Canon RAW format

File compression techniques that lose some of the original data are called ‘lossy’. However, ‘lossless’ compression is also available. This is used by Canon digital cameras when the highest resolution image is stored as RAW data.
Lossless compression uses mathematical algorithms to pack all the data into less space. This compression is fully reversible, so that when the file is opened, all the data is still there. This means that there is no reduction in image quality.
Lossless compression cannot achieve the file size reductions offered by JPEG compression, but Canon RAW format files can often be saved at a quarter of the size of an uncompressed file. (The actual file size is affected by the subject and the ISO speed.)
The RAW setting captures all the sensor data and records it without any significant processing inside the camera. This means that you can work on the file once it has been downloaded to a computer, experimenting with different settings until you get the image you want. This extends to adjusting the colour balance and other image parameters such as sharpness and contrast.
A RAW file is often described as a ‘digital negative’, because it offers the creativity given by a film negative in the darkroom.


Voici le détail du code RAW: on remarquera que la mention jpeg y figure à plusieurs endroits. Si on suit le lien en orange, un autre détail est accessible, qui mentionne lui aussi la présence de compression jpeg sans perte dans le RAW.


Code: [Select]
Although not publicly documented by Canon, their CR2 RAW file format specifiction is scattered in bits and pieces across the web. Compiled here is believed to be an accurate specification for the orignal CR2 compression. Because I own the original Canon 5D, this specification reflects its CR2 formatting. Newer 5D versions have other compression varieties such as sRAW (sRAW1, sRAW2, etc.), and these are not supported by this software.
Included here is the CR2 coder/decoder and a zip file of its C-code implementation. The companion Canon CRW Specification may also be of interest. Another good source of CR2 information can be found in a document titled Understanding What is stored in a Canon RAW .CR2 file, How and Why at Inside the Canon RAW format version 2, understanding .CR2 file format and files produced by Canon EOS Digital Camera.
The specifiction is listed below and is included in the cr2.zip (revised 11/10/08) file as comments of the primary code file Cr2Codec.cpp. The zip file contains the following:
Cr2Codec.cpp - Primary C-code for CR2 coder/decoder
Cr2Codec.exe - its sample excutable
Cr2Codec.h - its header file
MakerNote.h - A few definitions for Canon's TIFF maker-note
Prop.h - Properties type definitions
RawUtl.cpp - Various raw utilities
RawUtl.h - and its header file
TiffTags.h - TIFF tag definitions
TiffUtl.cpp - Various TIFF utilities
TiffUtl.h - and its header file
getput.cpp - Low level input/output
getput.h - and its header file
jpeg.h - Various JPEG definitions
The executable Cr2Codec.exe must be run in a Windows command shell. Executing the command without parameters yields its syntax as follows:
Usage: Cr2Codec.exe [options] file.cr2 outfile
Decompress raw image data of file.cr2
-b: decode then save binary file (default)
-c: decode then recode file
-h: decode then create (text) histogram
-j: extract JPG image
-t: decode then save as 8-bit TIFF file
-T: decode then save as 16-bit TIFF file
Version 1.0
Wildtramper.com, Copyright (c), All rights reserved
Although the -t or -T options create a TIFF file from RAW, expect crude colorization. The -j option is useful to extract the embedded JPG file, and it has Canon's as-shot colorization. This JPG is believed to be optimized for the camera's on-board LCD display -- what to heck, it's a quick view.
/************************************************** *************************
* The Canon CR2 file format is an encapsulated TIFF shell having 4 IFD sets.
* These IFDs are different versions of the same image.
*
* +=====================================+ Start of TIFF/CR2 file
* | TIFF Header |
* | Size = 8 |
* +=====================================+
* | Various TIFF Tags describing File | IFD #1 Segment
* | EXIF (TIFF subdirectory) | Canon 5D image size 2496x1664
* |- - - - - - - - - - - - - - - - - - -|
* | JPEG data (baseline compression) |
* +=====================================+
* | JpegInterchangeFormat | IFD #2 Segment
* | | unknown image size
* |- - - - - - - - - - - - - - - - - - -|
* | JPEG Compressed data |
* +=====================================+
* | Few TIFF Tags describing segment | IFD #3 Segment
* | | Canon 5D image size 384x256
* |- - - - - - - - - - - - - - - - - - -|
* | JPEG data (unknown compression) |
* +=====================================+
* | Few TIFF Tags describing segment | IFD #4 Segment - RAW image
* | | Canon 5D image size 4476x2954
* |- - - - - - - - - - - - - - - - - - -|
* | JPEG data (lossless compression) |
* +=====================================+
*
* A sample parsing of these IFDs are:
* sample.cr2: FileID=II, Ver=2A, IFD #1 w/ 14 Tags
* TagName(TagID,Len,DataOfst) =Value
* ImageWidth(0100,1,001A) =2496
* ImageLength(0101,1,0026) =1664
* BitsPerSample(0102,3,00BE) =8 8 8
* Compression(0103,1,003E) =6 {JpegCompression}
* Make(010F,6,00C4) ="Canon"
* Model(0110,D,00CA) ="Canon EOS 5D"
* StripOffsets(0111,1,0062) =82349
* Orientation(0112,1,006E) =1 {TopLeft, Normal}
* StripByteCounts(0117,1,007A)=1030590
* XResolution(011A,1,00EA) =72/1 (=72)
* YResolution(011B,1,00F2) =72/1 (=72)
* ResolutionUnit(0128,1,009E) =2 {InchUnits}
* DateTime(0132,14,00FA) ="2006:09:24 07:14:52"
* Exif(8769,1,00B6) =270
* TagName(TagID,Len,DataOfst) =Value
* ExposureTime(829A,1,0264) =1/80 (=0.0125)
* FNumber(829D,1,026C) =4/1 (=4)
* ExposureProgram(8822,1,0130) =3
* ISOSpeedRatings(8827,1,013C) =100
* ExifVersion(9000,4,0148) =48 50 50 49
* DateTimeOriginal(9003,14,0274) ="2006:09:24 07:14:52"
* DateTimeDigitized(9004,14,0288) ="2006:09:24 07:14:52"
* ComponentsConfiguration(9101,4,016C) =1 2 3 0
* ShutterSpeedValue(9201,1,029C) =417792/65536 (=6.375)
* ApertureValue(9202,1,02A4) =262144/65536 (=4)
* ExposureBiasValue(9204,1,02AC) =0/1 (=0)
* MeteringMode(9207,1,019C) =5
* Flash(9209,1,01A8) =16
* FocalLength(920A,1,02B4) =24/1 (=24)
* MakerNote(927C,12548,02BC) =29 0 1 0 3 0 46 0 0 0 30 4 0 0 2 ...
* UserComment(9286,108,12804) =0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ...
* FlashpixVersion(A000,4,01D8) =48 49 48 48
* ColorSpace(A001,1,01E4) =1
* PixelXDimension(A002,1,01F0) =4368
* PixelYDimension(A003,1,01FC) =2912
* Interoperability(A005,1,0208) =76044
* FocalPlaneXResolution(A20E,1,1292A) =4368000/1415 (=3086.93)
* FocalPlaneYResolution(A20F,1,12932) =2912000/942 (=3091.3)
* FocalPlaneResolutionUnit(A210,1,022C)=2 {InchUnits}
* CustomRendered(A401,1,0238) =0
* ExposureMode(A402,1,0244) =0
* WhiteBalance(A403,1,0250) =0
* SceneCaptureType(A406,1,025C) =0
* sample.cr2: FileID=II, Ver=2A, IFD #2 w/ 2 Tags
* TagName(TagID,Len,DataOfst) =Value
* JPEGInterchangeFmt(0201,1,12944) =76348
* JPEGInterchangeFmtLen(0202,1,12950)=6001
* sample.cr2: FileID=II, Ver=2A, IFD #3 w/ 11 Tags
* TagName(TagID,Len,DataOfst) =Value
* ImageWidth(0100,1,12962) =384
* ImageLength(0101,1,1296E) =256
* BitsPerSample(0102,3,129E2) =8 8 8
* Compression(0103,1,12986) =6 {JpegCompression}
* Photometric(0106,1,12992) =2 {RGB}
* StripOffsets(0111,1,1299E) =1112939
* SamplesPerPixel(0115,1,129AA)=3
* RowsPerStrip(0116,1,129B6) =256
* StripByteCounts(0117,1,129C2)=294912
* PlanarConfig(011C,1,129CE) =1 {ChunkyFormat}
* UndefinedTag(C5D9,1,129DA) =2
* sample.cr2: FileID=II, Ver=2A, IFD #4 w/ 6 Tags
* TagName(TagID,Len,DataOfst) =Value
* Compression(0103,1,129F2) =6 {JpegCompression}
* StripOffsets(0111,1,129FE) =1407851
* StripByteCounts(0117,1,12A0A)=9920742
* UndefinedTag(C5D8,1,12A16) =1
* UndefinedTag(C5E0,1,12A22) =1
* UndefinedTag(C640,3,12A36) =1 2238 2238
*
* The first IFD is a low pixel count JPEG image, and for the Canon 5D its image
* size is 2496x1664. Also included as part of the first IFD are an assortment
* of image and shot data, such as Make, Model, and abundant EXIF information.
* The EXIF information is itself an IFD subdirectory, and within the EXIF
* directory is the Tag 'MakerNote' which contains more shot information such a
* lens type and serial numbers. MakerNote is has a TIFF like IFD structure,
* but the "TagType" field follows different rules, see below.
*
* The second IFD is another JPEG rendered image, and it is described by two
* TIFF Tags. It is not clear what the purpose of this image, but noting that
* the section size is very small (6001 bytes in the sample), then the image
* dimensions must also be small. It is likely a thumbnail. Peeking into this
* section one finds four JPEG markers: SOI (start of image), DHT (define
* Huffmann tables), DQT (define quantization tables), and SOS (start of scan).
* There is no SOFn marker to identify the image dimensions.
*
* The third IFD is another JPEG rendered image. In this case there are several
* TIFF tags, and these give the size of the image as 384x256. Certainly a
* small image. Although the compression is tagged as JPEG, it is believed this
* is not the case since (1) the image data contains no JPEG markers and (2) the
* size of the image data is exactly three times the rows times columns (294912
* = 3x384x256). Thus, it is believed the image data is uncompressed RGB.
*
* The forth IFD is the sweet spot of the CR2 file. It is a lossless JPEG
* compressed image of dimensions the size of the camera's photo sensor. Canon
* adds three proprietary TIFF tags which are of unknown meaning, except the Tag
* 0xC640 with values for the sample file {1, 2238, 2238} are described by Dave
* Coffin's as being 'slice' information. Peeking into the JPEG code of this
* section one finds the following markers: SOI (start of image), DHT (define 2
* Huffmann tables), SOF3 (start of frame for lossless, sequential, non-
* differential, Huffman coding), and SOS (start of scan). There are no RSTm
* (reset modulo-8) markers. The section is located at the end of the file, and
* it is this location which makes it easy to replace a 'valued added' version
* of the image with the original.
*
* Decoding lossless JPEG is similar (and simpler) to decoding CRW images. Like
* CRW images, the compressed data is organized as a concatenation of a Huffmann
* code (i.e. HufCode or codeword) followed by a variable length difference code
* (i.e. Diff) bit stream as shown below. Unlike CRW images the HufCode only
* conveys the number of bits required by Diff.
*
* +----------------+-------------+
* ... | HufCode[nBits] | Diff[nBits] | ...
* +----------------+-------------+
*
* Like CRW images, the compressed data is row organized with interleaved BAYER
* grid array data for that row. So with a BAYER grid of RG/GB, the even rows
* has interleaved HuffCode/Diff data for ...RGRGRG..., while the odd rows it is
* ...GBGBGB...
*
* Unlike CRW images, there are no 64 pixel blocks, rather it is the width of a
* row. The initial values at the beginning of each row is the RG/GB value of
* its nearest previous row beginning. For the first row, the initial row
* values are 1/2 the bit range defined by the precision. Thus for 12-bit
* precision:
* Pix[Row, Col] = Val
* Pix[0,0] = (1 << (Precision - 1)) + Diff
* Pix[0,1] = (1 << (Precision - 1)) + Diff
* and for n >= 1
* Pix[n,0] = Pix[n-2,0] + Diff
* Pix[n,1] = Pix[n-2,1] + Diff
* while for any other Row/Column
* Pix[R,C] = Pix[R,C-2] + Diff
*
* Also unlike CRW images the mapping of decoded rows into the image buffer is
* divided into four quadrants. It is unclear why Canon chose this method, but
* nonetheless it's there. The RAW image is divided into 4 equal sized
* quandrants:
* +------------------------+------------------------+ RAW Image
* | | |
* | Quad 0 | Quad 1 |
* | | |
* +------------------------+------------------------+
* | | |
* | Quad 2 | Quad 3 |
* | | |
* +------------------------+------------------------+
* The finished image inteleaves quadrants row segments 0/1 and interleaves
* quandrant rows segments 2/3 while combined quandrants 0/1 is located to the
* left and combined quadrants 2/3 are concatenated to the right:
* +------------------------+------------------------+ Finished Image
* | Quad0.Row0 | Quad2.Row0 |
* | Quad1.Row0 | Quad3.Row0 |
* | Quad0.Row1 | Quad2.Row1 |
* | Quad1.Row1 | Quad3.Row1 |
* | etc | etc |
* | Quad0.RowN | Quad2.RowN |
* | Quad1.RowN | Quad3.RowN |
* +------------------------+------------------------+
* So it can be said that Quads 0 and 2 contain the same two BAYER grid colors
* and Quads 1 and 3 contain the other two BAYER grid colors.
*
* Like CRW images, the actual difference value contained in the Diff[nBits] is
* organized loosely as a signed magnitude number, but has its own specific
* rules. First, it should be noted that the value of nBits determines the
* range of the number. As an example if nBits = 3, then the magnitude (of a
* DiffVal that can be +/- this magnitude) is 4 <= magnitude <= 7, or more
* specifically:
*
* (1 << (nBits - 1)) <= DiffVal <= ((1 << nBits) - 1) // + DiffVal
* -(1 << (nBits - 1)) >= DiffVal >= -((1 << nBits) - 1) // - DiffVal
*
* If the most significant bit (MSB) of Diff[nBits] is one, then DiffVal is
* positive and has a magnitude directly represented by binary value of these
* bits. If however, the MSB is zero, then DiffVal is negative and has a
* magnitude that is the compliment of these bits. As an example if
* Diff[nBits=3] = 101, then DiffVal is 5, whereas if Diff[nBits=3] = 001, then
* DiffVal is -6.
*
* The size of the decompressed image is slightly larger than the final image
* size. A few extra 'black' rows added on top and bottom and a few extra
* 'black' columns may be added to the left and right (but none have been
* observed). These 'black' rows/columns along with a few additional RG/GB
* rows/columns make up a set of Trim rows/columns which are ultimately deleted
* to get the final 'as advertised' RAW image size. Other than noting that some
* of the Trim is 'black,' it is beyond the scope of this description to
* determine the method to find the optimum Trim rows/columns. As an
* observation, customized Trim may (or it may not) be encoded in the Firmware
* of camera so that that the final calibration of the image sensor reflects
* this Trim in a manner that places the center of the image sensor at the lens
* center.
*
* TIFF MakerNote:
*
* The TIFF Tag called MakerNote may be used by a manufacturer to embed any type
* of information. Canon uses this segment. Parsing of this proprietary
* segment follows the following data structures:
*
* typedef struct
* {
* tU16 TagID;
* tU16 TagType;
* tU32 TagCnt;
* tU32 DataOfst;
* } tREC;
*
* typedef struct
* {
* tU16 numRecords;
* tREC RecordDir[numRecords];
* tU8 Heap[];
* } tMAKERNOTE;
*
* The ordering of bytes is 'little endian' (Intel), but this is probably a
* function of the overall TIFF byte ordering. The first two bytes identifies
* the number of records (numRecords), and this is followed by the record
* directory (RecordDir), and this if followed by the Heap of various data.
* Each record directory consists of 12 bytes with 4 fields. The first field is
* the tag identification (TagID), followed by the tag type (TagType), followed
* by the tag count (TagCnt), and finally followed by data offset (DataOfst) or
* if the TagType is 4 then this field is immediate data. This format closely,
* but not exactly, follows standard TIFF.
*
* The TagType fields may have the following meaning:
* Type = 2: ASCII data
* Type = 3: tU16 data
* Type = 4: immediate data
* Type = 7: unknown
*
* The TagID fields may have the following meaning:
* TagType = 0x01: Camera settings 1
* TagType = 0x04: Camera settings 2
* TagType = 0x06: Camera model (string)
* TagType = 0x07: Camera F/W version (string)
* TagType = 0x08: Image number ???
* TagType = 0x09: Owner name (string)
* TagType = 0x0C: Camera serial number (immediate data number)
* TagType = 0x0F: Custom functions
* TagType = 0x95: Lens model (string)
*
* The following is an sample extraction:
*
* 02BC: 1D 00 =NumRecord
* -ID-- -Type ---Cnt--- --Ofst--- #
* 02BE: 01 00 03 00 2E 00 00 00 1E 04 00 00 1 - CameraSettings1
* 02CA: 02 00 03 00 04 00 00 00 7A 04 00 00 2
* 02D6: 03 00 03 00 04 00 00 00 82 04 00 00 3
* 02E2: 04 00 03 00 22 00 00 00 8A 04 00 00 4 - CameraSettings2
* 02EE: 06 00 02 00 0D 00 00 00 CE 04 00 00 5 - "Canon EOS 5D"
* 02FA: 07 00 02 00 18 00 00 00 EE 04 00 00 6 - "Firmware Version 1.1.0"
* 0306: 09 00 02 00 20 00 00 00 06 05 00 00 7 - OwnerName
* 0312: 0C 00 04 00 01 00 00 00 1F 15 CE 42 8 - CameraSerialNum = 0x42CE151F
* 031E: 0D 00 07 00 00 04 00 00 26 05 00 00 9
* 032A: 0F 00 03 00 17 00 00 00 76 09 00 00 a - CustomFunctions
* 0336: 10 00 04 00 01 00 00 00 13 02 00 80 b
* 0342: 12 00 03 00 28 00 00 00 26 09 00 00 c
* 034E: 13 00 03 00 04 00 00 00 A4 09 00 00 d
* 035A: 15 00 04 00 01 00 00 00 00 00 00 A0 e
* 0366: 19 00 03 00 01 00 00 00 01 00 00 00 f
* 0372: 83 00 04 00 01 00 00 00 00 00 00 00 10
* 037E: 93 00 03 00 10 00 00 00 AC 09 00 00 11
* 038A: 95 00 02 00 40 00 00 00 CC 09 00 00 12 = "EF24-105mm f/4L IS USM"
* 0396: 96 00 02 00 10 00 00 00 0C 0A 00 00 13
* 03A2: A0 00 03 00 0E 00 00 00 1C 0A 00 00 14
* 03AE: AA 00 03 00 05 00 00 00 38 0A 00 00 15
* 03BA: B4 00 03 00 01 00 00 00 01 00 00 00 16
* 03C6: E0 00 03 00 11 00 00 00 42 0A 00 00 17
* 03D2: D0 00 04 00 01 00 00 00 00 00 00 00 18
* 03DE: 01 40 03 00 1C 03 00 00 64 0A 00 00 19
* 03EA: 02 40 03 00 66 2B 00 00 9C 10 00 00 1a
* 03F6: 05 40 07 00 88 C0 00 00 68 67 00 00 1b
* 0402: 08 40 03 00 03 00 00 00 F0 27 01 00 1c
* 040E: 09 40 03 00 03 00 00 00 F6 27 01 00 1d
...

En bref,

au final, peu importe de savoir quel type de compression est utilisée dans le RAW.

L'important est qu'on sache qu'il y en a une et qu'elle est de type non destructrice. (LossLess)

Tu peux traduire en verres de pastaga stp?

Citation:

---

Envoyé par Thomas Anderson

Tu peux traduire en verres de pastaga stp?

---

heu non , il a tout bu et est sous la table ..:D:D

Citation:

---

Envoyé par Thomas Anderson

Tu peux traduire en verres de pastaga stp?

---

J'ai dû d'abord traduire pastaga...

J'ai une préférence pour le Henri Bardouin, d'Aix-en-Provence. ;))

Citation:

---

Envoyé par SRT100

J'ai une préférence pour le Henri Bardouin, d'Aix-en-Provence. ;))

---

De Forcalquier.

Mais on s'éloigne du sujet.

Coucou,

Chasseur d'Images n° 384, juin 2016, page 122 notamment...

Etrangement, on y retrouvera des exemples qui ressemblent aux miens et des éléments de langage fort voisins...

Je vous promets que je n'ai pas participé à la rédaction du numéro! :D

Citation:

---

Envoyé par Thomas Anderson

Coucou,

Chasseur d'Images n° 384, juin 2016, page 122 notamment...

Etrangement, on y retrouvera des exemples qui ressemblent aux miens et des éléments de langage fort voisins...

Je vous promets que je n'ai pas participé à la rédaction du numéro! :D

---

cachotier, tu es un redacteur de CI :D... quand j'ai lu l'article j'ai tout de suite penser a tes remarques :D:D

Mais ... meme si je fais "aussi" confiance a CI qu'a tes propos, je ne regrette pas pour autant mon choix de 1Dx par rapport au 7D II.
Pour diverses raisons, logiques et illogiques ... car bdm ... qu 'est ce que c'est agréable d utiliser un 1Dx pour faire des photos .. surtout sous la pluie comme hier !!. il a encore bien morflé !... enfin ... surtout moi !:D