12

For example, I have an 1024*768 JPEG image. I want to estimate the size of the image which will be scaled down to 800*600 or 640*480. Is there any algorithm to calculate the size without generating the scaled image?

I took a look in the resize dialog in Photoshop. The size they show is basically (width pixels * height pixels * bit/pixel) which shows a huge gap between the actual file size.

I have mobile image browser application which allow user to send image through email with options to scale down the image. We provide check boxes for the user to choose down-scale resolution with the estimate size. For large image (> 10MB), we have 3 down scale size to choose from. If we generate a cached image for each option, it may hurt the memory. We are trying to find the best solution which avoid memory consumption.

Vincent
  • 321
  • 1
  • 2
  • 9
  • 3
    How many images do you have? If it's a comparatively small number, you might be better off just doing the resizing and looking at the file size. Especially if you're going to have to actually resize it at some point. – Anon. Dec 22 '10 at 21:01
  • I have mobile image browser application which allow user to send image through email with options to scale down the image. We provide check boxes for the user to choose down-scale resolution with the estimate size. For large image (> 10MB), we have 3 down scale size to choose from. If we generate a cached image for each option, it may hurt the memory. We are trying to find the best solution which avoid memory consumption. – Vincent Dec 22 '10 at 21:12

7 Answers7

10

I have successfully estimated the scaled size based on the DQT - the quality factor.

I conducted some experiments and find out if we use the same quality factor as in the original JPEG image, the scaled image will have size roughly equal to (scale factor * scale factor) proportion of the original image size. The quality factor can be estimate based on the DQT defined in the every JPEG image. Algorithm has be defined to estimate the quality factor based on the standard quantization table shown in Annex K in JPEG spec.

Although other factors like color subsampling, different compression algorithm and the image itself will contribute to error, the estimation is pretty accurate.

P.S. By examining JPEGSnoop and it source code, it helps me a lot :-)

Cheers!

Vincent
  • 321
  • 1
  • 2
  • 9
3

Like everyone else said, the best algorithm to determine what sort of JPEG compression you'll get is the JPEG compression algorithm.

However, you could also calculate the Shannon entropy of your image, in order to try and understand how much information is actually present. This might give you some clues as to the theoretical limits of your compression, but is probably not the best solution for your problem.

This concept will help you measure the differences in information between an all white image and that of a crowd, which is related to it's compressibility.

-Brian J. Stinar-

Brian Stinar
  • 1,080
  • 1
  • 14
  • 32
  • This really help! It seems like another lesson for me :-) I have the feeling I finally will use the actual compression algorithm. – Vincent Dec 22 '10 at 21:51
2

Why estimate what you can measure?

In essence, it's impossible to provide any meaningful estimate due to the fact that different types of images (in terms of their content) will compress very differently using the JPEG algorithm. (A 1024x768 pure white image will be vastly smaller than a photograph of a crowd scene for example.)

As such, if you're after an accurate figure it would make sense to simply carry out the re-size.

Alternatively, you could just provide an range such as "40KB to 90KB", based on an "average" set of images.

John Parker
  • 54,048
  • 11
  • 129
  • 129
  • Isn't this the halting problem? – Brian Stinar Dec 22 '10 at 21:18
  • @Brian Stinar Er... no? (Thought that was about whether a program could run indefinitely without crashing or summat?) – John Parker Dec 22 '10 at 21:21
  • 1
    Is there any better algorithm to calculate the "average" set? – Vincent Dec 22 '10 at 21:23
  • 1
    @Vincent - The perfect algorithm in this instance is the JPEG compression code. :-) You could attempt to examine the image (colour variation, changes in contrast, etc.) and make a more informed guess based on this, but this could quite possibly be less efficient than simply carrying out the re-size, especially as you'll need to open the original image and hence use lots of memory, etc. anyway. – John Parker Dec 22 '10 at 21:27
  • You'll have to run the algorithm in order to find the output of the algorithm {halt, no halt}. That's all I meant. – Brian Stinar Dec 22 '10 at 21:37
  • @Brian Stinar Ahh - yup. I see what you mean. In that case it is. Sort of. Kinda. A bit. ;-) – John Parker Dec 22 '10 at 21:38
  • 1
    How then does the iPhone mail controller predict the size of the image when offering the different scale-down options (Small, Medium, Large, Original) ? – Kamchatka Feb 26 '11 at 04:22
  • @Kamchatka: I don't know how it's implemented but it just as well could "brute force" it. Imagine the "small" setting should result in a file of 50Kib or less. Then it could just compress the image with setting X and see if the result is < 50Kib or > 50Kib. From there it's a simple "binary search" to find the closest value just below (or equal) to 50Kib. – RobIII May 27 '13 at 20:35
