Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PNG files are created with 48/64 bit depth, not 24/32 - results in increased file size, potential incompatibility/standards breach #157

Strobey opened this issue Apr 24, 2015 · 4 comments


Copy link

Strobey commented Apr 24, 2015

I noticed that some of the PNG files RFB creates, specifically the android-chrome*.png and apple-touch*.png have 48 or 64 bpp rather than the expected 24 or 32.

This isn't always the case, it seems to primarily happen to those created with the "Add a solid, plain background...." feature, but there might be other settings that do it.

This has a few problems:

  • Firstly, the filesize - eg. android-chrome-192x192.png (48bpp) was 34.41KB. When I re-saved this as a 24bpp PNG the filesize dropped to 15.28KB - that's over 55% smaller!
    Similarly, the apple-touch-icon-precomposed.png (64bpp) was 28.60KB, when re saved as 32bpp it was 14.44KB, about half the size.
  • Secondly a possible breach of standards - according to the w3C ( - "the format for the image you have chosen must be 16x16 pixels or 32x32 pixels, using either 8-bit or 24-bit colors. "
    Also the Apple documentation ( suggests that the bit depth should be 24/32bits.
    "The standard bit depth for icons and images is 24 bits—that is, 8 bits each for red, green, and blue—plus an 8-bit alpha channel, for a total of 32 bits. "
    (emphasis mine)
  • Thirdly, this could potentially cause compatibility problems with devices that aren't expecting this format or that perhaps have an old or buggy PNG library. Given the targets affected by those particular PNG's, this is unlikely, but it's a possibility.


@phbernard phbernard added the bug label Apr 27, 2015
Copy link

phbernard commented Apr 27, 2015

Wow, I never realized this. Thank you very much for reporting this one with so much details.

I suppose ImageMagick (used internally to generate the pictures) can manage this. I think the easiest solution is to blindly re-encode each generated picture to make sure everything it properly encoded, whatever the options.

Copy link

Strobey commented Apr 29, 2015

No worries!

I've had a look at the options for ImageMagick, it looks like if you just add:
-depth 8
to the command line of your existing conversions that create the PNG files that it will force it to 24/32 bits (ie 8 bits per channel which is what the -depth command does). That should be enough the way I read it.
See similar issue -
Reference -

You might also want to add this which will make the file as small as possible:
-type optimize
(but only if you are not already using the "type" command with a different type)

Hope this sorts it out :)

Copy link

phbernard commented May 4, 2015

Thank you!

The fix will be part of the patch v0.11 (

phbernard added a commit to RealFaviconGenerator/realfavicongenerator-api-test-suite that referenced this issue May 12, 2015
@phbernard phbernard added this to the Package v0.11 milestone Sep 7, 2015
Copy link

phbernard commented Feb 18, 2016

That was released on 2015/12/03 as part of v0.12, see

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

2 participants