Toutes les images numériques ne sont-elles pas au final des pixels compris entre 0 et 255?

J'ai quelques questions incroyablement basiques (stupides?) Sur les images; spécifiquement, les formats d'image et les valeurs de pixel.

Pardonne-moi, je ne suis pas photographe. Je suis juste quelqu'un qui travaille avec des images et pour moi, ce ne sont que des lignes et des colonnes de chiffres.

Mes questions sont:

Si, au cœur, les photos ne sont que 3 canaux de valeurs de pixels [0, 255] X RBG, alors comment pourrait-il y avoir une différence entre deux formats d'image? Je veux dire, qu'est-ce qui différencie un fichier RAW d'un fichier TIFF - ne sont-ils pas tous limités à des valeurs comprises entre 0 et 255? Un nombre est un nombre - ne devrait-il pas y avoir un seul format possible? Ou bien deux images de même hauteur et largeur ne devraient-elles pas être verrouillées avec la même taille de fichier?

De plus, d’un point de vue numérique, en quoi une image 16 bits est-elle différente des images 32 bits? Encore une fois, une image est juste un tableau avec des valeurs entières comprises entre 0 et 255.

Poursuivant dans cette perspective selon laquelle une image sur le système de fichiers d’un ordinateur n’est qu’un tableau d’entiers sur 3 canaux compris entre 0 et 255, quel est l’intérêt de compresser une image dans un format avec pertes comme, par exemple, JPG? Supposons que l’algorithme de compression modifie certaines valeurs de pixel de 254 à 255 ou peu importe. Alors? Comment cela permet-il d'économiser la taille du fichier ou d'avoir un impact sur la qualité visuelle?

Je sais qu'il y a beaucoup de façons différentes de stocker des données d'image. Mais je ne demande rien d'autre qu'une image de base RBC à 3 canaux. Tout ce que je sais, c'est que si quelqu'un m'en donne un, j'ai maintenant une série de chiffres. Je n'ai aucune raison de savoir pourquoi un tableau de nombres peut être différent d'un autre tableau de chiffres compris entre 0 et 255. J'espère que cela a du sens. Cette question ne se limite pas au format RAW! Il s’agit plutôt d’un tableau de valeurs de pixels

Désolé, mais votre prémisse de base est fausse: une image peut être codée sous forme de tableau de pixels RBG avec 8 bits par valeur, mais il existe de nombreuses autres manières:

• un canal avec un bit / canal (noir et blanc pur),
• un canal avec x bit / canal (formats en niveaux de gris, x sera généralement 8 ou 16, donnant 256 ou 65 536 valeurs),
• divers formats à base de palette (cf.GIF)
• en couleur avec (du moins en théorie) autant de canaux que vous le souhaitez, avec la profondeur de bits requise.

Et c'est pour l'image stockée dans la RAM de l'ordinateur pendant l'édition / la visualisation. J'ignore les différents formats d'image RAW existants (ici et dans le reste de cet article).

Pour la photographie , les plus courantes sont 3 canaux avec 8, 16 ou 32 bits / canal (généralement des nombres entiers, mais au moins certains programmes fonctionnent en interne avec des nombres à virgule flottante 32 bits). Il existe souvent un 4ème canal (alpha), en particulier lorsque le programme permet l'utilisation de couches. Et quelque part, les dimensions du tableau d’images doivent être stockées.

Il existe différentes raisons pour ces différents formats. Pour le format en mémoire, une considération importante était la taille des données et la vitesse (beaucoup plus rapide pour manipuler un canal 8 bits que 4 canaux 32 bits). Celles-ci sont moins importantes de nos jours, mais nous avons obtenu une gestion complète des couleurs avec différents espaces colorimétriques. Certains d'entre eux (par exemple, RVB prophoto) nécessitent au moins 16 bits / canal pour que les différences entre les couleurs voisines soient suffisamment petites pour éviter les bandes visibles. Et à mesure que les traitements deviennent plus compliqués, l’utilisation de nombres à virgule flottante 32 bits présente des avantages (dans laquelle les couleurs sont codées avec des valeurs comprises entre 0,0 et 1,0 et le traitement permet des valeurs intermédiaires en dehors de cette plage).

Si vous voulez pouvoir stocker l’image dans un fichier et la recharger dans les mêmes données en mémoire, vous devez utiliser au moins autant de bits par canal que le format im-memory, et vous devez stocker des informations sur dimensions de l'image, profondeur de bits et espace colorimétrique.

Les utilisateurs de ces images souhaitent également stocker des informations supplémentaires sur l’image (légende, titre, qui a pris l’image, etc.). Encore une fois différentes façons de stocker cette information.

Ensuite, il existe différentes manières de compresser les données d'image pour le stockage de fichiers. L'un des plus simples est RLE (Run Length Encoding), où vous stockez un nombre et une valeur de pixel chaque fois que vous rencontrez une valeur de pixel répétée. D'autres, comme jpeg, sont beaucoup plus compliqués, mais donnent aussi beaucoup plus de compression. Par exemple, jpeg utilise une transformation en cosinus et jette les informations haute fréquence (moins visibles), donnant des taux de compression élevés au détriment de la perte d’informations (il ya plus, mais cela prend trop de temps).

Cela donne déjà de nombreuses façons de stocker les informations sur le disque, mais quelle que soit la méthode choisie, le format doit être bien spécifié pour permettre une interprétation correcte lors du chargement de l'image.

Il existe ensuite un développement constant des techniques de compression sans perte, par exemple, que les formats existants ne peuvent pas toujours gérer.

Nous nous retrouvons donc avec une variété de formats de fichiers, avec différents compromis entre la fidélité des informations stockées, l’espace disque occupé et la vitesse de lecture, d’écriture et de transmission (comparez la taille d’un TIFF non compressé à une qualité décente jpg) .

Si vous recevez une image en mémoire, celle-ci se présentera sous la forme d'un ou de plusieurs tableaux. À ce stade, le format de fichier d'origine ne devrait plus jouer de rôle . Je suppose que vos données sont traitées avec 8 bits / canal.

Mais vous devrez savoir si vous avez une image traitée ou une image brute, car il existe deux différences importantes entre celles-ci:

• Les images brutes ont généralement 1 couleur par pixel et les pixels sont généralement disposés dans un tableau de Bayer avec 2 pixels verts, 1 rouge et 1 pixel bleu par carré de 4 pixels. Les valeurs sont proportionnelles à l'intensité de la scène (sauf les valeurs très basses et très élevées).
• Les images traitées peuvent être agencées sous forme de matrice 2D d'enregistrements contenant 3 valeurs numériques ou sous forme de plans de couleur (3 matrices 2D, une pour chaque R, V, B). De plus, les valeurs ne sont généralement pas proportionnelles aux intensités de la scène . Pire encore, la relation exacte entre les valeurs des pixels et les intensités de la scène dépend du traitement de l'image. Et la balance entre les couleurs a été ajustée pour correspondre à la réponse de l'œil humain (Balance des blancs, le rouge et le bleu sont amplifiés par rapport au vert).

