14

I have to say the I don't know much about how file formats work. My question is say I have a jpeg file that is 200 px by 200 px, how can one calculate what the maximum size that file could be in terms of megabytes/bytes?

I think that the reasoning that led to the question will help some one answer me. I have a Java Applet the uploads Images that people draw with it to my server. I need to know what the max size that this file can conceivably reach. It is always going to be 200x200.

It sounds dumb but are there colors that take more byte size then others and if so what is the most expensive one?

Tegra Detra
  • 24,551
  • 17
  • 53
  • 78
  • To answer the second part of your question, every color takes the same space to represent in JPEG: 12 bits before any lossy compression is done. – Mike Bailey Apr 29 '10 at 04:05
  • Also how about the Tiff file format? – Tegra Detra Apr 29 '10 at 04:08
  • Tiff is different. There are multiple compression schemes available, not to mention variable bit width. In the case of lossless though they're usually 32-bits per pixel, so slightly bigger than a bitmap due to extra header data. – Mike Bailey Apr 29 '10 at 04:13

5 Answers5

28

There are many ways to make a 'pathological' JPEG/JFIF file that is unusually large.

At the extreme end of the spectrum there is no limit to the size, since the standard doesn't limit some types of marker appearing more than once - e.g. a JFIF file full of many GB of DRI (define restart interval) markers and then an 8x8 pixel MCU at the end is technically valid.

If we restrict ourselves to 'normal' marker usage then we find an upper limit as follows :

Some background -

  1. JPEG encodes pixels as a MCU (group) of 8x8 pixel blocks (DCT blocks), one DCT block for each component (Y, Cb, Cr).

  2. To get best compression (and smallest size), a 4:2:0 chroma subsampling scheme is used where 75% of the chroma information is omitted. To get best quality (and largest size), the file is 2/3rd's chroma, 1/3rd luminance info.

  3. Huffman bitstream symbols are used to encode DCT components, of which there are up to 65 per DCT block (64 AC + 1 DC).

  4. Huffman symbols can range from 1 to 16 bits and are chosen by the encoder to be as small as possible; However, the choice of symbol length can be specified.

  5. Final encoding of the huffman bitstream must be done so that markers can be uniquely identified. I.e, any occurance of a 0xff byte in the output must be replaced by two bytes - 0xff,0x00.

Using all this information we can construct a pathological, but valid, JPEG file which libjpeg (the most common JPEG decoder implementation) is happy to decode.

First, we need the longest possible huffman symbols. At first thought, defining a maximal-length huffman symbol (16 bits) of all 1's, would use most space, however libjpeg refuses to handle a Huffman symbol which is all 1's, this doesn't seem to be excluded by the standard - as it still a unique symbol as the size is already known to be 16 bits unlike other variable-length symbols, and indeed some decoders can handle it (JPEGSnoop).

So we define a huffman table which sets the last two symbols as follows :

11111111_1111110  -> (0,0) (EOB - end of block value)
11111111_11111110 -> (0,15)

Such a huffman table would appear in a JPEG file as :

0xFF, 0xC4 ; DHT - define huffman table
0x00, 35 ; length
0x00 ; DC 0
1,1,1,1,1,1,1,1,1,1, 1, 1, 1, 1, 1, 1 ; histogram
1,2,3,4,5,6,7,8,9,10,11,12,13,14,0,15 ; symbols

Now to encode a maximal-length DCT block :

1 x DC of 31 bits  ( 11111111 11111110 11111111 1111111 )
64 x AC of 31 bits ( 11111111 11111110 11111111 1111111 )
= 2015 bits

Since an MCU will be 3 DCT blocks (one for each component), the MCU size will be 6045 bits.

Most of these bytes will be 0xff, which are replaced by 0xff,0x00 in the output stream, as per the standard, in order to differentiate the bitstream from valid markers.

Perform this mapping and a complete DCT is represented by 8 repeats of the following byte pattern :

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

which totals 8*54 = 432 bytes

Adding all this up, we have : 3 components * (432 bytes per component) = 1296 bytes per 8x8 pixels

a header of 339 bytes is required for the SOI/DHT/DQT/SOS segments to setup the image properties and huffman tables, a 2 byte EOI marker is required to end the image.

Since a 200x200 image would be 25x25 MCU's, we have a final size of :

339 + (25 * 25 * 1296) + 2 = 810341 bytes

which works out as a little over 20.25 bytes per pixel, over 6 times larger than an uncompressed BMP/TGA.

