1

I have read severel posts like this one claiming that the size of a JPG texture can be calculated as

If each pixel contains 32 bits of information, then

307,200 * 32 = 9,830,400 bits of information

Divide by the 8 bits to become a byte value

9,830,400 / 8 = 1228800 bytes (Or 1.17 Mb)

which totally makes sense since each pixel is represented by a color value. Here comes the weird part:

I have these two JPG files

First JPG which has the dimensions 242x198 and uses 24-bit color values.

Second JPG which has the dimensions 3840x2400 and uses 24-bit color values.

Then I tried to calculate the sizes using the technique above and concluded that

  1. The first JPG must have the size 242*198*24 = 1149984 bits = 1149984/8/1000 = 143.7 kb - now the actual file size is 47,6 kb?? So the calculation apparently gives a number above the actual size, why?

  2. The second JPG must have the size 3840*2400*24 = 221184000 = 221184000/8/10000 = 27.6 mb - now the actual file size is 7.33 mb. So the calculation apparently gives a number above the actual size, why?

I have myself managed to draw the first JPG and made sure to export it without compression (JPG 100).

Alan Birtles
  • 32,622
  • 4
  • 31
  • 60
  • I am not sure that 100% is compression free. It may still be lossless compression. – drescherjm Sep 28 '18 at 17:03
  • I recollect that image raster data should be word aligned. Thus the extra bytes are a result of the word alignment. Maybe I'm wrong, but this was the case for other image types (other than JPEG). – PaulMcKenzie Sep 28 '18 at 17:03
  • @drescherjm well if a JPG cannot be 100%-compression-free - how would you calculate the size of the texture? I need this because i am trying to edit some texture data and has to know how many bytes there are –  Sep 28 '18 at 17:47
  • If this data is compressed I am not sure you can edit it easily. Changing the values will change the # of bytes. And you have to decompress to edit and recompress after your edit. – drescherjm Sep 28 '18 at 17:49
  • The article you refer to suggests an upper bound for the size of a JPEG. As such, you shouldn't be surprised that your JPEG comes in lower than the upper bound. The actual size is dependent on the information content and frequencies present in your image, so can vary considerably. https://en.m.wikipedia.org/wiki/JPEG – Mark Setchell Sep 28 '18 at 19:57
  • @MarkSetchell I see. I think what made me confused was the fact that apparently my JPGs somehow still were compressed even though i selected "no" to compression. Thanks for the comment :) –  Sep 28 '18 at 20:06
  • It's actually almost impossible to predict how big a JPEG will turn out with a given quality - I wrote a "binary search" type of approach here... https://stackoverflow.com/a/52281257/2836621 – Mark Setchell Sep 28 '18 at 20:09
  • @MarkSetchell great, i'll check it out –  Sep 28 '18 at 20:16
  • ***were compressed even though i selected "no" to compression.*** 100% quality does not mean no compression. Here is an example that shows 2.7:1 compression with Q=100 https://en.wikipedia.org/wiki/JPEG#Sample_photographs – drescherjm Sep 28 '18 at 21:18

1 Answers1

0

The whole point of JPEGs is that they are compressed to take up less space. If you resave your file as a BMP you'll get the sizes you expect (plus a bit extra for headers and alignment).

Alan Birtles
  • 32,622
  • 4
  • 31
  • 60
  • Then how would you calculate the size of a JPG? –  Sep 28 '18 at 17:29
  • @sostack by creating it and seeing how big it is, the actual size depends on the complexity of the image and the compression level. if you want a specific size then compress it, if its too big reduce the quality and compress again, repeat until you get the size you want. If your question is how to do that then you should edit your question to say so. – Alan Birtles Sep 28 '18 at 20:35