Ainsi, si vous obtenez une image brute avec 3 valeurs de couleur par pixel, cette image brute a déjà fait l'objet d'un traitement (au moins un dématriçage , ou un simple regroupement de 4 pixels bruts en un pixel d'image). Que cela soit acceptable ou non dépendra de votre application.

Si au cœur, les photos ne sont que 3 canaux de valeurs de pixels [0, 255] X RBG,

Mais les photos ne sont pas "seulement 3 canaux de valeurs de pixels", même "au cœur". Les écrans d'ordinateur sont généralement constitués d'une matrice de pixels RVB, donc si vous voulez afficher une image sur un écran d'ordinateur , vous devez, à un moment donné, la carte toutes les données image que vous avez dans un tableau de pixels RVB, mais que les données ne sont un rendu particulier des données d'image. Les données de l'image peuvent ne pas consister en un flux de valeurs de pixels. Pour obtenir les valeurs de pixel d'une image, vous devez savoir comment les données sont formatées.

alors comment pourrait-il y avoir une différence entre deux formats d'image? Je veux dire, qu'est-ce qui différencie un fichier RAW d'un fichier TIFF - ne sont-ils pas tous limités à des valeurs comprises entre 0 et 255?

Ce sont deux bons exemples, car aucun de ces formats ne contient nécessairement un tableau rectangulaire de valeurs RVB.

RAW n’est pas un format unique, c’est une sorte de nom fourre-tout pour les fichiers contenant des données enregistrées directement à partir d’un capteur d’image. Ainsi, un fichier RAW peut contenir une séquence de valeurs représentant des tensions lues à partir des différents sites de capteurs. Ces sites sont comme des pixels d'image, mais ce ne sont pas des pixels RVB. Pour obtenir des pixels RVB d'un fichier RAW, vous devez interpréter ces données dans le contexte des informations relatives au capteur, aux paramètres de l'appareil photo à l'heure, etc. En d'autres termes, vous pouvez ouvrir un fichier RAW dans un éditeur hexadécimal. et cherchez tout ce que vous voulez, mais vous ne trouverez pas une seule valeur RVB.

TIFF signifie format de fichier d'image balisé , et c'est un format très intéressant car il peut contenir de nombreuses représentations différentes d'une image. Un seul fichier TIFF peut contenir la "même" image dans plusieurs tailles, comme une vignette, une image de résolution d'écran et une image de résolution d'impression, ainsi que des versions en couleurs et en niveaux de gris. Saviez-vous que les télécopieurs envoient généralement leurs données sous forme de fichiers TIFF? Pour obtenir des pixels RGB d'un fichier TIFF, vous devez comprendre non seulement le format TIFF, mais également le format de la représentation particulière de l'image au sein de ce fichier.

Un nombre est un nombre - ne devrait-il pas y avoir un seul format possible?

Non. Il existe de nombreux formats d’image différents, car chacun répond à des besoins différents. La compression avec perte de JPEG est idéale pour obtenir de très petits fichiers image, mais ne convient pas aux images qui devront être modifiées plusieurs fois. Certains formats utilisent l' entrelacement , ce qui rend très rapide la lecture de l'image à différentes résolutions. Et ainsi de suite ... chaque format offre son propre mélange d'avantages et de compromis.

Ou bien deux images de même hauteur et largeur ne devraient-elles pas être verrouillées avec la même taille de fichier?

Non, ce serait terrible. Si la taille de chaque fichier image devait être essentiellement width * height * 3(en supposant une couleur 24 bits), vous perdriez beaucoup d'espace de stockage. La plupart des photos contiennent beaucoup de redondance, c'est-à-dire des régions dans lesquelles la même couleur se répète plusieurs fois. Pour économiser de l'espace de stockage, il est souvent logique d'éliminer ces informations redondantes. Une façon de le faire, par exemple, est le codage de longueur d’exécution.ou RLE. Par exemple, si vous avez une région de 4195 pixels consécutifs qui sont tous blancs, il est beaucoup plus efficace de l'encoder car "les 4195 pixels suivants sont tous {255, 255, 255}" au lieu de simplement stocker autant de pixels blancs le fichier. Le format RLE est effectivement utilisé dans certains formats d'image, mais de nombreux formats ont des schémas beaucoup plus sophistiqués qui permettent d'économiser beaucoup plus d'espace. Cela signifie que vous pouvez stocker beaucoup plus d'images sur un disque dur ou une carte mémoire. En outre, l'envoi de l'image à quelqu'un d'autre est beaucoup plus rapide.

Poursuivant dans cette perspective selon laquelle une image sur le système de fichiers d’un ordinateur n’est qu’un tableau d’entiers entiers compris entre 0 et 255, quel est l’intérêt de compresser une image dans un format avec pertes tel que JPG, par exemple?

Le fait est que cela rend le fichier beaucoup plus petit. La compression JPEG réduit souvent la taille d'un fichier par un facteur de 10 ou plus. Cela signifie que vous pouvez adapter davantage d'images sur un périphérique de stockage donné, les copier plus rapidement, les ouvrir plus rapidement, et les télécharger et les télécharger plus rapidement. Stocker la même image (ou presque) dans un espace beaucoup plus petit utilise les ressources plus efficacement et réduit donc les coûts. Pensez à cela à grande échelle: il est probable qu'un très grand pourcentage des informations disponibles sur Internet se composent d'images et de films. Sans compression, nous aurions besoin de centres de données plus grands ou plus grands et consommons beaucoup plus d'énergie.

Supposons que l’algorithme de compression modifie certaines valeurs de pixel de 254 à 255 ou peu importe. Alors? Comment cela permet-il d'économiser la taille du fichier ou d'avoir un impact sur la qualité visuelle?

Prenons mon exemple RLE ci-dessus. Supposons que votre photo comporte un grand mur vierge. Par conséquent, les grandes zones de votre photo sont toutes de la même couleur, à l'exception du fait qu'il y a une dispersion de pixels légèrement plus sombres, à peine perceptibles dans l'image. Ces pixels réduisent l'efficacité de la compression. Au lieu de pouvoir simplement dire "les 500 000 pixels suivants sont tous {243, 251, 227}", vous devez exécuter la longueur, coder beaucoup plus de morceaux beaucoup plus petits, car vous rencontrez de temps à autre un de ces pixels légèrement différents. Si vous permettez à l'algorithme de compression de faire de petits changements, en modifiant peut-être uniquement un pixel d'au plus 1% ou 2%, vous pouvez obtenir un taux de compression beaucoup plus élevé sans modifier sensiblement l'image. C'est un compromis: vous ' renoncez à une petite quantité d’informations dans l’image originale en échange d’une réduction importante de la taille du fichier. L’emplacement exact où vous souhaitez tracer cette ligne peut changer. Par conséquent, les formats avec perte tels que JPEG permettent à l’utilisateur de choisir le niveau de compression qu’il souhaite.

En plus de la réponse fantastique de @ remco , je voudrais ajouter pourquoi il existe différents codecs pour (à peu près) le même but.

Les codecs sont conçus pour:

• Être sans perte contre perte
• Encoder rapidement contre réduire la taille du fichier
• Décodage asymétrique / symétrique
• Être compatible avec le logiciel
• Être pratiquement sans perte dans différents niveaux / situations de compression
• Avoir des fonctionnalités que d'autres codecs n'offrent pas, y compris:
  • être libre de droits
  • support pour les couches
  • support pour alpha-channel (eg RGBA) / transparrency
  • offre une vue Web rapide
  • prend en charge une plus grande profondeur de bits
  • prend en charge plusieurs espaces couleur (RVB / CMJN)
  • support pour les métadonnées / la gestion des versions / ...

Certaines de ces choses sont mutuellement exclusives. Et à cause de cela, il nous reste une multitude de codecs.

Quelques exemples

Remarque: la liste des codecs n'est pas complète et toutes leurs fonctionnalités (ou leur absence) ne sont pas mentionnées. Si cette réponse s'avère utile à quelqu'un, je pourrais ajouter quelques informations supplémentaires (et être un peu plus précis).

Le format le plus connu est peut-être JPEG . C'est un format très largement supporté, mais ancien. Il utilise la transformation discrète en cosinus (DCT). Ainsi, s'il offre une qualité assez bonne à ses paramètres de qualité les plus élevés, un blocage apparaîtra avec les paramètres les plus bas.

Puis JPEG 2000 est venu remplacer JPEG: il est basé sur la transformation en ondelettes. Ainsi, bien qu’il offre à peu près la même qualité que JPEG dans les paramètres de qualité supérieurs, il offre une bien meilleure qualité dans les paramètres de qualité inférieurs (les blocs sont un peu flous). ). De plus, JPEG 2000 offre des zones d'intérêt (haute qualité dans une zone de l'image, qualité inférieure dans une autre) et prise en charge 16 bits. (En outre, certaines autres choses.) Malheureusement (?), Car il coûte plus cher en calcul que JPEG et en raison de problèmes de licence, JPEG 2000 n’est pas aussi largement pris en charge que JPEG.

Le format PNG est un autre format largement connu: il est sans perte et prend en charge les canaux alpha, mais il ne prend pas en charge les espaces colorimétriques non RVB (tels que CMYK). Par conséquent, il s'agit d'un format "en ligne uniquement".

Ensuite, il y a les formats VFX comme OpenEXR . Ils tournent tous autour de la qualité et de la rapidité: OpenEXR est sans perte, prend en charge jusqu’à 64 bits et encode / décode rapidement. Il est principalement utilisé dans l'industrie des effets visuels en tant que format intermédiaire.

Le format TIFF est un autre format sans perte très populaire auprès des photographes. Pour la compression, il offre none / ZIP / RLE / LZW / JPEG. Il supporte jusqu'à 32bit. Avec sa compression sélectionnable, il est assez adaptatif, mais en raison de son absence de perte, il s’agit plutôt d’un format hors ligne.

HEIF est l’un des derniers codecs d’image. Il utilise la même compression que HEVC / h.265 et devrait donc donner un meilleur taux de compression que JPEG. Cependant, parce qu'il est toutfait nouvelle et parce qu'il estobjet de brevets, il est aussi largement soutenu que tout de ceprécède.

Les images RAW ^{Voir aussi} ne sont pasvraies photos, vraiment: Ils sont plus d'un conteneur pour l'brut (où le nom) capteurdonnéeslecture. Seulement avec un logiciel qui sait interpréter les données, il est possible d'obtenir une image. C’est également pour cette raison que les convertisseurs RAW tels que Lightroom / Capture One / DarkTable / ... ont besoin de mises à jour pour prendre en charge les nouveaux appareils photo utilisant des conteneurs déjà spécifiés, tels que * .CR2 pour Canon. C'est aussi la raison pour laquelle un fichier RAW 14 bits offre plus d'options d'édition qu'un fichier TIFF 32 bits exporté à partir du même fichier RAW.

