Rich wrote:
I guess I'll have to wait until you expound upon this later, though.
The simple answer is that PNG has a very disciplined philosophy about official chunks. A lot of effort goes into defining them, then they don't change, rather new ones with a new name get created. Contrast this with fractint's use of a version. There is a lot of complex logic in fractint needed to accomodate changes in the data that happened over time based on the current version. This is what the PNG team wanted to avoid.
Beyond what is stored in the GIFs, why would PNG be any different?
Using the GIF extension block feature of PNG should be easy. This was added because our biggest concern was making migration from GIF to PNG easy. However sticking to the original GIF extensions in PNG will really hold us back. Storing data in PNGs is a pretty complex topic, harder than one might think. Greg Roelf's book "PNG, The Definitive Guide" is a big help. The chunks in question are gIFg and gIFx. The fact that fRAc is officially registered may be a big help eventually. Here's an interesting quote from Greg's book (in the paragraph on fRAc). "But for technical reasons relating to Fractint's 16 bit origins, PNG support was not added as planned, so design of the fRAc chunk was deferred pending a rewrite of the program as a 32-bit application" :-) Tim