1

I think what you want is something weird and difficult to do. Based on JPG compression level some images are heavier that others in terms of heavier (size).

crsuarezf
  • 1,201
  • 3
  • 18
  • 33
  • 1
    I think this is correct. If I have an image of 5000 x 5000 pixels of pure black, the JPEG algorithm is going to give me better compression than if I have a beautiful image of a dude in a "CAT" baseball hat wearing a button up shirt. – Brian Stinar Dec 22 '10 at 21:17
1

My hunch for JPEG images: Given two images at same resolution, compressed at the same quality ratio - the image taking smaller memory will compress more (in general) when its resolution is reduced.

Why? From experience: many times when working with a set of images, I have seen that if a thumbnail is occupying significantly more memory than most others, reducing its resolution has almost no change in the size (memory). On other hand, reducing resolution of one of the average size thumbnails reduces the size significantly. (all parameters like original/final resolution and JPEG quality being the same in the two cases).

Roughly speaking - higher the entropy, less will be the impact on size of image by changing resolution (at the same JPEG quality).

If you can verify this with experiments, maybe you can use this as a quick method to estimate the size. If my language is confusing, I can explain with some mathematical notation/psuedo formula.

  • Thanks! I understand what you explained. It would be nice to show the mathematical formula. P.S. Is there any metadata in JPEG that can help to elicit the entropy? – Vincent Dec 23 '10 at 18:52
  • It might be too late a reply to be useful for you, but: I don't think there is any metadata about frequencies. Also, now that I go on to devise a psuedo-formula - its turning out to be more confusing than the plain explanation :). –  Jan 11 '11 at 04:37
0

An 800*600 image file should be roughly (800*600)/(1024*768) times as large as the 1024*768 image file it was scaled down from. But this is really a rough estimate, because the compressibility of original and scaled versions of the image might be different.

Oswald
  • 31,254
  • 3
  • 43
  • 68
0

Before I attempt to answer your question, I'd like to join the ranks of people that think it's simpler to measure rather than estimate. But it's still an interesting question, so here's my answer:

Look at the block DCT coefficients of the input JPEG image. Perhaps you can find some sort of relationship between the number of higher frequency components and the file size after shrinking the image.

My hunch: all other things (e.g. quantization tables) being equal, the more higher frequency components you have in your original image, the bigger the difference in file size between the original and shrinked image will be.

I think that by shrinking the image, you will reduce some of the higher frequency components during interpolation, increasing the possibility that they will be quantized to zero during the lossy quantization step.

If you go down this path, you're in luck: I've been playing with JPEG block DCT coefficients and put some code up to extract them.

Community
  • 1
  • 1
mpenkov
  • 21,621
  • 10
  • 84
  • 126
  • But doesnt the higher the frequency of a component, the lower size is the jpeg image (like the huffman code). Thus, the lower impact when we scale the image? – Vincent Dec 23 '10 at 19:26
  • I think this depends on the number of high frequency components, but not on the actual frequency of an individual component. It's been a while since I studied this stuff, but the term I think you want to read about is called "Nyquist–Shannon sampling theorem". I think this is primary a sampling problem, if you need many high frequency components you will have more information. Check out the wikipedia on "Nyquist–Shannon sampling theorem" and let me know if I'm totally wrong. – Brian Stinar Dec 23 '10 at 21:38
  • 1
    There are two different *frequencies* to think about here. The first is the frequency of terms in a sequence -- in an entropy coding sense (as Vincent mentioned). The second is *DCT domain frequency* (DC = plain image, higher frequency = finer detail). Both are relevant to JPEG, but my answer was aimed at examining the *DCT domain frequencies* of each encoded block. As Brian Stinar correctly points out, many high frequency components in an image means more image information. The more you have, the more you have to lose. The task is to estimate how much you will lose during the resizing. – mpenkov Dec 24 '10 at 03:42