Activity for OptiPNG
-
Cosmin Truta posted a comment on ticket #90
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...
-
Andrew posted a comment on ticket #90
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
-
Yun created ticket #89
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...
-
schsiung created ticket #88
Out of memory crash with optipng-0.7.8?
-
Laurent Roro created ticket #65
keep creation date
-
Sebastian Pipping posted a comment on ticket #87
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...
-
OptiPNG released /OptiPNG/optipng-0.7.8/optipng-0.7.8.tar.gz
-
-
-
-
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!
-
Thomas Hurst posted a comment on ticket #71
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?
-
zengyx posted a comment on ticket #87
configuration options："-zm 3 -zc 1 -zw 256 -snip -out"
-
Global-buffer-overflow on optipng
-
Avoid rewriting identical bKGD chunk
-
Viatrix created ticket #85
1-, 2-, and 4-bit greyscale modes ignored
-
Unused palette entries not removed
-
Marc created ticket #64
Show filename in case of incorrect file
-
NRK posted a comment on ticket #4
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
-
toptee posted a comment on discussion Help
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)
-
Sami Farin posted a comment on ticket #82
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.
-
Rafał M posted a comment on discussion Help
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 )
-
Jan O posted a comment on discussion Help
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
-
He Xintong created ticket #62
Add support for APNG
-
uis created ticket #61
Add palette
-
ioctl created ticket #83
Incorrent "-o" parameter treatment
-
f2d2 posted a comment on ticket #66
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.
-
Aymeric Blot created ticket #10
Always use default compression window size
-
CtrlZ created ticket #82
Optipng doesn't support non-ASCII filenames
-
gbrisbine created ticket #81
Misspelling in "A guide to PNG optimization" article
-
BILLY NOAH created ticket #80
Output goes to stderr instead of stdout
-
robpats created ticket #79
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.
-
Christoph Päper posted a comment on discussion Help
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.
-
Some Guy created ticket #78
Doesn't like some TIFF files
-
RavenWorks created ticket #60
Stop compression trials once goal filesize is reached
-
Dummy Void created ticket #59
Support Unicode and Wildcard
-
Hongxu Chen posted a comment on ticket #77
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
-
Ahmad AlMughrabi posted a comment on ticket #72
Hi, any update on this item?
-
freshlydog created ticket #58
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...
-
winston smith posted a comment on ticket #75
Help?
-
Behemot posted a comment on ticket #73
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
-
Strobe created ticket #74
-clobber with -out option creates unexpected backup files
-
taroxd modified a comment on ticket #73
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...
-
Henri Salo created ticket #71
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
1 >