Against all probability, I've just discovered two bugs with one image.
1) PNGOut doesn't handle tRNS chunks well on low-bitdepth greyscale (c0) images. When making a c0 image of bit depth < 8, if white is transparent, it will write 255 (instead of 2^d-1) in the tRNS chunk. When reading a c0 image of bit depth < 8, it will ignore the tRNS chunk and make the image opaque.
2) When using /k1, if there are any ancillary chunks after the IDAT chunk, PNGOut seems to write the wrong length for the recompressed IDAT chunk, resulting in the IDAT "engulfing" the subsequent chunks. It gives the PNG file the appearance of losing its extra chunks and having an IDAT chunk with the wrong CRC and extra compressed data.
BarrenSoul at
:) we all beta testers. PNGOUT is a great program so lets make it better ;)
counting_pine at
A couple of small bugs...
When pngout checks whether an image with transparency can be converted to colour type 0 or 2, it seems to check that only one colour is transparent, but it doesn't check whether all the pixels of that colour are transparent. This can lead to parts of the image being transparent when they're not supposed to be.
If you try and save an image with options that it can't be saved with (e.g. saving a colour image as greyscale or saving an image at too low a bit depth), and specify the /force option, pngout writes a zero-byte file and causes an error.
Awesoken at
Thanks for the bug reports, counting_pine. I don't know how you manage to find all these rare bugs. You must sure use PNGOUT a lot! I have fixed both bugs (hopefully) and posted a new version of PNGOUT on my website.
counting_pine at
Yeah, the PNG format interests me a lot, and I find I end up doing a lot of experimenting on a lot of different images. I'm trying to write my own PNG compressor, and I've found there's a lot of stuff to take into consideration when doing it. It seems to be more of a headache worrying about PNG specs than the deflate compression.
Anyway, thanks for the update. The /force bug is fixed, but pngout's still having problems with transparency. Now it doesn't seem to check that there's only one transparent colour.
I guess it's difficult to cut corners on the check and get away with it. You have to check that only one colour's transparent, then check it's always transparent. It probably needs two passes, or a large array, or something.
Did you see my first post, by the way?
Awesoken at
Yes, I did overlook your first post. Whoops! My bad. Ok, all 3 bugs should be fixed now. Please download & try again. : )
counting_pine at
Thanks, the first two bugs seem to be fixed :)
I think you've nearly got the transparency issue sorted, but now it seems to be finding transparency in opaque images.
Awesoken at
Dammit... I think I found the problem and fixed it. Give it another try and hopefully this version should be good until your next bug report : )
counting_pine at
Yes, I think it's all fixed now, thanks :)
counting_pine at
Oh, hang on...
pngout is misquoting the output size. It only seems to count up to the end of the IDAT chunk.
I guess this is a side effect of the /k1 bug fix?
(Don't think of this as my next bug report, just as a postscript to a previous one :)
Awesoken at
Oh, you're right. How embarrassing. : P Fixed & updated.
counting_pine at
Sorry, Ken, found another bug
This one happens when you try and keep specific anciliary chunks.
For example, if you try pngout /v /kbKGD on an image with a bKGD chunk, pngout seems to get the wrong chunk length, and picks up a lot of bogus chunks.
As always, thanks for the bug report. I have fixed it & updated PNGOUT on my website.
TX at
Awesoken said
As always, thanks for the bug report. I have fixed it & updated PNGOUT on my website.
The other day I asked JonoF what you were working on lately, and he replied that he didn't know -- perhaps the answer is "fixing counting_pine's PNGOUT bugs." :) Perhaps a new Linux build of PNGOUT will be available from JonoF soon? It seems like there have been quite a few significant fixes since the last build.
JonoF at
I got an update to the PNGOUT code from Ken a couple of weeks ago but clean forgot about building the update a couple of days after. I'll get a new build up with these updates asap.
Jonathon
Awesoken at
TerminX, feel free to write me directly. When people ask me what's up, I usually just copy & paste some text from a previous E-mail response. It usually goes something like this:
Here's a few things:
* JFBuild (http://jonof.edgenetwork.org): Occasional bug fixes.
* Pngout (http://advsys.net/ken/utils.htm#pngout): Occasional bug fixes.
* MoonEdit (http://www.moonedit.com): Developing a plugin with Tom Dobrowolski.
* Evaldraw (http://advsys.net/ken/download.htm#evaldraw): This project is dormant at the moment, but I have plans to upgrade the compiler.
Obviously, that isn't descriptive enough to cover my day-to-day doings. Still, it's good enough for most people.
There have been no significant changes to PNGOUT since 2004. All the recent changes have been bug fixes for Counting Pine's rare images.
Martin at
http://img43.echo.cx/img43/7792/littleman7nl.gif
Converted into PNG (using PNGOUT, of course), it's sized 541 bytes, and when you do PNGOUT again, it compresses further to 540 bytes. I wonder why it is not compressed to 540 bytes on the first run.
Awesoken at
By default, PNGOUT starts with the input file's palette and swaps palette indices after each pass as it sees fit. If you want a stable file size, you can specify /c3 explicity at the command line. Doing this forces PNGOUT to generate a palette from scratch. You'll get a consistent file size this way, but it's not always as good as starting with the input file's palette.
counting_pine at
536 bytes.
This is sort of unrelated, but I've noticed that sometimes PNGOut always seems to output the last pass of the image. This is normally the best pass, but occasionally an earlier pass might get a smaller size.
It's quite rare that this happens and it's generally not a huge saving. I also suspect that PNGOut saves memory by not caching previous passes, so I guess asking for PNGOut to output the smallest pass is more of a feature request than a bug fix.