-
Hi, and thank you for your request.
As I am slowly working towards completing version 0.7, I am happy to let you know that the feature that you requested already exists in the 0.7 alpha branch. This has been requested by many people for a long time, and is listed in the Roadmap section. (See "metadata editing" in the OptiPNG home page.)
There will still be a while before the final 0.7 release...
2009-10-27 01:44:17 UTC in OptiPNG
-
You should be able to use wildcards, e.g. *.png, or /path/to/images/*.png. If you want recursive path search, you could try rOptiPng, an OptiPNG-based tool designed to do just that.
2009-10-16 21:18:35 UTC in OptiPNG
-
Thanks for the report. BTW, libpng 1.2.40 is already out, and libpng 1.4.0 is just around the corner.
As a general rule, every new OptiPNG release has the latest libpng. On the other hand, there is no need to make a new OptiPNG release with every libpng release, unless the new libpng release contains a functionality enhancement or a critical fix that affects OptiPNG. Moreover of the past libpng...
2009-09-13 03:16:04 UTC in OptiPNG
-
Thank you, Igor. "Later" is good enough, because incorporation of 7zip-based deflation in OptiPNG also falls under "later" in my plans :-)
Best regards,
Cosmin.
2009-08-25 03:34:47 UTC in 7-Zip
-
Hello,
Recently I downloaded the LZMA SDK, hoping that I could use it for producing well-compressed deflate streams. I noticed, however, that the SDK supports LZMA compression only.
Not only LZMA, but also deflate, are highly optimal when produced by 7zip. I was hoping to use the deflation code in another project (OptiPNG), but adapting the 7zip LGPL-licensed code is too restrictive for me...
2009-08-23 18:27:23 UTC in 7-Zip
-
Dirk,
I just realized I forgot to respond to your other question:
> BTW: Is there somewhere a UNIX software to show the CHUNKS and internal contents of PNGs?
pngcheck
http://www.libpng.org/pub/png/apps/pngcheck.html
Best regards,
Cosmin.
2009-08-23 15:23:33 UTC in OptiPNG
-
Dirk, thank you for updating your submission by adding "fixed.png". Now I think I understand what's going on.
The difference between "optipng.png" and "fixed.png" is a few chunks: pHYs, tIME and bKGD. GIMP didn't do anything smart; on the contrary, all it did was throw away the chunks that it does not understand. That's why the GIMP'ed image ended up being smaller.
But why does it appear...
2009-08-16 18:25:19 UTC in OptiPNG
-
One more thing:
Compression-wise, this method has to be carefully analyzed as well. It's one thing when you erase wide areas of contiguous alpha=0 pixels, and that helps you with compression; but it's another thing when this is done blindly on any image and you apply it, say, on images that have "transparent salt" (very small areas of transparent pixels surroundend by large areas of...
2009-08-16 17:13:12 UTC in OptiPNG
-
Hello, pornel,
I am sorry I am rejecting this patch. I initially set the resolution to "postponed", thinking I will do it later, but, after thinking about it more carefully, I consider it altogether a bad idea for OptiPNG.
However, do not let yourself be deterred by my decision. You don't necessarily need to put this code in OptiPNG or pngcrush, especially given that ImageOptim works by...
2009-08-16 16:53:16 UTC in OptiPNG
-
Hello, Dirk,
As far as I understand from your report, you fed "original.png" to OptiPNG, and you received "optimized.png". Unless I'm missing something, here is what I noticed:
** Processing: original.png
7x16 pixels, 4x8 bits/pixel, RGB+alpha
Reducing image to 8 bits/pixel, grayscale
The original image has a sterile alpha channel, which OptiPNG correctly stripped away. Moreover, the...
2009-08-14 01:12:07 UTC in OptiPNG
