I don't like the additional chunk as the PNG files size will be huge, even if compressed.
Of course size is a consideration. But there is very little overhead to a chunk. And LIBPNG contains everything needed to define and implement compressed chunks, as you know. That might help a lot.
Another view is to use my algorithm for generating true colour palettes and to such for and remove duplicates and only save the lookup table.
We can certainly define a palette compression scheme similar to the one Fractint uses now for PAR files. We can also leave holes in the palette and have fractint interpolate through the holes, but that would require saving an index as well. Finally, palettes could be specified algorithmically via something like the formula parser. I don't think these issues are a hold-up, though you might disagree. We could define some simple temporary thing that is not optimized for space, and refine it later. The biggest obstacle from Jonathan and my points of view has been an adequate port to a flat memory model with reasonable performance and with preservation of the current feature set, which if overcome would let us retire the medium model version. If we fix those things and the license, we can probably attract new developers. And of course an even bigger obstacle is that I haven't helped Jonathan for about five years :-) Tim