In article <45C7D9B9.8050705@seznam.cz>, charlie chernohorsky <endlessoblivion@seznam.cz> writes:

...

[fullscreen] But I gotta be honest and say there's still more plumbing that needs to change before those things are going to materialize.

no hurry here, we just want to be sure that you won't lock the backdoor for such things to be able to sneak in later when their time comes...

With the changes I have in mind, doing such things will be much, much easier than now.

...

So you can encode the iteration counts as a PNG image and stick that in an extension block designed to hold iteration counts.

i'm somewhat aware of chunks (er, a general idea), but even if you hack it to contain a regular png image, still you need a way to make the binary data, something like libpng api.. then, you will need to pretend it's not a grayscale to get more than 16 bits..

You can use PNG to encode 16-bits per channel with up to 4 channels per pixel, so you can use it to compress data that is 64 bits per channel before you have to split it into multiple images. For instance, for 32-bit iteration counts, you take the four bytes of the 32-bit integer and call them r, g, b, and a and you have a "pixel" that would compress well with PNG. You're still exploiting the 2D coherency of the iterations this way, its just an odd way to think of a 'pixel'. PNG would do better than zip because it exploits the 2D coherency. zip only knows how to exploit repetitive nature of patterns in a linear space, so its compression dictionary would be off at the end of every scanline and would only recognize compressability within a scanline as opposed to between scanlines for the same x coordinate within a scanline.

glad to hear it.. again, no hurry, just leave the backdoor..

Everything I'm doing is with an eye towards widening possibilities, not constricting them :-) -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

Charlie wrote:

i'm somewhat aware of chunks (er, a general idea), but even if you > hack it to contain a regular png image, still you need a way to make the binary data, something like libpng api.. then, you will need to pretend it's not a grayscale to get more than 16 bits..

I was involved in the development of PNG, and reserved the fRAc chunck for fractal data. I did nothing with it because the memory demands for PNG exceeded what we could do with the DOS fractint. Now we can define it. Tim