Intermisision: sans perte ou sans perte

Je ne suis toujours pas sûr de ce que vous demandez vraiment, alors je pensais que cela ne ferait pas de mal d'ajouter une petite explication sur l'absence de perte par rapport à perte.

La compression sans perte fonctionne en effectuant un codage à durée d'exécution (RLE) / un codage de Huffman / ... pour compresser les données. Les données elles-mêmes ne sont pas modifiées, mais enregistrées dans un package plus petit. Par exemple, prenons RLE: Disons que nous avons un train binaire de canal R (de pixel 0,0en pixel 0,11) de 255,255,255,255,255,215,215,235,100,000,000,000- RLE encoderait ceci en tant que 52552215123511003000- ceci est beaucoup plus petit, et puisque nous savons qu’il est sauvegardé par groupes de 4 chiffres et que le premier chiffre est le compteur et les trois derniers chiffres sont la valeur, alors nous pouvons reconstruire le plein 255,255,255,255,255,215,215,235,100,000,000,000.

La compression avec pertes , en revanche, tente de compresser encore plus loin que ne peut le faire sans perte. Pour ce faire, les codecs avec perte tentent généralement de supprimer les choses que notre perception ne comprend pas. Prenons, par exemple, les YUV( YCbCrvraiment) modèle JPEG (et presque tous les codecs vidéo) utilisations: Y = Luminance, Cb = Chrominance Blue, Cr = Chrominance Red. Un humain ne peut pas faire la différence entre une image codée 4:2:0(chaque pixel a une valeur de luminance, mais les couleurs sont enregistrées par blocs de 2x2) et une 4:4:4image codée (chaque pixel a une luminance et les deux canaux de couleur). Cela est dû à la physiologie de notre œil : nous ne pouvons pas voir les différences de couleur aussi bien que nous pouvons voir les différences de luminance.

Cela fonctionne bien la plupart du temps, mais comparez-le avec un fichier MP3: Presque personne ne peut faire la différence entre 192kbps et 320kbps, mais allez au-dessous de 64kbps et les choses se dégradent rapidement. De plus, le réencodage réduira davantage la qualité, car des artefacts indésirables pourraient apparaître (par exemple, en JPEG, les petits blocs d’encodages de haute qualité seront considérés comme des détails de l’image dans les encodages ultérieurs).

Ligne de fond

Si vous ne vous souciez pas des formats d’image ou de leurs caractéristiques, l’un ou l’autre sera acceptable. Avec des paramètres de qualité suffisamment élevés, il est possible et prévisible que vous ne verrez même pas de différence entre eux.

Toutefois, si vous avez besoin de fonctionnalités spécifiques, il est possible (et presque certainement) de disposer d’un codec doté de cette fonctionnalité.

Si au cœur, les photos ne sont que 3 canaux de valeurs de pixels [0, 255] X RBG

Cette hypothèse est sérieusement brisée et le reste de votre question n’est tout simplement pas recevable sans rupture.

Je veux dire, qu'est-ce qui différencie un fichier RAW d'un fichier TIFF - ne sont-ils pas tous limités à des valeurs comprises entre 0 et 255?

Le terme "brut" peut faire référence à deux choses différentes, une image "Camera Raw" ou un fichier contenant des données d'image brutes sans en-tête.

Une image "Camera Raw" stocke les données brutes à la sortie du capteur. La plupart des capteurs de caméra modernes ont un CAN avec plus de 8 bits, mais ils ne collectent également des données d'intensité que pour un composant de couleur à chaque emplacement. La géométrie peut être déformée par l'objectif, les valeurs d'intensité de l'ADC peuvent ne pas refléter correctement la perception de l'intensité par l'homme, les composantes de couleur peuvent ne pas correspondre exactement à celles utilisées par votre moniteur, etc.

Un processus de mappage compliqué impliquant une interpolation est nécessaire pour transformer les données brutes du capteur en une image RVB de bonne qualité, et il n'existe pas de bonne façon de le faire. De plus, en raison de la nécessité d’interpoler les composantes de couleur, l’image RVB risque d’être plus grande que les données brutes.

La conversion peut être (et est souvent) faite dans l’appareil photo, mais de nombreux photographes s’efforcent de sauvegarder les données brutes afin d’améliorer le traitement après coup.

Tiff est un format de fichier complexe pouvant stocker des images dans une grande variété de formats avec une grande variété de métadonnées. En pratique, il est généralement utilisé pour stocker des images RVB ou CMJN non compressées ou compressées sans perte.

Les fichiers contenant des données d'image brutes sans en-tête sont rarement utilisés car vous devez connaître leur format et leurs dimensions avant de pouvoir les lire. Certains outils de traitement d'images les supportent cependant.

De plus, d’un point de vue numérique, en quoi une image 16 bits est-elle différente des images 32 bits?

Malheureusement, "n bit" peut signifier deux choses différentes. Cela peut signifier que toutes les composantes de couleur sont regroupées dans un nombre de bits (par exemple, 5 bits pour le rouge, 5 bits pour le bleu et 6 bits pour le vert pour 16 bits ou 8 bits de rouge, 8 bits de vert, 8 bits de bleu et 8 bits). de alpha pour 32 bits) ou at peut signifier que chaque composante de couleur a n bits d’information à chaque emplacement de pixel.

Poursuivant dans cette perspective, une image sur le système de fichiers d’un ordinateur n’est qu’un tableau d’entiers sur trois canaux compris entre 0 et 255.

Encore une fois, cette perspective est tout simplement fausse.

Un fichier est une séquence d'octets, mais ces octets ne sont presque jamais "juste un tableau d'entiers à 3 canaux compris entre 0 et 255"

Vous pouvez stocker une image comme ça. Certains outils prennent même en charge la lecture et l'écriture de tels fichiers, mais le problème est que cela signifie que vous devez connaître le fichier avant de pouvoir le lire. Supposons que vous ayez un fichier de 3 000 octets de taille, avez-vous 1 000 pixels RVB 24 bits? 3000 pixels en niveaux de gris 8 bits? 3000 pixels 8 bits d'une palette? Dans quel ordre sont les composants de couleur? quelle forme est l'image? sont les composants de couleur dans l'ordre RVB ou BGR? Si vous ne connaissez pas les réponses à ces questions, vous ne pouvez pas lire ce fichier de manière significative.

Ainsi, les formats d'image pratiques commencent généralement par un ou plusieurs en-têtes qui identifient le type de fichier, les dimensions de l'image et la façon dont les données d'image réelles sont stockées. Ils peuvent également contenir des métadonnées facultatives.

Quel est l'intérêt de compresser une image dans un format avec perte tel que JPG, par exemple? Supposons que l’algorithme de compression modifie certaines valeurs de pixel de 254 à 255 ou peu importe. Alors? Comment cela permet-il d'économiser la taille du fichier ou d'avoir un impact sur la qualité visuelle?

Les algorithmes de compression ne se contentent pas de "changer les valeurs", ils codent les informations de manière totalement différente, par exemple, JPEG peut être décrit grossièrement comme suit:

• Convertir les données de RVB en YUV
• (éventuellement) réduire la résolution des canaux de chrominance d'un facteur 2 dans l'une ou les deux dimensions
• Divisez les données pour chaque canal en 8x8 blocs.
• Convertir les blocs dans le domaine fréquentiel à l'aide d'une transformation en cosinus discrète
• Quantifier les résultats, en préservant les informations basse fréquence tout en réduisant la précision des informations haute fréquence.
• Encodez les nombres résultants sous forme d'une séquence d'octets en utilisant un schéma de codage à longueur variable (codage de Huffman ou codage arithmétique)
• Enregistrez ces octets dans le fichier avec les en-têtes appropriés.

Les formats compressés sans perte, d’autre part, reposent souvent sur un algorithme de compression de données à usage général, mais complètent parfois un prétraitement spécifique à une image, par exemple, le format PNG.

• Convertir les données dans l’un des formats pris en charge (par exemple, un bit pour le rouge, le vert et le bleu dans cet ordre)
• Pour chaque ligne de l'image, effectuez un "filtrage", il existe plusieurs options de filtrage (y compris aucun filtrage), mais l'objectif général est de prendre les informations spécifiques à l'image qu'un pixel est susceptible de ressembler à ses voisins et d'encoder. d'une manière que "dégonfler" peut traiter.
• Compressez les données filtrées à l'aide de l'algorithme de compression général "deflate".
• Enregistrez ces octets dans le fichier avec les en-têtes appropriés.

Cette hypothèse est fausse pour plusieurs raisons et toutes se résument à une chose:

Quelle échelle utilisez-vous réellement?

Et cela peut être décomposé un peu plus loin:

Qu'est-ce que 255?

