This is the original image, 625 x 833 at 71KB

This is a resized image, increasing to 704 x 938 file size is 136KB

So, long story short, we are developing an app. We have a couple of animations which are roughly 200 png's long. We are no longer working with our animator who made these in flash. The animations, when exported to their final state are around 70kb, however if I look in the assets in the app, they are closer to around 30kn each.

So, I find myself in a bit of a bind. I cannot figure out, for the life of me, how someone got squeezed those few KB's out of these png's. Every time I modify any of these png's they double in size.

I am increasing these in pixels only around 105% is that enough to jump that much?

  • 1
    I feel like there's a lot of information missing. What do these PNGs look like? What do you mean "I am increasing these in pixels only around 105%"? What compression techniques have you tried? Do you still have the original Flash files? – Zach Saucier Mar 22 '16 at 20:01
  • FYI: 105% increase in each dimension (100px > 105px) is a 10% increase in total pixels, and ICC profiles appear to be approx 4k (fixed). Note that I have had PNGs with transparency data where the transparency was "invisible" when opened in Photoshop, so if you are altering the transparency and exporting with a new alpha channel, you are adding a 4th channel (approximately 1.33x) more data. (Some RGBA is e.g. 5 bits for R & B, 6 bits for G and 1 bit for alpha). The app may be storing "headerless bitmaps" have only the image data... – Yorik Mar 22 '16 at 20:42
  • Wow, well thank you both, that is great information... As of right now I have tried a decent amount. Exporting directly from flash, increasing size in flash and exporting, exporting in AE, etc. as far as different formats, decreasing colors doesn't make much of a difference, the biggest shift I have had was when I turned off smoothing in Flash. I even tried creating a batch process in PS, importing and using "save for web" for each png. I will upload a sample of the images. Thanks guys! – Evan H. Stanfield Mar 22 '16 at 21:11
  • Is it likely that your designer used another tool to better compress the PNGs after exporting them? Tools such as pngcrush can quite literally squeeze PNGs down to the absolute minimum size - and they typically do so without changing the image itself a bit. – usr2564301 Mar 22 '16 at 23:25

In short PNG, just like GIF, is based on color reduction for compression. And by rescaling, you're increasing the amount of colors.

A regular bitmap is saved as 24 (or 32, including transparency) bits per individual pixel, which gives RGB channels of 8 bits, and a total of 256x256x256 = 16 million colors.

GIF says wait. I'm going to use less colors (256 in total), and I'm creating a list of all the colors I am using. So your colors can be picked from those 16 million, just not too many of them. This makes it much more efficient than a bitmap, with the downside that you can't use the whole 16 million colors in a single image. But for simpler images that's fine.

A GIF is at least ~3 times as efficient (8 bits vs 24 bits), but potentially more. Because if you only use 16 colors instead of 256, it only needs 4 bits per color. And GIFs also don't store every single pixel. A bitmap will say 1, green, 2, green, 3, green, 4, green, 5, blue, 6, red, 7 blue, 8 blue. Whereas a GIF will say 1, green, 5, blue, 6 red, 7, blue.

PNG is almost the same as a GIF, but it says; yeah I like the idea of using less colors, and just listing the first out ouf a series of same-colored pixels... but what if I do need more than 256 pixels? PNG will use less bits if possible, so 4 bits if you use 16 colors, 8 bits if you use 256 colors or less, and 24 bits if you're actually using all 16 million colors because it's a photo of a holi celebration.

What this boils down to is this; the less colors you use, and the larger your flat areas are; the smaller your filesize is.

When exporting the artwork from flash, your artist (or an algorithm) looked at the work and said; okay I am currently using a lot of colors, but if I reduce it to about 32, it will look pretty much the same to the naked eye.

Then you took the image and resized it, which creates more unique pixels. Because instead of a clean cut between color A and B, the border is now halfway between a pixel, so photoshop creates a new color that is a mix of A and B. This has two main effects: - it creates more colors, so writing down each color takes more bits - it creates more color changes per row

Both make the image file larger.

Take a simple circle for example: enter image description here Goes from 16 to 17 pixels, and from 2 to about 8 colors. I can write down the (firs few lines of) first circle as

1, white, 6, blue, 12, white, end
1, white, 4, blue, 14, white, end
1, white, 3, blue, 15, white, end

Whereas the second circle is

1, white, 6, lightblue, 7, darkblue, 8, blue, 11, darkblue, 12, lightblue,13, white, end
1, white, 4, lightblue, 5, lightishblue, 6, blue, 12, lightishblue, 13, lightblue, 14, white, end
1, white, 3, lightblue, 4, blue, 14, lightblue, 15, white, end

Which is well over twice as long.

Other people mentioned header data, and exponential growth (scale by 105% means you get 110% amount of pixels) but I believe the bitdepth is the primary cause of the size increase in this case. Imagine writing down a class of schoolchildren by first name only, or by both first and last name.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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