re: [Fractdev] <Paul> Recoloring an RGB triplet-colored fractal at a later time.
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/
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/>
In article <E1HEFoQ-0003OC-00@xmission.xmission.com>, Richard <legalize@xmission.com> writes:
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. [...]
That should be "64 bits per pixel". -- "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
In article <45C79F83.23567.831EC5@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
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.
Lately I've been wondering if XML might be useful in specifying this sort of thing -- in other words leave the structuring and whatnot to the XML and just have the chunk store a string. Just a thought. -- "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/>
participants (3)
-
charlie chernohorsky -
Richard -
Tim Wegner