This patch should fix the problem, but I'd like to take another day or two so that I can see what other changes I could make to the image reduction code. For example: opportunities to remove tRNS from grayscale images exists, just as with RGB images, but they are ignored. Another thing that I want to point out is that this kind of fix ought to be backported to older OptiPNG versions also, e.g. to give a chance to downstream package maintainers to apply the fix even if they don't plan on upgrading...
Example 2 To aid debugging, this test case is perhaps more obvious? See attached 'toolbar.png'. The image is RGB with a tRNS chunk defining RGB(0,0,1) as transparent. Critically, this colour doesn't exist in the image, so there should be no transparency. When viewing, the image has a bright green background. Details are also confirmed with TweakPNG. Image is optimized on Win32 with Batch command line optipng.exe -v -f0 -force "%~1" -out "%~1.out.png", producing: OptiPNG version 0.7.8 Copyright (C)...
Image corruption with invalid transparency
Please ignore my previous message. I must have done something in which I did not manipulate the test images correctly, before running my tests; but after a full reset of my test environment, now I confirm that you bug report is 100% legit.
Andrew, I tried to reproduce the corruption that you're seeing, but I couldn't. I tried it both on Windows and Linux, and both with the embedded libpng and with the system libpng. If you could please take a look at my command line and let me know what I am missing. optipng.exe -i0 -zc1 -zm8 -zs3 -f0 -force actions.png -out out.png The resulting file out.png is identical to actions.png. And then I tried the same but with actions-broken.png: optipng.exe -i0 -zc1 -zm8 -zs3 -f0 -force actions-broken.png...
I started to debug this before, but lost my notes... I observe the issue with non-paletted images (RGB/A), that have a tRNS chunk that specifies an RGB value not present in an image. May affect grayscale images too (G/A) ? When the image is optimised as indexed, the transparency is wrongly applied to the palette index. I think the issue is in the use of libpng png_get_tRNS…? “…For non-paletted images, the function retrieves the single color value which is treated as fully transparent. If the transparency...
I started to debug this before, but lost my notes... I observe the issue with non-paletted images (RGB/A), that have a tRNS chunk that specifies an RGB value not present in an image. When the image is optimised as indexed, the transparency is wrongly applied to the palette index. I think the issue is in the use of libpng png_get_tRNS…? “…For non-paletted images, the function retrieves the single color value which is treated as fully transparent. If the transparency information is valid, i.e. PNG_INFO_tRNS...
I have highlighted the defective pixel (that becomes full transparent), to red for clarity - attached.
Image corruption with invalid transparency
Heap-buffer-overflow at pnm_fget_values
Out of memory crash with optipng-0.7.8?
I'm closing this report as "invalid", because it's not really a bug. However, I will take this as a suggestion to make the error cause more obvious, when such out-of-memory errors occur.
Thank you for your report. This is a legitimate out-of-memory error, because the input images "lie" about being huge, but aren't. (Admittedly, the program could be and maybe should be "smarter" and catch this form of "deceit", but that should be a special feature, not a bugfix.) In my own internal tracing, I can see the following: ** Processing: id_000000.bmp in pngx_read_bmp: width = 2031690, height = 1107296257, depth=16 in pngx_read_bmp: row size = 4063380 Error: Out of memory ** Processing: id_000001.bmp...
Out of memory crash with optipng-0.7.8?
keep creation date
Thanks, Cosmin! OptiPNG is at 0.7.8 in Gentoo now.
I just did what I should have done days ago: ship version 0.7.8 with Thomas' fix as-is. And then, should a follow-up fix turn out to be necessary, I'll do it in the next release. Sebastian wrote: Is there anything making sure that "curbit + code_size" cannot overflow btw? I don't know the answer to this question, which is why I wanted to investigate the other LZW implementations out there, and to understand exactly why they are robust in a way that this one inside OptiPNG isn't. I uploaded the fresh...
Hi Cosmin, would you recommend Thomas' patch for application as-is in Linux distros before the is a release 0.7.8? I think distros would want to patch before 0.7.8 unless it's only a few days away. Is there anything making sure that "curbit + code_size" cannot overflow btw? Best!
The bundled version remains out of date.
This issue can be Closed. It was fixed upstream (commit).
Tested with OptiPNG.exe v0.7.7 (27-Dec-2017), Win32. Confirmed. This 8-bit indexed image is more optimally stored as 2-bit indexed. This reduction should be evaluated, in addition to grayscale 8 bit. The extra run should not be necessary.
Global-buffer-overflow on optipng
Thank you, Thomas, for the fix that you proposed. It is straightforward, and it solves the problem. I want to publish a new release (v0.7.8), with an overhaul of the GIF reader, which was originally forked and then heavily modified, eons ago, from the same original code by David Koblas. Among other programs that are based on the same old code, the most notable one is gif2png. Interestingly enough, that program is unaffected by this POC test case, but that's because of the differences in the handling...
A simple fix that just adds a bounds check: https://gist.github.com/Freaky/0effd5f4bd3895f256329289bc45897e The "configuration options" appear completely meaningless, you don't need any particular flags to trigger this.
A simple fix that just adds a bounds check: https://gist.github.com/Freaky/527b5f4162c392798fae6c04dac92a41 The "configuration options" appear completely meaningless, you don't need any particular flags to trigger this.
@zengyx is there a patch for this?
configuration options:"-zm 3 -zc 1 -zw 256 -snip -out"
Global-buffer-overflow on optipng
Avoid rewriting identical bKGD chunk
1-, 2-, and 4-bit greyscale modes ignored
Unused palette entries not removed
Show filename in case of incorrect file
I suppose this is still not implemented? Unfortunate. I wanted to be able to optimize my screenshots before stuffing them into the clipboard. Something like: $ maim -s | optipng | xclip -selection clipboard -t image/png
Just gave OptiPNG for a spin and sharing my result, just being objective: Test image, 5280z1150z24BPP, saved in irfan PNG Q6: 989KB After OptiPNG, -O5: 900KB webp, lossless: 542KB webp, Q75: 258KB jpq Q75: 491KB (webp Q75 much better image quality)
what is output of command "locale"? If you have non-UTF8 locale, shell does not find filename ???.png if the filename is actually three UTF8-chars + .png. If UTF8 is properly being used, ??? would work, and also copy-paste from dir listing etc.
Indeed what I was looking for was lossy method, thank you for recommendation. I had pretty good results to my needs with "Crunch" https://github.com/chrissimpkins/Crunch (pngquant + zopflipng )
There are "lossy" ways of compressing PNGs. Much like you can compress a jpeg more by throwing away information, there are tools that can throw away some png information to make the image look similar, but be much smaller. If I'm ok with losing information (eg. reducing the colour palette in a lossy manner) then you can try a lossy tool like pngquant.
That depends on how inefficient the original compressor was. Rafał M's experience of 1-15% sounds about right, but if the png is the output of another compressor (eg. pngquant) then expect less than 1%, if any.
hello, I would like to compress the hell out of an png but Im getting few % of decrease compared to this website where I get about 45% compresspng.com Am I doing it wrong or OptiPNG cannot do something that the website is doing?
dont really know, but I tried to compress few png's and I get something between 1%-15%
From further testing with OptiPNG v0.7.7, it seems zlib strategies 0 and 1 both can produce files with static Huffman blocks. I'm not sure what is happening internally in zlib with those strategy modes to enable this...
Expose zlib strategy '4' for fixed Huffman blocks
Add support for APNG
Add palette
Incorrent "-o" parameter treatment
Last time that i've seen this error was in 2018 and it was OptiPNG version 0.7.6. Seems like 0.7.7 does not have this problem. Zlib was updated according to history.txt, maybe that's why. It's OK to close this ticket.
Always use default compression window size
Optipng doesn't support non-ASCII filenames
Misspelling in "A guide to PNG optimization" article
Output goes to stderr instead of stdout
optipng 0.7.6-0.7.7 cannot handle about 1000 chunks
The Mercurial repo was an old and now-abandoned experiment. I released zip and tar archives for OptiPNG until now, but I suppose I could (and should) reconstruct a Git repository out of those archives.
The latest binary release in Files is from 2017, but the latest commit in the Mercurial repo accessible via the SF website is from 2013-12-29, while the Git repo is empty altogether. Is this intentional?
One more thing: if you're willing to disclose your identity, I'd be glad to give credit for your feature request.
Doesn't like some TIFF files
Thank you for the report. It is easy to account for a missing compression field, meaning "no compression", and I'll do that in the next OptiPNG release. You are right: I cannot invest in implementing support for compressed TIFF, unfortunately.
Doesn't like some TIFF files
Stop compression trials once goal filesize is reached
Support Unicode and Wildcard
seems that gifs cannot be uploaded. Please follow the following links: https://github.com/ntu-sec/pocs/blob/master/optipng-0.7.7/hangs/s01.gif https://github.com/ntu-sec/pocs/blob/master/optipng-0.7.7/hangs/s02.gif
Please see the attached input files for reference.
Please see the attached input files for reference.
Please see the attached input files for reference.
Please see the attached input files for reference.
Please see the attached input files for reference.
Please see the attached input files for reference.
Please see the attached input files for reference.
Slow to run on some crafted images
Hi, any update on this item?
cache best try for speeding up
0.7.7: "optipng *.png" don't works
Acknowledged. This is not a bug in OptiPNG, but a backwards-incompatible change in the more recent MinGW-w64 library that has affected the OptiPNG build. I will override that in the next release, so that I can make it work again. Thank you for the report.
-clobber with -out option creates unexpected backup files
Confirmed as a defect to be fixed in an upcoming version. Thank you for the report.
Long execution time and high CPU load
Unfortunately, it is not possible to detect the "already-optimized" status of a PNG image, in the way that you can, e.g., with a JPEG image. When you're optimizing baseline JPEG, you just check if the Huffman trees are the optimized or not. And if you see that they're optimized, you're done. But with PNG, there's no such thing. Most (virtually all) of the PNG images already have their Huffman trees in optimized form, inside the zlib datastream, and yet, PNG optimization is much more than that. There...
Help?
Yep, same problem with the win build, 0.7.6 works fine. Since I don't use anything else than PNG anyway (is it OptiPNG or OptiTIFF, OptiGIF?), the 0.7.7 brings nothing of value so I'll stick with 0.7.6 for now, no prob.
Long execution time and high CPU load
-clobber with -out option creates unexpected backup files
I am experencing the same issue. If optipng is compiled with msvc, wildargs.c may not work as expected.Link with setargv.obj instead of wildargs.obj as documented in https://docs.microsoft.com/en-us/cpp/c-language/expanding-wildcard-arguments should resolve this issue.
Same issue. If compiled with msvc, wildargs.c may not work as expected.Link with setargv.obj instead of wildargs.obj as documented in https://docs.microsoft.com/en-us/cpp/c-language/expanding-wildcard-arguments should solve this issue.
0.7.7: "optipng *.png" don't works
An inquiry about the maximum size a OptiPNG image
Need support for IDAT larger than 2GB
I moved this ticket from "Bugs" to "Feature Requests". This is a known limitation, which results from the concatenation of all IDAT chunks into a single one, without considering that the total amount of IDAT data may be larger than 2GB. Using a 64-bit build won't help in this situation. Future releases should either have this limitation removed, or mentioned as a bug in the user manual.
Ticket moved from /p/optipng/bugs/67/
Possible Malware in Windows build
Was fixed in v0.7.6 (but forgot to close it).
null ptr deref + segfault w/ malformed png
opngreduc.c:957: opng_reduce_to_palette: Assertion `index >= 0' failed.
Hello, and thank you for the defect report. The error occurs because of an undetected bad bKGD chunk, with 16-bit color samples in a 8-bit RGB image. The reduction code in opngreduc.c gets confused because it expects valid PNG data from libpng, but libpng fails to perform this particular check. Here is the fix that applies to libpng v1.6.34 embedded in OptiPNG v0.7.7. The upstream libpng needs this fix (or a similar fix) also. diff --git a/src/libpng/pngrutil.c b/src/libpng/pngrutil.c --- a/src/libpng/pngrutil.c...
opngreduc.c:957: opng_reduce_to_palette: Assertion `index >= 0' failed.
Can we close this issue? Seems to be fixed already.
Hi, Jeff, I've just released OptiPNG version 0.7.7, and looking to close the old defects, I realized I had omitted your report. The issue is fixed, but I haven't credited your discovery. Apologies. I will mention your credit retroactively, in the next OptiPNG release.
Segmentation fault with malformed gif