There are some bugs in PNGOUTWin that cause the program to return corrupted images. I found them by setting PNGOUTWIN to "keep all chunks".
- Images deflated using the "Uncompressed" method don't save properly when there are ancillary chunks that it's supposed to keep.
- PNGOUTWin doesn't save images with bKGD chunks properly, although it seems to be OK with other chunks. I guess this is because PNGOUTWin has to handle background chunks intelligently, in case the color type or palette index changes.
I tried a small bit of experimenting, and here are the results I got from it:
Color type 0: Seems to be OK
Color type 2: Corrupt image
Color type 3: PNG writes OK, but can get the palette index wrong
Color type 4: Seems to be OK
Color type 6: Corrupt image
I think you should add in a "sanity check" routine that performs a few simple checks before writing a PNG - for example, verifying chunk names and CRCs, and making sure the file doesn't end unexpectedly - to make sure that the program doesn't write corrupt PNGs. Especially when it's set to overwrite the original image.
David at
Re: PNGOUTWin Bugs
counting_pine said
[...]
I think you should add in a "sanity check" routine that performs a few simple checks before writing a PNG - for example, verifying chunk names and CRCs, and making sure the file doesn't end unexpectedly - to make sure that the program doesn't write corrupt PNGs. Especially when it's set to overwrite the original image.
Thank you for the suggestions.
I recently added very low level checks to the debug builds that include CRC, PNG spec, and DEFLATE checks using ZLIB. As you found in the beta, CRC checks don't catch all that much: the corrupt files created with the longest match strategy passed all CRC checks.
We are working on the fixes to these issues, and I will add these cases to our regression tests.
counting_pine at
PNGOUTWin Bugs
That is good news. Making sure thorough checks should pretty much guarantee the validity of the file.
I've just checked the license and it says ZLib can be used in commercial software if you acknowledge that you use it, so will this feature make it into the next release?
Will it compare the image data with the original image, or will it just check that the file is valid?
Also, will it do any checks on the input file? PNGOUTWin has been known to crash while reading in files.
David at
Consistency checks
counting_pine said
That is good news. Making sure thorough checks should pretty much guarantee the validity of the file.
I've just checked the license and it says ZLib can be used in commercial software if you acknowledge that you use it, so will this feature make it into the next release?
Will it compare the image data with the original image, or will it just check that the file is valid?
Also, will it do any checks on the input file? PNGOUTWin has been known to crash while reading in files.
This is in the internal debug-only build, and not in the commercial shipping product. Not all of the code used in the consistency check is in the public domain--pngcheck is used as well, and none of this code ends up in the commercial version.
counting_pine at
PNGOUTWin Bugs
OK, I understand now, thanks.
Hopefully, since PNGOUTWin is officially out of beta now, there won't be (m)any more major bugs.
Awesoken at
Hey counting_pine,
I think I've fixed all the bugs you mentioned above but I'm lacking good test images to try it with. Would you mind sending me some samples?
I'm most interested in this case:
Color type 3: PNG writes OK, but can get the palette index wrong
Thanks in advance : )
counting_pine at
I suggest downloading the PNG test suite from http://www.libpng.org/pub/png/pngsuite.html
The images with background chunks are:
tbbn1g04.png, bgbn4a08.png, bgwn6a08.png, tbbn3p08.png, tbgn3p08.png, tbrn2c08.png, tbwn3p08.png, tbyn3p08.png, bggn4a16.png, bgyn6a16.png, tbbn2c16.png, tbgn2c16.png, tbwn1g16.png
Any image ending in "16" is a 16-bit image. I'm not sure if PNGOUTWin supports them. There are also some corrupt images, I think they all begin with "x". Check the document included in the zip file for more details about what's there.
For more "miscellaneous" testing images, I'd just take existing images and add chunks manually with TweakPNG.
ace_dent at
Quality Assurance
It's great to see this product developing.
However, as a potential 'customer' I'd like to just say that reliability would be one issue that would stop me buying / using POW. I think for most website developers, the compression of images by ~20% would be cool, but *any* chance of corruption would mean it just isn't worth the risk. I would love to run POW against the several thousand images that are contained in OpenOffice.org, but frankly cannot afford the time to hand check every image (again).
It really is necessary IMHO to add a 100% Quality Assurance mode. This should render both the original and final optimized png, comparing the images pixel for pixel.
Regards,
Andrew
ace_dent at
Corruption of greyscale images
Using the latest version (downloaded today), I'm finding some greyscale images are getting corrupted. Generally just alpha is being lost, but sometimes the palette seems to get broken.
Examples can be found here:
http://people.bath.ac.uk/ea2aced/OOo/POW.zip
My Settings:
- Colour type: All ticked (except auto)
- Filter: All
- Palette Order: All
- Block Split: Auto, {0,8,16,32,64,75,80,90,100,128,140,170,200,240,256,280,360,512,700,1024,1100,1600,2048,3000,4096}
- Huffman Tabs: All
- Bit depth: All
-KSFlate : All
Many thanks,
Andrew
PS- Please include build number in addition to version in the About box, as this is useful for bug reports.
David at
Re: Corruption of greyscale images
ace_dent said
[...]
PS- Please include build number in addition to version in the About box, as this is useful for bug reports.
I agree--I added this earlier this week when I put up the changelog page on the web site.
counting_pine at
PNGOUTWin Bugs
I managed to narrow that down to just the default settings, but with the palette option.
I think I know the problem here:
If PNGOUTWin takes the original palette for a greyscale (0 or 4) image, it just has a palette filled with all the greyscale colours from 0 to 255.
When the Palette Order is set to "Preserve" or "Optimize", then it starts with that palette (with the latter option, removing any colours that aren't there.) But that palette doesn't contain any non-opaque colours.
The resulting behaviour is that for "Preserve", it seems to map each colour to the palette index that has the right grey value. For "Optimise", it seems to group all the non-opaque colours together and place them at index 255.
(It seems to abort with an error before getting this far if it detects that there are too many colours (grey/alpha combinations) to fit into a palette in the first place)
I tried converting a grey+alpha image to palette using PNGOUT /C3 /KP, and the same thing happened as with PNGOUTWin, so that sort of confirms the behaviour; it's a bug in both.
counting_pine at
What would be really useful is a tool that can compare images, and tell you if they're different or not.
I whipped up a batch file to do the same thing. It uses PNGOUT to convert both images to RGBA format, and then compares those two files. If two images are the same, PNGOUT should make the same file for each one.
I've set it to pause iff it comes across a difference, which should be handy if you set up a batch file to run it on a set of images.
echo Comparing
echo.
fc /b "%temp%\1.png" "%temp%\2.png" > nul
if errorlevel 1 (echo Images are different! & pause) else (echo Images are the same.)
del "%temp%\1.png"
del "%temp%\2.png"
Edit: This batch file assumes PNGOUT is in your %PATH% somewhere. You might have to specify its folder explicitly.
David at
New Build
1.0 Build 60516 is now on http://www.pngoutwin.com
Changes for this build.
+ Display total bytes saved in the status bar
+ Accept file names or folder name on command line to support "Send To"
+ Paste of file that was copied from explorer adds file to list
* Fix: Issue with background chunks
* Fix: Don't accept 16 bit extended PNG images
* Fix: Issue with images having all transparent pixels
* Fix: Issue with pasted images and compression
ace_dent at
PNGOUTWin Bugs
David,
Does this build also fix the greyscale issue I reported earlier, (fixed in Build 60512) ?
Cheers,
Andrew
PS- Surely you're getting towards version 1.0.1 ? :)
David at
Build 1.0 60512
ace_dent said
David,
Does this build also fix the greyscale issue I reported earlier, (fixed in Build 60512) ?
Cheers,
Andrew
PS- Surely you're getting towards version 1.0.1 ? :)
Yes, this also fixes the greyscale issues. I'll have to add that to the release notes. Thanks.
My version scheme is major.minor.documentation.build. If there were more digits, then I could probably have called it a .0.1. release.
counting_pine at
PNGOUTWin Bugs
Ken's also posted up a new version of PNGOUT.EXE. Among many other things, it also fixes the /c3 /kp bug with partially transparent greyscale images.
counting_pine at
Bug in the new version of PNGOUT.EXE
With small images, trying large numbers of block splits (not necessarily more than the number of byte in the image,) or very small numbers for the block split threshold, can cause the program to quit unexpectedly during the block splitting process.
I don't know if the bug can be reproduced for more sensible settings, but most images seem to crash if you try to compress it with something like /b1e-5.
As you can't specify non-integer thresholds or the number of block splits in PNGOUTWin, I couldn't get it to crash there, so PNGOUTWin is pretty much immune. If I can't get it to crash there, probably noone else will : )
Awesoken at
PNGOUTWin Bugs
I updated PNGOUT & KZIP on my site with the fixes. The sudden quit happened when it was trying to split a 1 byte block, giving an error condition that was being confused with the ESC keypress logic.
counting_pine at
Thanks.
I hadn't actually realised the problem affected KZIP as well, but looking at it again, it could produce empty blocks at the beginning, and the resulting deflate stream was corrupted. Hopefully that's fixed now.
I also notice the new version puts a block count at the end of the block boundary list, which is nice.
Sometimes if you ask for a large number of blocks, it doesn't split into as many blocks as you asked. Is this a safeguard against 1-block splits?
Awesoken at
Sometimes if you ask for a large number of blocks, it doesn't split into as many blocks as you asked. Is this a safeguard against 1-block splits?
Correct. I don't allow 1-byte blocks to be split. /n# doesn't guarantee the total number of blocks you requested.. but this reduction only happens in cases where it would be silly.
David at
PNGOUTWin update
A new PNGOUTWin has been released to the website with the following changes:
* Fix: Updates strategy names to reflect new defaults
* Fix: Missing DLLs issue on fresh OS installs
* Fix: Issue with block split and cancel code conflict