La "couleur" n'est pas une propriété de l'univers physique. C'est une sensation qui surgit dans l'esprit. Et cela inclut des éléments comme "bleu", "vert" et "rouge". Une échelle de 0 signifiant "pas de bleu du tout" à 255 signifiant "tout le bleu!" En réalité, 255 ne représente pas l’idéal platonique du bleu , car… il n’existe pas de chose aussi parfaite dans le monde réel. Alors, cela veut-il dire:

• la chose la plus sûre que vous puissiez faire sur l’appareil devant vous?
• aussi proche du bleu idéal du point de vue du système de vision humaine, même si la plupart des écrans et des combinaisons imprimante / encre / papier ne peuvent pas le représenter?
• un assez bon bleu qui est susceptible d'être raisonnablement représenté sur une grande variété de périphériques?
• un bleu qui est en dehors de la portée de la vision humaine, mais qui permet à votre triple RVB de couvrir la plupart des couleurs qui sont dans la gamme?

Son artificiel? Nan! Ce sont en réalité des exemples réels . Découvrez ces représentations de chaque choix. La zone incurvée est une coupe 2D de l'espace colorimétrique de la vision humaine et le triangle indique la zone pouvant être représentée avec un choix particulier pour le rouge, le vert ou le bleu.

Tout d'abord, voici le profil de mon écran d'ordinateur portable, assez représentatif des appareils actuels de milieu de gamme:

Maintenant, voici l'espace Adobe RGB. Remarquez à quel point c'est plus grand que ce que mon écran peut montrer!

Donc, voici sRGB - la norme defacto et l’espace par défaut généralement pris en charge lorsque rien n’est spécifié. C'est censé être "assez bon" dans la plupart des situations.

Et enfin, ProPhoto RGB, qui utilise des couleurs imaginaires comme couleurs primaires, afin de rendre le triangle assez grand pour s’adapter à la quasi-totalité de la vision humaine.

Ajoutez maintenant la couleur de la lumière elle-même et l'adaptation chromatique - la capacité du système de vision humaine à ajuster la perception à l'environnement. En fait, pas seulement la capacité: cela se produit que vous le vouliez ou non . "Bleu pur" signifie-t-il que cette chose a l'air aussi bleue que possible sous cette lumière incandescente? Quelle devrait être la valeur si nous photographions plutôt au soleil?

Donc, "255" peut signifier beaucoup de choses différentes.

Qu'est ce que 0?

C’est assez simple: à quel point le noir doit-il être 0? Est-ce vantablack noir? Si tel est le cas, mais que toutes les nuances de votre scène sont beaucoup moins extrêmes , voulez-vous vraiment "gâcher" un tas de valeurs potentielles pour une plage dynamique qui ne figure pas dans votre scène - et qui, comme la couleur, peut 'ne même pas être représenté par un périphérique ou une imprimante que vous avez accès?

Quelle est votre courbe?

Alors, une fois que vous avez vos points finaux, comment allez-vous de l'un à l'autre? La perception humaine de la luminosité est résolument non linéaire . Sur votre échelle 0-255, 100 doit-il être deux fois plus brillant que 50 ou devrait-il être un facteur plus important? La différence de perception entre, par exemple, 3 et 4 doit-elle être identique à celle entre 203 et 204?

Si vous décidez d'utiliser un système de stockage de journaux, cette courbe doit-elle être optimisée pour correspondre à la vision humaine, à l'optimisation des données ou à autre chose?

Il existe de nombreuses possibilités, pour de nombreux besoins différents.

En compression

Tu demandes.

Supposons que l’algorithme de compression modifie certaines valeurs de pixel de 254 à 255 ou peu importe. Alors? Comment cela permet-il d'économiser la taille du fichier ou d'avoir un impact sur la qualité visuelle?

Les algorithmes de compression modernes sont plus compliqués que cela, mais cela en fournit un bon exemple. Je vais utiliser hexadécimal FFpour représenter 255 et FEpour représenter 254, et imaginons que nous utilisons le codage de longueur d'exécution comme forme de compression. Et pour simplifier, supposons le noir et blanc au lieu de la couleur. Avec cela, si nous avons une ligne de données qui ressemble à ceci:

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 

nous pouvons compresser cela à un très simple

16×FF 

... ce qui est une économie assez évidente. Nous pouvons en principe stocker 16 octets sur deux (un pour le compte, deux pour les données). Mais disons que nous avons:

FF FF FE FF FE FF FF FF FF FF FE FE FE FF FE FE

Maintenant, l'encodage en longueur nous donne:

2×FF 1×FE 1×FF 1×FE 5×FF 3×FE 1×FF 2×FE

... ce qui ne représente aucune économie et aurait en fait pu augmenter la taille du fichier. Mais si nous arrondissons toutes les FEvaleurs à FF, nous revenons au premier cas, avec une réduction de taille significative, avec un impact faible mais probablement difficile à remarquer sur la qualité du fichier.

Bien sûr, il s’agit d’un exemple trivial et artificiel, mais tous les algorithmes de compression avec pertes partagent cette caractéristique fondamentale: la perte de données facilite l’utilisation d’un format de stockage plus compact, avec, espérons-le, peu de changement perçu .

Sur la profondeur de bits

De plus, d’un point de vue numérique, en quoi une image 16 bits est-elle différente des images 32 bits? Encore une fois, une image est juste un tableau avec des valeurs entières comprises entre 0 et 255.

Donc ..... un tableau de valeurs entières compris entre 0 et 255 est un tableau de huit bits . (2⁸ = 256.) Avec trois canaux, il s'agit d'une image 24 bits. certains formats ont également un canal de transparence ("alpha") pour 32 bits. On peut également utiliser une valeur plus élevée par canal, ce qui correspond généralement à ce que nous entendons par "profondeur 16 bits". Cela signifie que le tableau va de 0 à 65 535 (2¹⁶ = 65 536) plutôt que de 0 à 255. En règle générale, dans un tel schéma, il s’agit en gros d’un multiplicateur dans lequel la valeur la plus élevée représente la même chose sur chaque échelle, mais la profondeur de bits la plus élevée donne plus de nuance possible. (Voir cette réponse pour plus d'informations.) Il existe également certains formats de fichiers spécialisés qui utilisent des valeurs flottantes 64 bits (!) Au lieu des entiers pour les valeurs ou d'autres types de données, en fonction du cas d'utilisation, mais le concept de base est identique. .

Non, une image ne correspond pas simplement à des valeurs RVB comprises entre 0 et 255. Même si vous ignorez les formats de stockage, il existe de nombreuses façons de décrire la couleur. Voici quelques exemples:

• Composants rouge, vert et bleu (RVB)
• Composants cyan, magenta, jaune et noir (CMJN)
• Teinte, saturation et luminosité / valeur (HSL / HSV)
• La quantité de lumière qui a frappé un groupe de capteurs dans une caméra
• La quantité de lumière et sa direction quand il frappe des capteurs (dans une caméra à champ lumineux )

Les deux premiers sont les plus couramment utilisés pour l'affichage sur des moniteurs et pour l'impression, respectivement.

De plus, une image n'est pas seulement des pixels, mais aussi des métadonnées. Il peut s'agir d'éléments tels que la largeur en nombre de pixels, la largeur physique si vous deviez l'imprimer, une vignette ou même l'emplacement géographique de l'appareil photo au moment où l'image a été prise.

Votre prémisse n'est pas fausse: toute image peut être représentée à l'aide d'un tableau de valeurs finies à N dimensions. Personnellement, je généralise l’utilisation de la géométrie discrète au lieu d’une matrice, mais l’essence est la même. Mais c'est le contenu, pas le fichier.

Cependant, les formats de fichier sont différents. Fondamentalement, il existe différentes manières de représenter cette même image, comme le mentionnent les personnes suivantes: bmp, png, jpg, etc. Bien entendu, une fois que vous les avez décodés, deux versions codées sans perte de la même image conduisent aux mêmes matrices.
Considérez-le comme un fichier .txt que vous avez compressé avec zip. Avec l'étrangeté supplémentaire qu'un codage sans perte de données renverrait un texte qui n'est pas identique à l'original, mais très proche, presque comme une version simplifiée du texte.

En reprenant l'analogie avec le texte, supposons que vous ayez le même texte, enregistré au format .txt, .docx, .pdf, etc. Pourquoi tous les fichiers ne sont-ils pas exactement identiques, si le contenu est identique? (Ok, txt n'a pas de formatage, mais les autres ont)

Soit dit en passant, le codage Netpbm est vraiment différent du JPEG .

Autant que je sache, pour les formats RAW et TIFF, la réponse (comme d'autres l'ont déjà dit) est qu'ils n'utilisent pas toujours les mêmes espaces colorimétriques (par exemple, les fichiers RAW peuvent utiliser plus de bits par pixel pour pouvoir stocker des informations de couleurs plus fines). .

