Add option to zopflipng to not change the colorspace

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use zopflipng to compress up_black.png (attached) as up_black2.png:
    zopflipng up_black.png up_black2.png
2. You can use GIMP (Image > Image Properties) or Mac's file info screen ⌘I 
to see that the color space was changed from RGB to Grayscale.

Attached is another PNG, up_gray.png.  zopflipng does not change this image's 
color space:
    zopflipng up_gray.png up_gray2.png

The reason why changing the color space is not desired in my case is because I 
want to create a sprite using ImageMagick.  However, when the sprite tiles have 
different color spaces, then the colors are changed.

I have attached up.png, generated with ImageMagick 6.8.7-7 via:
    convert up_gray.png up_black.png +append up.png
I have also attached up2.png, generated with ImageMagick 6.8.7-7 via:
    convert up_gray2.png up_black2.png +append up2.png
(Note: ImageMagick 6.8.8-2 and ImageMagick compiled from source at revision 
14367 have the same behavior.)

Notice how the colors are different in up.png and up2.png.

What is the expected output? What do you see instead?
I would like an option to *not* change the color space of the input PNG.


What version of the product are you using? On what operating system?
I am using zopflipng compiled from source @c54dc204 on Mac OS 10.9.1 
'Mavericks'.


Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 14 Jan 2014 at 4:33

Attachments:

• up_black.png
• up_gray.png
• up.png
• up2.png

[snoack]

I just ran into the issue, where I had some images in grayscale+alpha mode, which zoplipng converted to RGBA, producing larger files than pngout and pngcrush when preserving the color mode.

FWIW, I wouldn't mind having an option so that I can at least enforce preserving the color mode in these situations. But IMO zopflipng should never migrate to a color mode which the original color mode is a subset of (by default) in the first place. Ideally, it could even detect the colors used in the image and downgrade the color mode automatically to grayscale(+alpha) if possible without losing information.

[snoack]

At least the issue, I experienced only seems to happen with rather small images, and it seems to be a bug, as that code path while handling different color modes only considers RGB and RGBA. Fixing it is trivial:

diff --git a/src/zopflipng/zopflipng_lib.cc b/src/zopflipng/zopflipng_lib.cc
index b93bb18..0a72059 100644
--- a/src/zopflipng/zopflipng_lib.cc
+++ b/src/zopflipng/zopflipng_lib.cc
@@ -239,7 +239,10 @@ unsigned TryOptimize(
       // Too small for tRNS chunk overhead.
       if (w * h <= 16 && profile.key) profile.alpha = 1;
       state.encoder.auto_convert = 0;
-      state.info_png.color.colortype = (profile.alpha ? LCT_RGBA : LCT_RGB);
+      if (profile.colored)
+        state.info_png.color.colortype = (profile.alpha ? LCT_RGBA : LCT_RGB);
+      else
+        state.info_png.color.colortype = (profile.alpha ? LCT_GREY_ALPHA : LCT_GREY);
       state.info_png.color.bitdepth = 8;
       state.info_png.color.key_defined = (profile.key && !profile.alpha);
       if (state.info_png.color.key_defined) {

Adding an option to never change the color mode, would be another story though.

[JayXon]

#130 ?