I have a 32bit PNG converting to 8bit in Photoshop. My understanding the conversion should drop the file size of the image to a quarter of its original (because 32/8 = 4). Say a 750kb 32-PNG file should get to ~188kb 8-bit PNG, but my 8-bit image still has 333kb in size. Why?

enter image description here

  • 2
    \$\begingroup\$ I'm voting to close this question as off-topic because it's about image file formats without a photographic context. \$\endgroup\$
    – Philip Kendall
    Mar 27, 2018 at 4:25
  • \$\begingroup\$ @PhilipKendall, please suggest a better stackexchange site or suggest migrate this question to a suitable place. \$\endgroup\$
    – KMC
    Mar 27, 2018 at 5:06
  • \$\begingroup\$ @KMC graphicdesign.stackexchange.com \$\endgroup\$
    – Michael C
    Mar 27, 2018 at 12:03
  • 3
    \$\begingroup\$ Graphic Design might be appropriate. But please do consider that not every possible question has a specific home, and that just because there isn't one doesn't necessarily change what should be on topic here. You might try superuser.com, which is the Stack Exchange site for general computer questions, which this seems to really be. \$\endgroup\$
    – mattdm
    Mar 27, 2018 at 15:55
  • 1
    \$\begingroup\$ File formats like PNG and JPEG are certainly relevant to photography, even if the OP didn't say specifically that the file in question came from a camera. \$\endgroup\$
    – Caleb
    Mar 27, 2018 at 21:27

3 Answers 3


My understanding the conversion should drop the file size of the image to a quarter of its original (because 32/8 = 4).

PNG images are compressed, so your 750KB file is already much smaller than what you'd get if you multiplied the number of pixels in the image by 4 bytes (or 32 bits). When you convert to 8 bits, you do reduce the amount of information that needs to be stored, but you don't reduce it by a factor of 4.

  • \$\begingroup\$ and also, if used for photos, the 32 bit PNG is actually 24 bit (as the transparency channel is not used). even ignoring compression, the file size would be 3x smaller, not 4x. \$\endgroup\$
    – szulat
    Mar 28, 2018 at 14:10

It comes down to compression.

Note: This is answer tries to be technical, but on an understandable level. Therefore, there might be some (hopefully small) inaccuracies.

Different file formats have different methods for achieving different goals. BMPs, TIFs, and OpenEXRs, for example, can all be saved with different compression algorithms - or no compression at all. That way, the user can decide if they want to have bigger files that can be saved with less CPU time or smaller files that will need some additional computation.

PNG, like JPEG, does not offer a modular solution. PNG will always be compressed by doing some filtering (meaning that the encoder will look for a way to efficiently "pack" the pixels) and then by compressing it via DEFLATE, which basically tries to reduce redundant data1 and then, it uses a Huffman table / Run Length Encoding, which basically tries to store information into binary in the most efficient way. Both sub-steps are lossless and relatively easy to compute.

1 Reducing redundant data: E.g. a 8x8 checker field can be saved as 1 black and 1 white square with each of them repeating itself 32 times in alternating order.

A basic example:

Say your 32 bit image looks like this:

Subtractive color wheel

Stolen from Wikipedia's article on Color Mixing

This image contains 8 colors - cyan (RGB 0, 1, 1 2), green (RGB 0, 1, 0), yellow (RGB 1, 1, 0), red (RGB 1, 0, 0), magenta (RGB 1, 0, 1), blue (RGB 0, 0, 1), black (RGB 0, 0, 0), and white (RGB 1, 1, 1 ). Therefore, it can (in theory) be saved by saying From pixel position X=0 Y=0 to X=100 Y=0: RGB=1, 1, 1; from pixel position X=101 Y=0: RGB=0, 1, 1; [...] (this is the DEFLATE-part) and then, this information is saved via a Huffman coding, meaning that the most repetitive part of the information gets a binary value of 0, the second-most repetitive part gets 10, the third most repetitive gets 110, etc.p.p..

2 Representation from 0 to 1, as this is usual for 32 bit pictures.

Therefore, your image can be stored relatively efficiently if compression is at hand - and as discussed, PNG always compresses your images.

Now, if you convert a picture from 32 bit to 8 bit (or do any downconverting), all that happens is that the discrete values will get a new, coarser-grained scale (as in: less sub-steps). For example, a 32 bit pixel has to hold the information for each channel in steps of 0.000000001 from 0 to 1, while an 8 bit pixel has to hold the same information in steps of 1 in a range from 0 to 255. Each value from 32 bit now has to be mapped to a new value on our 8 bit scale, which means that usually, many values of the 32 bit scale will get packed into a single value of the 8 bit scale.

However, our picture has no gradients but only solid colors, so we had no need to save our picture with a precision of 0.000000001 per channel per pixel in the first place - in reality, we would only need 8 different values.

Therefore, our 32 bit picture will ideally not have 4 times the file size of the 8 bit picture, as the bit depth reduction can be achieved losslessly (so the 8 bit picture is not smaller) and filtering and DEFLATEing should reduce the file size of the 32 bit file in the first place. Now, if we would add a few gradients, the 8 bit would either be far more efficient - or far worse, as it would show banding artifacts.

What this means for you:

Bit depth reduction not always leads to smaller file size - especially when your codec has some compression implemented. However, it does not mean that 32 bit is useless by any means: It is always better to work with a picture (or anything, really) with no reduction in its information as long as it is possible. This however does not mean that you should go ahead and save all your pictures as 64 bit OpenEXRs: If you care for file size, try to approach this topic with the sensible attitude of "how much do I need?". If you do not care for file size, go with as much bit per pixel as you like.

  • 1
    \$\begingroup\$ You lost me at "less granular," but it's probably just a matter of how you look at it. I think most people would say that "more granular" means larger steps, which is what you get with 8-bit color. Instead of more/less, it might work better to talk about granularity using words like coarse and fine. Also, it's a little hard to see how the very simple and somewhat contrived example image here relates to the 750KB file that the OP was talking about. \$\endgroup\$
    – Caleb
    Mar 28, 2018 at 14:31
  • \$\begingroup\$ @Caleb Oh - that might be true. As English isn't my native language, it might well be that I misinterpreted the meaning of granular, as it is not a word that correlates to anything we use regularly in German (fein and grob relate to fine and coarse). Will change that ASAP. As to "simple image != 750kB": you are absolutely right - however, I could not see a way to stay simple AND talk about edges, repetitive patterns, noise/grain, and gradients. If you have any suggestions about that, I'm of course all ears :-) \$\endgroup\$
    – flolilo
    Mar 28, 2018 at 15:46

There are a lot of factors regarding image compression and bit depth.

My understanding the conversion should drop the file size of the image to a quarter of its original (because 32/8 = 4).

No. The conversion drops the bit depth from 24 to 8. If it was a png with alpha channel included the transparency will be dropped. That is the bit depth, not the file size.

To estimate the file size you need to take into account what is the content of your image.

A photo of a forest, where you have a lot of tiny details and changes in color will be significantly bigger than a photo of a blue sky.

So trying to drop the bit depth of a blue sky will not reduce the resulting file weight much, because it is already optimized.

But a funny thing is that probably the forest will neither because there would be a lot of changes in regions of color.

A compression basically tells "Here is a large zone of similar colors" and in the forest image could potentially not be a large zone of similar colors next to each other.

Where you potentially will notice more difference in compression is in colorful gradients, where you "Flatten" a 256 levels gradient to a posterized version of only let's say 8 colors for each gradient. But again, depends on the photo, the final palette.

If you dither your image you can potentially increase the file size!


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.