matja
  • 4,014
  • 3
  • 23
  • 29
  • +1 Great little run through a worst case synthetic jpeg MCU. I do however doubt that you can get any (realistic) jpeg compressor to actually produce all these huffmanstreams of so many 1's. Is there maybe a way to work out a tighter upper limit of the worst case huffman streams, if we attempt to actually construct a worst case bitmap, that we then feed into huffman encoder thingy? – Zuu Dec 29 '13 at 16:14
  • For starters, I _think_ it would be safe to assume that you cannot construct a bitmap that libjpeg would compress to a size larger than the source bitmap (ignoring headers, and dims being multiples of 16). So it would be great if we could get a little closer to a realistic upper bound. – Zuu Dec 29 '13 at 16:20
  • from a response on www.impulseadventure.com/photo/optimized-jpeg.html: The restriction for all-1s comes from Annex C in the ITU T.81 standard: the codes shall be generated such that the all-1-bits code word of any length is reserved as a prefix for longer code words – Reinstate Monica Mar 28 '19 at 18:17
  • Small correction: MCU consists of 1 DC coefficient and **63** AC coefficients. _8 × 8 blocks, and each block is transformed by the forward DCT into a set of 64 values referred to as DCT coefficients. One of these values is referred to as the DC coefficient and the other 63 as the AC coefficients. Each of the 64 coefficients is then quantized <...> After quantization, the DC coefficient and the 63 AC coefficients are prepared for entropy encoding._ [spec](https://www.w3.org/Graphics/JPEG/itu-t81.pdf) (page 19) – shitpoet Sep 02 '22 at 19:48
  • Also there can be a possibility to create a multi-scan progressive JPEG with a lot of refine scans. As far as I know JPEG standard does not limit the maximum number of scans. Anyway I read somewhere it can easily (theoretically) be say 1000. I am not sure if it possible to create refine scans doing nothing according to the spec. But if it possible then maximum theoretical size of 200x200 JPEG would be approaching infinity) – shitpoet Sep 02 '22 at 19:52
12

As a rule of thumb, no JPEG is going to be larger than an equivalent size 32-bit bitmap. A 32-bit bitmap will have 4 bytes per pixel in the image, so multiply the dimensions together (200x200 = 40000), then multiply that by 4 bytes (40000x4 = 160000), and you'll have an upper bound in bytes - for your example, 160000 bytes is approximately 156kb.

Amber
  • 507,862
  • 82
  • 626
  • 550
  • Is there a rule for the minimum bounds of the file? – Tegra Detra Apr 29 '10 at 04:06
  • That's a bit too big. The size of a pixel is 12 bits, not 32. At minimum, a JPEG would be a kilobyte or so. Try opening up paint and saving a blank image as JPEG. – Mike Bailey Apr 29 '10 at 04:11
  • 3
    I never stated that a JPEG uses 32 bits for a pixel. I stated that a 32-bit bitmap (the most common type) uses 32 bits for a pixel - and that JPEGs are always going to be smaller than equivalent bitmaps (since bitmaps are about the least efficient format there is). – Amber Apr 29 '10 at 04:23
3

The maximum possible size a JPEG can be should be somewhere around width * height * 12 bits.

JPEG converts images to a different color space (YCbCr) which uses fewer bits (12 to be exact) to represent a single color. Realistically speaking though, the image will be much smaller than the above formula would suggest.

If we use lossless compression only, the file size would be a bit smaller. Even then, no one does that so your image should be far below the limit set by that formula.

In short: 60 kb tops, but most likely way less.

Mike Bailey
  • 12,479
  • 14
  • 66
  • 123
1

The final size in bytes is based on the encoding quality settings used and the number of pixels. In your case, all images should be the same size since you are doing the encoding and your user seems forced to draw on a 200x200 area.

According to wikipedia though, the maximum is roughly 9 bits per a pixel.

So 200*200*9 = 360000 bits = 45 kB

http://en.wikipedia.org/wiki/JPEG#Effects_of_JPEG_compression

Tim Bender
  • 20,112
  • 2
  • 49
  • 58
0

I'm not sure this would be that helpful, but I believe that the absolute maximum it could be would be:

width * height * 4 (size of int) You should probably also add in a maybe a kilobyte for metadata... but I doubt the image would EVER reach that (as that is the whole point of JPEG compression)

Mitch Dempsey
  • 38,725
  • 6
  • 68
  • 74