Rich wrote:
[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...
There are two things here. The image and the iteration counts. Both PNG and GIF image formats have extension chunks (there's one registered for fractint, but its not been specced out according to Tim).
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..
with infinite iterations (more comes bellow) it's easy to get over 2^32..
OK, I see what you mean now about infinite iterations and I'd already considered that as something that's desirable before.
glad to hear it.. again, no hurry, just leave the backdoor..
The question is -- is it worth having a multiple precision 'int' to store the iteration counts then? (within an image)
oh no, i don't think so, 2^32 is enough, since it's primary use will be recoloring.. (or maybe resuming calculation?) if it's not enough, you can opt for RGBA 16 bits per channel
[SVG / HPGL] When things stabilize (i.e. plumbing changes are done), adding new save formats should be easy. ...I'm reluctant to divert my plumbing activity into new features until the plumbing is done.
..and again, no hurry, just try to keep all those in mind please when making any architectural decisions concerning plugability.. good-nite /charlie/