Mais pour aller au cœur de votre question, il arrive parfois que des images soient stockées dans des formats différents, mais que chacune d'elles représente exactement le même tableau de nombres.

Les différences de compression entre un fichier PNG et un fichier TIFF en sont un bon exemple.

Les fichiers PNG utilisent un algorithme de compression particulier. Cela signifie qu'une image ne sera pas simplement stockée sous la forme d'une grande liste de nombres pour chaque pixel. Exemple simplifié: il pourrait stocker quelque chose qui dit "dans ce bloc de pixels 10x10, tous les pixels sont en couleur XYZ". Ensuite, au lieu de stocker 100 fois ces informations, il les stocke une fois, ainsi que quelques informations sur la région concernée.

Le problème est alors de récupérer le tableau original de nombres (représentant les couleurs) afin que vous puissiez le montrer ou le modifier, peu importe, vous avez besoin d'un logiciel qui sache interpréter les informations compressées.

Les fichiers PNG utilisent toujours le même algorithme de compression, il est donc facile pour un logiciel de prendre en charge tous les fichiers PNG valides. D'autre part, certaines images ont une structure qui ne se prête pas à l'algorithme de compression de PNG. Par conséquent, certains de vos fichiers PNG risquent d'être assez volumineux.

Les fichiers TIFF, en revanche, prennent en charge de nombreux algorithmes de compression différents. En fait, il peut même stocker différentes parties de l’image compressées différemment. ET il prend en charge les «extensions», vous pouvez donc compresser les images de manière propriétaire. Ainsi, la moitié supérieure de votre image sera peut-être compressée à l'aide d'une méthode similaire à celle de PNG, mais cela ne se compressera pas très bien. La moitié inférieure est donc compressée à l'aide d'une méthode différente.

Les fichiers TIFF sont donc plus flexibles: vous pourrez peut-être stocker le même tableau de nombres en utilisant moins d'octets. Mais le logiciel nécessaire pour décoder l’image sera plus compliqué et risque de ne pas fonctionner de manière uniforme avec chaque fichier TIFF que vous lui envoyez. Par exemple, vous pouvez enregistrer un fichier TIFF dans un logiciel et ne pas pouvoir l’ouvrir à l’aide d’un autre logiciel. fonctionne toujours dans l'original.

Alors vous demandez

Mais je ne demande rien d'autre qu'une image de base RBC à 3 canaux. Tout ce que je sais, c'est que si quelqu'un m'en donne un, j'ai maintenant une série de chiffres. Je n'ai aucune raison de savoir pourquoi un tableau de nombres peut être différent de celui d'un autre tableau de chiffres compris entre 0 et 255.

