Does anyone else's computer crash while running pngout /b-1 on this image?
http://img36.exs.cx/my.php?loc=img36&image=sample1yj.png On my (WinNT4) computer it crashes near the end with a Dr. Watson box.
I've tried it on a different computer with Windows XP, and it seems to be better behaved.
EDIT: I've realised, it doesn't actually work on the WinXP computer either, but doesn't bring up a dialog box when it crashes, it just exits.
markcramer at
Yes, it crashes on my Win2KSp4 box as well, Pngout (05/02/26)
The instruction at "0x004076d9" referenced memory at "0x01b98000" Then memory could not be read.
Ken, the 2005/02/19 and 2005/02/11 crash the same way, the 2005-01-03 versions don't.
Dioxaz at
I can recognize here the sample image shipped with the TweakPNG utility made by Jason Summers.
Except that it's 16-color paletted here.
On Windows 2000, pngout doesn't seem to crash... the program seems to terminate normally, with the same "output size" as the one markcramer got.
edit: it deosn't display an error message but doesn't display the "unable to compress further" message either at the end of the process.
I managed to re-convert back the image to 8-bit paletted instead of 4-bit. PNGOut terminates normally and displays the "unable to compress further" message this time (always using the /b-1 commutator).
Suprisingly, as 4-bit paletted, the image compresses better without using trial and error. I came with a file size of 6432 bytes.
But, the best part of it? This image fits into the category of the ones that compress better with 8-bit than with 4-bit color depth: 6 098 bytes of file size. The 8-bit version of the image can be found here.
counting_pine at
It also crashes if you try to output to a different file. (This is a handy way of telling if it's crashed, because if it has, it won't write the file).
This problem doesn't seem to happen if you use /force. I guess this, and the fact that it only happens with recent builds, means it's something to do with the recently-added 'no compression' feature, and the file-size comparison.
This problem isn't restricted to /b-1. I have found another image that crashes it on /b1, and other low /b's.
I'd suspect that using low (non-zero) values for /b (which people rarely do because the compression level isn't usually as good) is more likely to make the compressed image result in a particular state that pngout doesn't cope well with.
Maybe it's possible, although highly unlikely, that it could happen on an image under normal compression. (It would probably have to be one that compressed better under 'no compression', which I guess is, in itself, uncommon.)
Awesoken at
Thanks for the feedback, everyone. I have found & fixed the bug. It was because I wasn't checking the output buffer size before doing the recently added 'no compression' feature. The new PNGOUT should no longer crash.
counting_pine at
Thanks for the update. The bug seems to be fixed now.
But... now it seems to crash on /i ...?
Awesoken at
Oops.. that was a stupid bug in the new code I just wrote. It's been fixed & updated. Thanks for finding & mentioning it.
counting_pine at
OK, thanks. Both things are working fine now
:)
BarrenSoul at
isn't pngout not supposed to make a file if it's larger then the original???? it just did, I just converted a JPG with /c2 and it output a larger file
Awesoken at
No. If my code worked like you say, you would have to specify /force for nearly every JPG file.. and that would be annoying. The "no overwrite" logic only applies to re-compressing PNG files when the following conditions are true:
* input is .PNG file
* output size >= input size
* output filename == input filename
* /force not specified on command line
BarrenSoul at
mabe an /over [0,1] option could replace force, with 1 as force and 0 as the original <= final version for all file formats
and when /over is not specified your program uses it's current behaviour.
Dioxaz at
BarrenSoul said
isn't pngout not supposed to make a file if it's larger then the original???? it just did, I just converted a JPG with /c2 and it output a larger file
A PNG can hardly be smaller than the corresponding JPEG.
Except... if the original JPEG is "100%-quality" and PNG format more appropriated considering its content.
counting_pine at
If you have an NT-based Windows, you can do it with a batch file. This should work:
pngoutover0.bat
@echo off
setlocal
:do_shift
if not %3*==* (set params=%params% %3 & shift /3 & goto do_shift)
pngout %params% %1 %2
if exist %2 (if %~z2 GTR %~z1 echo %2 bigger than %1 - deleting...&del %2)