Sometimes, yes. But JS PNG fixes are just scripts manipulating the DOM and using the DirectX AlphaImageLoader filter (that you can use with the filter or -ms-filter property in CSS). And that filter is real nasty. It has a handful of hard to manage and sometimes impredictable side effects. After using it for many projects, both manually and through JS scripts that automate the process, i know hold it a mistake to use it at all: too much trouble, really. Plus it has some performance issues.

There is one JS script that loads PNG images through VML that seems to have less limits and side effects. I have not used it in production yet.

But the point is: the bKGD chunk is not added automatically by image editors. If it’s present, it’s because someone choose to include it for a reason. So there is no reason to strip it.

Now, about the other kinds of color information chunks: i’m not sure what every editor out there does. I encounter PNG files with iCCP, sRGB or gAMA chunks from time to time (though not very often), and it’s nice to have a decent tool to remove them for a bunch of files. For me, making sure these chunks are not there (while the occasional bKGD chunk is kept) is part of readying images for production, along with filesize optimization.

As for open-sourcing, I know many people have asked for it, but there are two main reasons I’m not releasing it to the public just yet.

1) I don’t have much time to maintain an open-source project. If you know of anyone who would like to help I’d be happy to work with them. However, I do have some strong preferences about the design and user experience of the software, and would love to focus most of effort on there rather than merging code.

2) Punypng has a lot of dependencies. After upgrading to Snow Leopard, I’m still re-compiling all my libraries to get punypng running again on my laptop … which I hope I can get to today. One of the reasons I made punypng for my team here at Ask.com and my church (Gracepoint Berkeley) is that few web designers have the chops to manage a half-dozen UNIX packages let alone shell. It’s been 10 years since I coded C/C++ skills, so it also doesn’t look like a binary is going to happen soon either. Plus, I’m not sure I want to release a command-line binary because that’s what I hated about pngcrush, pngout, optipng, and the mix of them. It took too long and complicated to process my images from the command line.

So what I am planning on is creating a JSON API to interact with the punypng service. Will punypng be around forever. Probably not, but at the same time, I think it’s worth using now in your workflow and if one day it goes away, well, find another tool to suit your needs. Like you, I was an avid Smush.it can until Yahoo took over and killed Stoyan’s original interface. That’s why punypng was created, to replace that need in my workflow and go beyond what Smush.it was and I’m sure if some tragic would happen to punypng then I’m sure someone else will pick up the mantle.

As for your issues about punypng and other tools stripping out the bKGD chunk for IE6 compatibility, wouldn’t it better to use a JS PNG fix/hack to get your PNG to show in their full glory rather than worry about graceful degradations? Also, perhaps I misinterpret your comment, but from what I understand, web-friendly images should have no color information (ICC profile) embedded… which is why even something like Photoshop Save for Web strips out ICC information from all its images.

First, thank you for that useful tool. I had been using Smush.it for a while, then Yahoo integrated part of the tool in Yslow and basically killed it.

I have two concerns with punypng (in addition to the restrictive and somewhat misleading name):

1. What happens if punypng disappears? Web designers and front-end developers need that kind of all-in-one tool, but there’s no guarantee it’ll be available tomorrow. Smush.it was killed by Yahoo. Including punypng in one’s workflow is somewhat risky. Possible solutions include distributing binary packages and/or open-sourcing the tool.

2. One of the advantages of Smush.it was that it would strip problematic color information from files (PNG mostly, but i think JPEG had some issues with ICC color profiles either embedded or referenced). Most color information in PNG files are unnecessary for websites, and may cause color consistency issues in Internet Explorer, Safari and Firefox (especially since color management is on by default in FF 3.5 for tagged images). For PNG, Smush.it would remove the following chunks (and maybe others, but these are the only color-related ones i know of): gAMA, cHRM, iCCP, sRGB, bKGD. This avoids a lot of color rendering issues where CSS background-color won’t match the exact same color in an image ( tag or CSS background-image). The only problem is that removing the bKGD chunk is a mistake: that chunk, that you can set with graphics editor such as The Gimp or using a PNG optimization tool, is useful as it can work as a default matte color for a PNG-24 image in Internet Explorer 6 (a nice graceful degradation trick). So i would suggest that punypng strips the gAMA, cHRM, iCCP and sRGB chunks, but keeps the bKGD chunk. Right now all of them are kept.

If you’re interested in reading more about Image Optimisation for the web, Stoyan Stefanov (Yahoo!) has some good slides at http://www.phpied.com/image-optimization-7-mistakes/

@oncletom: once I finish the API, I’ll look into getting a binary to use punypng from the cmdline