Afin de vous la remettre, quelqu'un devait savoir comment l'image était stockée et comment la traduire en un tableau de nombres. (Ou peut-être qu'un logiciel fait cette traduction pour vous à votre insu).

Vous pouvez essayer d'enregistrer une image au format PNG puis à nouveau au format TIFF ou GIF et de l'examiner dans un afficheur hexadécimal pour voir comment chacune d'elles représente le même tableau de nombres différemment. Ou lisez les détails sur la façon dont les fichiers PNG et TIFF sont représentés en interne pour vous donner une idée de ce qui doit être intégré au logiciel pour lire différemment des tableaux de chiffres identiques.

Bitmaps

Un bitmap (BMP) est essentiellement ce que vous décrivez, un tableau de nombres représentant les couleurs des pixels. Quelque chose comme

1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1

Compression sans perte

Définissons maintenant un schéma de compression. Dans notre schéma de compression, nous aurons un tableau de paires de nombres. Par exemple

3, 1, 1, 0, 7, 1

La première chose que je veux souligner est que ce schéma de compression représente les mêmes pixels que le premier tableau. Le premier tableau a trois 1 suivis d'un seul 0 puis de sept 1. Et c'est ce que nous représentons ici. Ce format est plus court car il représente plusieurs pixels avec deux nombres. Le format bitmap doit utiliser un nombre pour chaque pixel.

De toute évidence, il s’agit d’une vue quelque peu simplifiée d’une image (par exemple, une seule ligne) et d’un schéma de compression. Mais, espérons-le, cela vous permettra de voir comment un schéma de compression modifie le format d'une image. Voici comment un GIF se rapporte à un BMP. GIF utilise un schéma de compression appelé Lempel-Ziv-Welch au lieu de celui simpliste.

Ce que nous avons décrit ici est un schéma de compression sans perte. Un problème avec les schémas de compression sans perte est que pour certaines entrées, la forme encodée peut être plus longue que l'original. Par exemple pour

1, 0, 1, 0, 1

L'encodage est

1, 1, 1, 0, 1, 1, 1, 0, 1, 1

Eh bien, c'était inutile. Nous avons fait l'entrée deux fois plus longtemps.

Une autre compression sans perte

Considérons maintenant un schéma de compression différent. Dans celui-ci, nous allons représenter l'image en tant que cercles superposés. Pour chaque cercle, nous définirons un centre, un rayon et une couleur.

Notre premier bitmap deviendrait

5, 5, 1, 3, 0, 0

C'est la même longueur que notre première méthode de compression.

Et notre deuxième pourrait être soit

2, 2, 1, 2, 1, 0, 2, 0, 1

Il s’agit de trois cercles centrés sur l’élément central (qui, dans le décompte des ordinateurs, est le numéro 2, car les ordinateurs commencent à compter à 0). Un cercle a un rayon de 2 et une couleur 1. Ensuite, nous ajoutons un cercle de couleur 0 et un rayon 1. Enfin, nous avons un cercle de couleur 1 et de rayon 0. En étapes, ce serait

1, 1, 1, 1, 1
1, 0, 0, 0, 1
1, 0, 1, 0, 1

Ou

2, 2, 1, 1, 0, 0, 3, 0, 0

C'est le même cercle initial mais couvert par deux cercles de points. En étapes, ce serait

1, 1, 1, 1, 1
1, 0, 1, 1, 1
1, 0, 1, 0, 1

Ce sont à la fois une version plus courte que la première version codée mais toujours plus longue que la version originale.

Vous vous demandez peut-être pourquoi je parle de cercles et non de plages. La raison principale est que les cercles sont plus proches de ce que les vraies images bidimensionnelles utilisent.

La compression avec perte

Nous avons également le concept de schémas de compression avec perte. Ces schémas de compression sans perte peuvent être rétablis dans le tableau bitmap d'origine. Les schémas de compression avec perte peuvent ne pas être réversibles.

Considérons une version avec perte de notre méthode des cercles. En cela, nous allons utiliser une règle simple. Nous ne stockerons aucun cercle de rayon inférieur à 1. Ainsi, lors de nos deux derniers encodages, nous aurions plutôt

2, 2, 1, 2, 1, 0

et

2, 2, 1

qui convertis à nouveau en pixels sont

1, 0, 0, 0, 1

et

1, 1, 1, 1, 1

La première version est seulement un élément plus long que l'original. La deuxième version est plus courte. Les deux sont valables, donc l'algorithme est libre de développer les deux et de choisir le plus court.

Nous décrivons les images avec des règles plus restrictives comme étant de qualité inférieure.

Cette représentation des images sous forme de collections superposées de formes circulaires est similaire au fonctionnement du format Joint Photographic Experts Group ou JPEG . Ses formes sont des ellipses plutôt que des cercles, mais l'idée est similaire. Plutôt que notre méthode simpliste, il utilise la transformation en cosinus discrète pour coder les images.

Contrairement au format GIF, le format JPEG est en réalité une manière différente de représenter l’image. GIF est toujours en pixels. Ils sont juste stockés d'une manière différente. JPEG est des formes. Pour afficher un fichier JPEG, nous convertissons ensuite les formes en pixels, car c’est ainsi que fonctionnent les écrans. En théorie, nous pourrions développer un écran qui ne fonctionnerait pas de cette façon. Au lieu de pixels, il pourrait produire des formes afin de mieux correspondre au format JPEG. Bien sûr, cet écran ne serait pas capable d'afficher des bitmaps. Pour afficher un fichier BMP ou GIF, nous devons convertir en JPEG.

Si vous convertissez un fichier GIF standard, par exemple 300 x 300 pixels, le convertissez au format JPEG et réduisez le niveau de qualité, les formes de base qu'il utilise doivent être visibles. De nombreux fichiers JPEG évitent ces artefacts en commençant par une image de résolution beaucoup plus élevée.

Les images JPEG sont bien dimensionnées car ce sont des formes plutôt que des pixels. Ainsi, si vous commencez avec une image 8000x8000, convertissez-la au format JPEG et affichez-la au format 300x300, une grande partie des détails perdus auraient de toute façon été perdus. Si vous avez d'abord converti le bitmap 8000x8000 au format 300x300, puis au format JPEG, les résultats seront souvent de qualité inférieure.

MPEG

Nous avons parlé d'images fixes. Le format MPEG ou Moving Picture Experts Group utilise le même type de compression que le JPEG, mais il fait aussi autre chose. Alors qu’un moyen simple de faire de la vidéo est d’envoyer une séquence d’images fixes, MPEG envoie en fait une image, suivie d’un certain nombre d’images répertoriant les modifications et se terminant par une image de fin. La plupart des images étant similaires à l'image précédente, la liste des modifications est souvent plus petite qu'une seconde image.

La séquence normalement n'est pas si longue, disons cinq images. Mais cela contribue à rendre le flux plus petit qu'il ne le serait autrement.

Des simplifications

J'ai beaucoup ignoré. Mes images ne comportent que deux couleurs (1 bit), pas le 256 d'une image 8 bits et certainement pas les 4 294 967 296 d'une image 32 bits. Même avec des images 8 bits, notez que vous pouvez souvent choisir différentes palettes pour l'image. Donc, deux bitmaps 8 bits avec les mêmes séquences peuvent représenter des images qui semblent différentes (même forme mais couleurs différentes).

Mes images sont des lignes simples et non pas en deux dimensions. La plupart des images auront une taille de ligne spécifique stockée, ce qui rendra les tableaux bidimensionnels.

Je n'ai pas essayé de représenter les encodages réels du tout. Ils sont beaucoup plus complexes que les simples que j'ai utilisés. Je l'ai fait parce que je voulais pouvoir décrire les encodages de ce post. Je ne suis pas convaincu de pouvoir expliquer Lempel-Ziv encore moins le raffinement plus complexe de Lempel-Ziv-Welch en une seule réponse. Et je ne comprends pas suffisamment bien la transformation de Fourier pour pouvoir les expliquer en détail.

Il s'agit en réalité d'une version simplifiée de la gestion des images. Cependant, j’estime qu’à des fins didactiques, il est plus facile à comprendre que la réalité plus complexe tout en touchant les points essentiels.

Disons que c'était vrai, que chaque pixel était constitué de trois nombres (rouge, vert et bleu), compris entre 0 et 255. D'autres répondants ont commencé par remettre en cause (correctement) cette hypothèse, mais pour simplifier, disons simplement que c'est la vérité.

Je me souviens (mais malheureusement, je ne trouve pas en ligne) une caricature d’un manuel de linguistique: deux anciens sculpteurs sur pierre égyptiens sont épuisés au bas d’un immense mur sur lequel ils ont sculpté un très grand nombre de personnages en marche. L'un dit à l'autre: "Il doit sûrement exister un moyen plus facile d'écrire:" Le pharaon avait 100 000 soldats? "". Gardez cette idée en tête.

Supposons maintenant que la première ligne de votre image contienne 1800 pixels noirs. Comment cela serait-il représenté?

0 0 0    0 0 0     0 0 0   ....

Alors, combien d'espace de stockage cela aurait-il besoin? Chaque valeur est un octet. Trois octets par pixel, 1800 pixels dans la ligne, donc déjà 5400 octets par ligne. Ainsi, une image de 1800 x 1200 doit en prendre 1200 fois, soit plus de 6 mégaoctets. Alors maintenant, allons faire une recherche d'image Google et télécharger quelques images 1800x1200 - disons, une .pngimage et une .jpgimage. Regardez la taille du fichier: est-ce 6 Mo? Pas du tout, c'est généralement beaucoup plus petit que ça. Et c'est une chose souhaitable, bien sûr, tout cet espace économisé et un temps de téléchargement plus court ....

Alors que se passe-t-il? La clé est que, même si vous avez autant de nombres à stocker, il existe différentes façons de représenterces chiffres dans le fichier. Il y a un exemple d'une représentation plus efficace ici dans ma réponse, il y a deux paragraphes. J'ai écrit les mots "1800 pixels noirs". Cela fait 17 caractères et ne nécessite donc pas plus de 17 octets, mais décrit parfaitement les mêmes informations pour lesquelles nous pensions avoir besoin de 5 400 octets. Et vous pourriez certainement faire mieux que 17 octets (et économiser beaucoup d’efforts dans la mise en œuvre de l’encodage / décodage) si vous n’utilisiez pas l’anglais pour encoder cette information, mais plutôt un langage plus spécifique. Nous avons donc déjà proposé plus d’un format de compression d’image: un format utilisant des mots anglais et un format plus efficace. Vous voyez où ça va?

OK, vous dites que cela fonctionne si un grand nombre de pixels adjacents ont la même couleur. Mais s'ils ne le font pas? Bien sûr, cela dépend du contenu de l'image: plus il y a de redondance , plus il est facile de compresser les informations. La redondance signifie que certaines parties de l'image peuvent être prédites assez bien si vous connaissez déjà d'autres parties. Compression signifie seulement écrire le strict minimum nécessaire pour reconstruire les informations. Toutes les images possibles n’ont pas de redondance, mais toute image réelle qui a une signification pour l’œil humain et le cerveau, bien qu’elle soit plus complexe que mon exemple en noir pur, aura quand même tendance à avoir beaucoup de redondance. Et il y a beaucoup de façons différentes de compresser. Certaines méthodes de compression sont sans perte, ce qui signifie que les informations peuvent être reconstruites pour être mathématiquement identiques à l’original, comme dans mon exemple de rangée de pixels noire. La plupart des .pngfichiers utilisent une méthode de compression sans perte. Certaines méthodes sont à perte : la reconstruction n’est pas parfaite, mais les erreurs sont cachées de telle manière que l’œil et le cerveau humains ne les remarquent guère. La plupart des .jpgfichiers sont à perte.

La manière dont vous reconnaissez les schémas de redondance complexes et comment en rédigez des descriptions compressées efficaces est très mathématique et non triviale. C'est pourquoi il y a de la place pour autant de formats différents, correspondant à différentes stratégies de compression. Mais j'espère que vous obtenez le principe.

Un couple de commentateurs ci-dessus ont fait des suppositions raisonnables quant à l'origine de votre idée fausse. Dans votre question, vous semblez penser que la compression modifie légèrement les valeurs des pixels (et que les méthodes de compression avec pertes le font par endroits, mais uniquement en tant qu'effet secondaire indésirable) sans modifier la présentation de l'information. Lorsque vous ouvrez le fichier et regardez le contenu de l'image (par exemple, un tableau de nombres dans Matlab ou une image à l'écran dans Photoshop), vous ne regardez pas le contenu du fichier compressé, mais plutôt la reconstruction., qui a la même disposition que l’original (ce ne serait pas une reconstruction si elle ne reproduisait pas la disposition correctement). La procédure d'ouverture de fichier a décompressé les informations du fichier en une représentation complète non compressée en mémoire. Si vous comparez deux reconstructions non compressées , il est en effet impossible de distinguer les deux formats d'image d'origine (sauf les erreurs de reconstruction, le cas échéant).

Oui, mais la façon dont vous obtenez ces 1 et ces 0 est très différente.

Je vais donner un exemple, mais c'est faux et c'est supposer illustrer plus qu'être précis. Gardez à l'esprit que toutes les images numériques sont représentées en binaire à un certain niveau.

Pour compliquer les choses, il existe différents canaux. CMJN, RVB, N & B, pour n’en nommer que quelques-uns. Nous n'allons pas entrer dans cela. Il existe également différentes étapes, telles que la capture, le stockage et l'affichage. Nous allons y aller, bien que l'exemple soit censé démontrer qu'il n'est pas exact. Si vous voulez des exemples précis, vous devrez consulter une tonne de documents techniques.

Dans notre échantillon, nous allons donc regarder une image en noir et blanc.

00067000
00067000
00567800
04056090
40056009

Les chiffres représentent la force du "Noir". Voici comment l'appareil photo a capturé l'image. C'est un appareil photo correct, donc c'est aussi la façon dont il stocke l'image.

Maintenant, il stocke l'image sur un ordinateur, mais prend beaucoup de place, nous allons donc la compresser. En plus de bien mélanger les choses, nous savons également que la plupart des gens ne peuvent pas détecter une différence d'un niveau de noir, nous allons donc en aplanir certains.

302730
302730
204820
*04056090
1420262019

Voilà comment nous stockons l'image sur le disque. Cela prend moins de place et nous permet de produire une grande partie de l'image originale.

Maintenant, disons que nous voulons l’imprimer sur une imprimante. L’imprimante n’imprimant qu’un seul niveau de noir, c’est pourquoi un ordinateur convertit l’image compressée stockée en parole de l’imprimante.

00011000
00011000
00111100
01011010
10011001

Ceci affiche une image d'aspect raisonnable, mais vous pouvez voir, même dans l'exemple, un manque de qualité extrême. Mais bon, c'est la faute de l'imprimante.

Enfin, vous allez imprimer l’image sur une bonne imprimante avec 10 niveaux de noir. Identique à votre appareil photo. Donc, vous utilisez l'image stockée et compressée.

00077000
00077000
00888800
04056090
40066009

Comme vous pouvez le voir, l'image est "meilleure" mais a été légèrement modifiée par rapport à l'original.

A tout moment, vous avez raison de dire que ce n'est que la force d'un canal. Et à part l'image compressée, qui doit être décompressée de toute façon, elle reste fidèle à cela.

Cependant, le format compressé perd beaucoup d'informations. Cette information est-elle importante? Eh bien, cela dépend de l'artiste et du public. Il existe plusieurs compromis entre gain de place, temps de traitement, qualité de l'image finale / stockée et besoin. Je numérise la plupart de mes documents en noir et blanc parce que c'est tout ce dont j'ai besoin. Cependant, les photos de mon mariage sont au format RAW HUGE parce que je ne sais jamais quand je veux une grande réimpression de celles-ci. Cela dit, lorsque je les transfère (photos) sur un cadre photo numérique, je les convertis au format JPEG pour économiser de l'espace. Différents canaux, différents filtres et différentes méthodes de compression constituent une série de compromis. C'est comme une version numérique du triangle des imprimantes.

Je vais donner quelques informations supplémentaires, car je me suis concentré sur la détection d’images et le codage / compression, bien que la plupart des images soient en mouvement.

Dans sa forme de base, une image (TOUTE image) affichée sur un écran particulier n’est en fait qu’un tableau de nombres identique. Ces nombres peuvent tous être 0-255 ou 0-65535 ou 0-que-ce-32-bits-est-je-oublié-aller-google-it.

MAIS il y a tellement de façons de STOCKER et de TRANSPORTER cette information, beaucoup d’entre elles sont simplement le produit de technologies perdues dans la nuit des temps.

En outre, un détail que je n’ai jamais vu parmi les autres pédants cités ici est que les données de capteur d’image véritablement RAW provenant d’un appareil photo numérique peuvent très bien être RGrGbB dans un motif de Bayer ou quelque chose qui doit être traité au moins un petit peu aucun sens pour le globe oculaire humain Mk.1. Il est fort probable que vous n'obtenez jamais cela, même dans un format RAW enregistré par votre reflex numérique, car il ne sert à rien tant que vous ne le convertissez pas en une belle grille de pixels RVB ou YUV, d'une profondeur de 8, 16, 32 ou onze milliards de bits.

Les éléments sur lesquels j'ai travaillé utilisent YUV en interne pour une raison quelconque, je suppose que les codecs les traitent plus facilement, car les humains perçoivent la luminosité avec beaucoup plus de sensibilité que de couleur.

Pour une lecture légère au coucher, voir la section "Format d'image": http://focus.ti.com/lit/ug/sprufg8b/sprufg8b.pdf

Quoi qu'il en soit ... revenons à votre question initiale sur la différence entre les fichiers image non compressés tels que TIFF / RAW / IFF / PNG.

Celles-ci existent généralement parce qu’il ya de nombreuses lunes, chaque fabricant d’ordinateur / système d’exploitation / imprimante a défini ses propres exigences légèrement différentes en ce qui concerne le stockage / l’envoi d’images.

Ainsi, RAW tel que discuté par d’autres dans ce fil de discussion est un terme générique qui désigne différentes choses enregistrées par différents appareils photo numériques, en utilisant la charge de données que le fabricant de la caméra a jugée importante, en fonction des fonctionnalités que leur appareil photo possède ou pourrait avoir à l’avenir. Ainsi, bien que le bit de données d'image principal puisse être très similaire, le "packaging" qui le décrit décrit l'image et tous les paramètres de l'appareil photo, etc. de sorte qu'un fichier ne serait pas compris par un fabricant différent.

C’est généralement pour qu’ils (ou, plus probablement, les photographes professionnels) utilisent leur logiciel exclusif (et parfois coûteux) pour traiter ces images de qualité supérieure, sans quoi vous pourriez commencer à utiliser le logiciel coûteux d’autres personnes. De plus, Adobe Photoshop pourrait peut-être prendre en charge leur format. Ils pourraient donc facturer cette information à Adobe $$$$; ainsi, un plus grand nombre de photographes professionnels achèteront du PS et achèteront peut-être cet appareil photo, car PS le prend en charge maintenant. Confortable!

RAW stocke également des informations sur la manière de transformer ce paquet de données particulier en une image visible par l’homme. Mettez simplement toutes les modifications que vous devez apporter aux données pour que l’image apparaisse "correctement".

Le format TIFF était l'un des premiers formats d'image, utilisé entre autres pour envoyer des données graphiques aux imprimantes (lorsque les imprimantes prenant en charge les graphiques ont commencé à devenir abordables). C'était assez simple, donc facile à traiter sur le petit microprocesseur bon marché à l'intérieur de l'imprimante.

IFF (ouais, c'est une chose) était un format similaire utilisé sur les ordinateurs Amiga, je crois qu'ils ont inventé ou l'un des paquets de peinture populaires. Mais je l’utilise ici à titre d’exemple car, bien qu’il stocke des données d’image bitmap comme les autres, il supportait les données non compressées ou RLE, des profondeurs de bits variables de 1 bit mono à 8 bits 256 couleurs (mais avec une palette RVB de 3x8 bits à choisir pour chacune des couleurs), ainsi que des modes spéciaux appelés Demi-teintes et Hold-And-Modify permettant de disposer de beaucoup plus de couleurs que d’autres machines de l’époque ne pourraient en gérer. Oh, et comme il supportait également l'animation (comme le format GIF), un fichier IFF pouvait stocker un nombre illimité d'images, avec des délais variables, et chaque image pouvait avoir sa propre palette. Ainsi, IFF inclurait des données supplémentaires pour gérer tout cela par rapport à, par exemple, un fichier TIFF.

Le format PNG est un autre format d'image sans perte, stockant à nouveau des données bitmap, mais prenant en charge certaines fonctionnalités géniales telles qu'un canal alpha à 8 bits pour la transparence variable d'une image à l'autre (utile sur les pages Web), de sorte que la "charge utile" des données d'image peut être très similaire mais l'encapsuleur qui l'entoure est différent et la charge utile peut contenir des données RGBA plutôt que des données RVB par pixel.

Donc, cela correspond à 4 formats de fichier image décrits - vous pouvez stocker un exemple d'image HD en couleur d'un chat dans n'importe lequel des 4 et il semblerait identique, chaque pixel de votre écran aurait la valeur EXACT SAME et NO différence de qualité entre les 4 ... mais les 4 fichiers seraient probablement différents en taille, en présentation et plus faciles ou plus difficiles à charger et à traiter par les logiciels.

J'espère que ça t'as aidé!

Je pensais juste que je donnerais ici les informations qui auraient dû figurer dans la toute première réponse à cette question.

Les pixels d'une image ne sont pas stockés dans un octet - sauf si l'image est monochrome, c'est-à-dire en noir et blanc uniquement.

Si vous avez une image truecolor, chaque pixel est représenté par 16 bits ou 2 octets - sous la forme d'une valeur. Si vous avez une image 32 bits, chaque pixel nécessite alors 32 bits ou 4 octets, là encore sous forme de valeur unique.

Il est intéressant de noter que les fichiers image et son ainsi que tous les autres types de données d’un ordinateur se résument à des bits de 1 et de 0. Ce n'est qu'en les interprétant dans les morceaux de taille correcte que la signification en est extraite.

Par exemple, une image, un document Word et un fichier MP3 ont tous le même contenu de données de base (un tas d'octets), et n'importe lequel d'entre eux peut être interprété comme l'un des autres types - vous pouvez interpréter un document Word comme un son. fichier et vous entendrez quelque chose, mais ce ne serait pas de la musique. Vous pouvez certainement interpréter un fichier son comme une image, ce qui afficherait quelque chose, mais ce ne serait pas une image cohérente.

Donc, pour résumer, un ordinateur ne connaît que les bits - un bit vaut 1 ou 0. Toutes les images, tous les sons, documents, films, vidéos, enregistrements, jeux, appels téléphoniques, messages texte et tout ce qui est étiqueté comme numérique ont exactement la même chose. contenu - un groupe de 1 et de 0. Les 1 et les 0 deviennent des images, des sons, des documents et tout le reste, car le code qui les lit sait lire ces bits par groupes et les traiter en conséquence.

C'est pourquoi nous avons des choses comme les images 16 bits et 32 ​​bits et les fichiers audio 16 bits et 24 bits. Plus vous utilisez de bits pour un pixel ou un échantillon sonore, plus vous pouvez être expressif: 16 bits ne peuvent définir que 64 000 couleurs uniques, mais 32 bits peuvent définir plus de 4 millions de couleurs uniques. Une image monochrome utilise 1 bit par pixel - elle est activée ou désactivée.

Avec les fichiers audio, plus vous utilisez de bits par échantillon, plus l'enregistrement peut être détaillé et nuancé.

Je n'ai pas lu le fil entier, mais il me semble que beaucoup de gens oublient les formats d'image vectorisés. Ce ne sont pas des tableaux de pixels, car le concept de pixel n'existe même pas dans un tel format. Il appartient au moteur de rendu de déterminer comment produire l'image sur un écran ou tout autre support.

Même sans mentionner les domaines de couleur, la compression, la taille des bits et le format de canal, il existe un ensemble de formats de fichiers totalement différents des pixels. Et pourtant, les formats vectoriels sont aussi beaucoup "meilleurs" pour représenter certains types d'images, généralement produites par un ordinateur et non par une caméra.

Cette question a reçu une réponse assez détaillée auparavant. Cependant, malgré les nombreuses théories présentées dans les réponses, j’ai le sentiment que certains sujets de base, généralement liés à la programmation informatique, nécessitent des éclaircissements supplémentaires. Je dois dire que je suis un ingénieur en logiciel. Après avoir lu la question, j’ai réalisé qu’il y avait une incompréhension totale des types de données de programmation de base qui ont généré cette question.

La première question est la suivante:

De plus, d’un point de vue numérique, en quoi une image 16 bits est-elle différente des images 32 bits? Encore une fois, une image est juste un tableau avec des valeurs entières comprises entre 0 et 255.

Tel que présenté précédemment: non ce n'est pas. Une image n'est pas simplement un tableau de valeurs entières comprises entre 0 et 255. En réalité, il peut s'agir d'un tableau unique ou multidimensionnel de 0 à 65535 valeurs, d'un tableau de 0 à 4294967295 ou même d'un tableau de bits (un bit peut contenir 0 ou 1 valeurs, c'est tout) qui est converti par le logiciel en mesure de lire les fichiers image en nombres entiers selon diverses règles de codage.

Pour mieux comprendre cela, comme indiqué précédemment, je pense qu'une discussion sur les types de données de programmation de base est nécessaire. Je vais essayer de les expliquer le plus simplement possible pour que tout le monde comprenne les problèmes liés au stockage de valeurs entières dans des fichiers informatiques.

En programmation informatique, nous utilisons certains types de données primitifs de base pour écrire des valeurs dans des fichiers, les lire à partir de fichiers dans la mémoire de l'ordinateur, manipuler ces valeurs à l'aide de divers types de données de langages de programmation spécifiques et éventuellement les sauvegarder dans des fichiers. Les entiers en programmation informatique ne sont pas simplement des entiers. Il existe toutes sortes d’entiers, cela dépend du langage de programmation que nous utilisons et de la quantité de mémoire dont nous avons besoin pour chacun. Généralement, dans la plupart des langages de programmation, nous avons les types de données suivants (et des méthodes pour les manipuler):

• BIT - maintien 0 ou 1
• UINT8 - entier non signé de 8 bits - ils peuvent contenir des valeurs comprises entre [0 et 255].
• INT8 - entier signé 8 bits - ils peuvent contenir des valeurs comprises entre [-126 et 127] intervalles.
• UINT16 - Entier non signé de 16 bits - ils peuvent contenir des valeurs comprises entre [0 et 65535] d'intervalle.
• INT16 - Entier non signé 16 bits - ils peuvent contenir des valeurs comprises entre [−32768 et 32767].
• UINT32 - entier non signé 32 bits - ils peuvent contenir des valeurs comprises entre [0 et 4294967295].
• INT32 - Entier non signé 32 bits - ils peuvent contenir des valeurs comprises entre [−2147483648 et 2147483647].
• OU une combinaison de tous ces types de données dans un format plus complexe. Par exemple, un UINT16 (16 BIT) contenant 3 valeurs différentes, les 4 premiers BIT contenant des valeurs comprises entre 0 et 127, le prochain BIT contenant 0 ou 1, etc.

De plus, les programmeurs doivent faire face à quelque chose lorsqu'ils lisent ou écrivent un type de données entier à partir de fichiers. L'endianesse.Endianness fait référence à l'ordre séquentiel dans lequel les octets (UINT8 de notre table) sont organisés en valeurs numériques plus grandes lorsqu'ils sont stockés en mémoire ou dans des fichiers. La finalité présente un intérêt en informatique car deux formats incompatibles et conflictuels sont couramment utilisés: les valeurs peuvent être représentées en format big-endian ou little-endian, selon que les bits, les octets ou d’autres composants sont classés dans le gros bit) ou la petite extrémité (bit le moins significatif). En termes simples, vous pouvez stocker une valeur comme celle-ci 0000000011011111 ou ... comme celle-ci 1101111100000000 en fonction de la commande finale que vous avez choisie. Et vous êtes libre de choisir l'ordre de votre choix. Il n'y a pas de règles autres que celles que vous définissez lorsque vous concevez un format de fichier image.

Veuillez noter que, dans la programmation informatique, les entiers utilisent plus ou moins d'espace, cela dépend de la valeur. Comme vous avez besoin de plus de papier pour écrire 255255255, vous avez besoin de plus de BIT pour écrire une valeur plus grande. Ensuite, lorsque vous souhaitez lire la valeur, vous devez connaître exactement les règles que vous avez créées lors de sa rédaction. Sinon, il vous est impossible de comprendre comment lire uniquement un tableau contenant des valeurs entières comprises entre 0 et 255, car vous ne savez tout simplement pas où ces nombres sont stockés et comment ces chiffres sont stockés, compte tenu de vos choix multiples (BIT, UINT8). , UINT16, UINT32 ou une combinaison de tous ces types de données informatiques). Et n'oubliez pas, Endianness. Si vous ne savez pas que les données ont été écrites en utilisant l'ordre big-endian ou little-endian, vous ne pouvez pas lire la valeur correcte.

A cause de cela, les images ne sont JAMAIS un simple tableau avec des valeurs entières comprises entre 0 et 255. Certaines d'entre elles sont des tableaux de UINT16 (images 16 bits), d'autres des tableaux de UINT32 (images 32 bits) ou d'autres sont des tableaux de UINT8 (images 8 bits). Certains programmeurs informatiques très créatifs peuvent même utiliser des types signés utilisant des tableaux de INT8, ce qui signifie un tableau de valeurs compris entre -126 et 127.

En fait, lorsque vous lisez un fichier image, l'une des premières données que vous rencontrez est généralement des bits qui représentent la largeur et la hauteur de l'image. Et ce ne sont pas que quelques valeurs 0-255. Ce sont aussi des types de données choisis par le programmeur. Certains programmeurs penseront que 16 bits sont suffisants pour stocker une largeur d'image maximale de 65 535 pixels, car ils conçoivent un format d'image utilisé dans un jeu pour conserver certaines images de petits boutons. Un autre programmeur peut utiliser ici une valeur de 32 bits vous permettant de stocker des images d’une largeur et d’une hauteur maximales de 4294967295. Certains programmeurs fous de la NASA peuvent même utiliser une résolution de 64 bits pour stocker une énorme photo de la galaxie jusqu’à 18446744073709551615 pixels.Si vous ne connaissez pas les règles, vous ne pouvez pas lire ces "valeurs" comme vous les appelez. Parce que vous ne savez pas où ils commencent dans le fichier image et où ils finissent. Donc, vous vous retrouvez avec un tas de BIT dont vous ne comprenez rien.

C'est pourquoi l'univers regorge de nombreux formats d'images. Parce qu'il n'y a pas de solution standard pour écrire des valeurs entières dans un fichier. C’est le choix du programmeur qui repose entièrement sur de nombreux facteurs, tels que l’endurance de la machine sur laquelle vous travaillez, le langage de programmation que vous utilisez pour concevoir l’implémentation du format de fichier original et de nombreux autres éléments, tels que le but du format d’image (comme indiqué clairement auparavant). autres réponses).

Un format de fichier simple et pratique d’une image en noir et blanc qui ne contient qu’une seule valeur 166 pour représenter une image de 4x2 pixels:

L'image (1 - pixel noir, 0 - pixel blanc):

1010 
0110

Ce format de fichier utilise 1 BIT par PIXEL stocké sous la forme d’une valeur unique SINGLE de 8 bits 166 (10100110). C'est tout. Aucun tableau de 0 à 255 valeurs n'est utilisé mais 8 valeurs 0 ou 1 différentes stockées en tant que valeur 166.

Si vous avez utilisé un tableau de 0 à 255 valeurs pour chaque pixel * 3 fois pour RVB, vous obtiendrez une image 24 fois plus grande. Ce format de fichier vient d’enregistrer 24 fois l’espace disque nécessaire pour enregistrer une image de ce type ou 24 fois moins de mémoire d'ordinateur pour lire et conserver cette image dans la RAM de l'ordinateur lorsque vous utilisez cette image par exemple dans votre moteur de jeu 3D haute performance pour dessinez quelque chose sur l'écran (texturer des milliers de particules de poussière en suspension pourrait être un bon candidat :)).