Je dois dire que je ne sais pas grand chose sur la façon dont les formats de fichiers fonctionnent. Ma question est de savoir que j'ai un fichier JPEG à 200 px de 200 px, comment calculer la taille maximale que le fichier pourrait être en termes de mégaoctets / octets?
Je pense que le raisonnement qui a conduit à la question aidera quelqu'un à me répondre. J'ai une applet Java, les images de téléchargent les gens qui tirent avec mon serveur. J'ai besoin de savoir quelle taille max que ce fichier peut éventuellement atteindre. Il va toujours être 200x200.
Il semble que ça sonne, mais y a-t-il des couleurs qui prennent plus de taille d'octets puis d'autres et si oui, quel est le plus cher?
5 Réponses :
Je ne suis pas sûr que ce serait aussi utile, mais je crois que le maximum absolu pourrait être:
largeur * hauteur * 4 (taille de INT) Vous devez probablement également ajouter un kilobyte pour les métadonnées ... mais je doute que l'image atteindrait jamais que (comme c'est le tout Point de compression JPEG)
En règle générale, aucun JPEG ne sera plus grand qu'un bitmap taille 32 bits équivalent. Un bitmap 32 bits aura 4 octets par pixel dans l'image, ainsi de multiplier les dimensions ensemble (200x200 = 40000), puis multipliez que 4 octets (40000x4 = 160000), et vous aurez une limite supérieure en octets - pour Votre exemple, 160000 octets est d'environ 156 Ko.
Existe-t-il une règle pour les limites minimales du fichier?
C'est un peu trop gros. La taille d'un pixel est de 12 bits, pas 32. Au minimum, un JPEG serait un kilobyte ou plus. Essayez d'ouvrir de la peinture et enregistrez une image vide comme JPEG.
Je n'ai jamais déclaré qu'un JPEG utilise 32 bits pour un pixel. J'ai déclaré qu'un bitmap 32 bits (le type le plus courant) utilise 32 bits pour un pixel - et que les JPEG seront toujours plus petites que les bitmaps équivalents (car les bitmaps sont au sujet du format le moins efficace).
La taille maximale possible Une JPEG peut être quelque part autour de JPEG convertit les images vers un autre espace de couleur (YCBCR) qui utilise moins de bits (12 à être exact) pour représenter une seule couleur. Réalisme de manière réaliste, l'image sera beaucoup plus petite que la formule ci-dessus suggérerait.
Si nous utilisons uniquement une compression sans perte, la taille du fichier serait un peu plus petite. Même alors, personne ne le fait que votre image devrait être bien inférieure à la limite fixée par cette formule.
En bref: 60 kb hauts, mais probablement moins. largeur * hauteur * 12 bits .
La taille finale en octets est basée sur les paramètres de qualité de codage utilisés et le nombre de pixels. Dans votre cas, toutes les images doivent avoir la même taille puisque vous faites le codage et que votre utilisateur semble obligé de dessiner sur une zone 200x200.
Selon Wikipedia cependant, le maximum est d'environ 9 bits par pixel.
SO 200 * 200 * 9 = 360000 bits = 45 kb
http://fr.wikipedia.org/wiki/jpeg#effects_of_jpeg_compression
Il existe de nombreuses façons de créer un fichier JPEG / JFIF pathologique 'inhabituellement grand.
à l'extrême extrême du spectre, il n'y a pas de limite à la taille, car la norme ne limite pas certains types de types de marqueur apparaissant plus d'une fois - par exemple un fichier JFIF rempli de marqueurs de GB de DRI (intervalle de redémarrage), puis un MCU de 8x8 pixels à la fin est techniquement valide. P>
Si nous nous limitons à l'utilisation du marqueur «normal», nous trouvons une majuscule. Limite comme suit: p>
du fond - p>
JPEG code pixels en tant que MCU (groupe) de 8x8 blocs de pixels (blocs DCT), un bloc DCT pour chaque composant (Y, CB, CR). P> LI>
Pour obtenir la meilleure compression (et la plus petite taille), un schéma de sous-échantillonnage de Chroma 4: 2: 0 est utilisé lorsque 75% des informations de chroma sont omises. Pour obtenir la meilleure qualité (et la plus grande taille), le fichier est 2 / 3ème chroma, 1 / 3ème info de luminance. P> li>
Les symboles Huffman Bitstream sont utilisés pour encoder des composants DCT, dont 65 par bloc de DCT (64 AC + 1 DC). P> LI>
Les symboles Huffman peuvent aller de 1 à 16 bits et sont choisis par le codeur pour être aussi petit que possible; Cependant, le choix de la longueur du symbole peut être spécifié. P> li>
Le codage final du Bitstream Huffman doit être fait afin que les marqueurs puissent être identifiés de manière unique. I.E, toute usure d'un octet de 0xFF dans la sortie doit être remplacée par deux octets - 0xFF, 0x00. P> LI> ol>
Utiliser toutes ces informations, nous pouvons construire un fichier JPEG pathologique, mais valide, que libjpeg (la mise en œuvre du décodeur JPEG la plus courant) est heureux de décoder. P>
Premièrement, nous avons besoin du plus long Symboles de Huffman possibles. À la première pensée, définir un symbole de Huffman de longueur maximal (16 bits) de tous les 1, utiliserait la plupart des espaces. Toutefois, libjpeg refuse de gérer un symbole de Huffman qui est tous 1, cela ne semble pas être exclu par la norme - comme il est toujours un symbole unique que la taille est déjà connu pour être 16 bits, contrairement à d'autres symboles de longueur variable, et bien certains décodeurs peuvent le gérer (Jpegsnoop). P>
Nous définissons donc une table de Huffman qui définit la dernière Deux symboles comme suit: P>
0xff,0x00,0xfe,0xff,0x00,0xff,0x00 0xff,0x00,0xfd,0xff,0x00,0xff,0x00 0xff,0x00,0xfb,0xff,0x00,0xff,0x00 0xff,0x00,0xf7,0xff,0x00,0xff,0x00 0xff,0x00,0xef,0xff,0x00,0xff,0x00 0xff,0x00,0xdf,0xff,0x00,0xff,0x00 0xff,0x00,0xbf,0xff,0x00,0xff,0x00 0xff,0x00,0x7f,0xff,0x00
+1 Great Petite courir dans un pire des cas Synthetic JPEG MCU. Je doute toutefois que vous puissiez obtenir un compresseur JPEG (réaliste) pour produire tous ces HuffManstreams de tant de 1. Existe-t-il peut-être un moyen de trouver une limite supérieure plus étroite des flux de Huffman les plus stricts, si nous essayons de construire un pire des cas bitmap, que nous nourrissons ensuite dans Huffman Encoder Thingy?
Pour commencer, je pense Donc, ce serait génial si nous pouvions avoir un peu plus près d'une limite supérieure réaliste.
à partir d'une réponse sur www.impulseadventure.com/photo/optimized-jpeg.html: la restriction pour tous-1 provient de l'annexe C de la norme UIT T.81: les codes doivent être générés de manière à ce que le code All-1-Bits Le mot de n'importe quelle longueur est réservé comme préfixe pour les mots de code plus longs
Pour répondre à la deuxième partie de votre question, chaque couleur prend le même espace pour représenter dans JPEG: 12 bits avant que toute compression de perte ne soit effectuée.
Aussi que diriez-vous du format de fichier TIFF?
TIFF est différent. Il existe plusieurs schémas de compression disponibles, sans parler de largeur de bits variable. En cas de perte sans perte, mais ils sont généralement 32 bits par pixel, ainsi légèrement plus grand qu'un bitmap en raison de données d'en-tête supplémentaires.