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

Closed
Strobey opened this Issue Apr 24, 2015 · 4 comments

Comments

Projects
None yet
2 participants
@Strobey

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 (http://www.w3.org/2005/10/howto-favicon) - "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 (https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/IconMatrix.html#//apple_ref/doc/uid/TP40006556-CH27-SW2) 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.

Thanks.

@phbernard phbernard added the bug label Apr 27, 2015

@phbernard

This comment has been minimized.

Show comment
Hide comment
@phbernard

phbernard Apr 27, 2015

Contributor

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.

Contributor

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.

@Strobey

This comment has been minimized.

Show comment
Hide comment
@Strobey

Strobey 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 - http://www.imagemagick.org/discourse-server/viewtopic.php?t=6290
Reference - http://www.imagemagick.org/Usage/formats/#png_write

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 :)

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 - http://www.imagemagick.org/discourse-server/viewtopic.php?t=6290
Reference - http://www.imagemagick.org/Usage/formats/#png_write

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 :)

@phbernard

This comment has been minimized.

Show comment
Hide comment
@phbernard

phbernard May 4, 2015

Contributor

Thank you!

The fix will be part of the patch v0.11 (http://realfavicongenerator.net/change_log)

Contributor

phbernard commented May 4, 2015

Thank you!

The fix will be part of the patch v0.11 (http://realfavicongenerator.net/change_log)

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

@phbernard

This comment has been minimized.

Show comment
Hide comment
@phbernard

phbernard Feb 18, 2016

Contributor

That was released on 2015/12/03 as part of v0.12, see http://realfavicongenerator.net/change_log

Contributor

phbernard commented Feb 18, 2016

That was released on 2015/12/03 as part of v0.12, see http://realfavicongenerator.net/change_log

@phbernard phbernard closed this Feb 18, 2016

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