zopflipng resets the resolution / image DPI

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Download the attached PNG.
2. On a terminal, execute:  zopflipng preview.png preview.min.png
3. Use an image viewer application to determine the image DPI of `preview.png' 
versus `preview.min.png'.  For example, open the images in Mac's Preview.app 
and press ⌘I to show the inspector.

What is the expected output? What do you see instead?
The image DPI changed from 144 DPI to 72 DPI.  I expected the image DPI to 
remain unchanged.

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

Please provide any additional information below.
Not changing the resolution of the PNG is important for creating assets for 
high-DPI displays such as a Retina display.

Original issue reported on code.google.com by dtrebbien@gmail.com on 29 Oct 2014 at 11:12

Attachments:

• preview.png

[GoogleCodeExporter]

You're correct that this should be fixed.

The problem is that ZopfliPng strips the pHYs chunk. You can avoid that 
behavior by adding the command line argument 

   --keepchunks=pHYs

By default zpfliPNG only keeps IHDR, PLTE, tRNS, IDAT and IEND.

Original comment by bay...@gmail.com on 30 Oct 2014 at 8:48

[lvandeve]

Hi,

--keepchunks=pHYS is indeed the way to keep the DPI.

By default zopflipng removes optional chunks (such as pHYS starting with a small letter), and only keeps the critical ones containing the pixel data (afaik web browsers don't use DPI, please correct me if this is wrong).

In case the information is needed, it can be kept with keepchunks, at the cost of some bytes. For example the pHYS chunk is 21 bytes and uncompressible (section 4.2.5 at https://www.w3.org/TR/PNG-Chunks.html: 9 bytes of data, plus the standard 12 bytes of PNG chunk overhead).

So this is by design. If anything should be fixed, it's the documentation, I'll look into it :)