Re: [Fractdev] introduction and questions
Hi Rich,
Yes, I understand, but an iteration count/pixel is just another "image", with each pixel being a 16-bit value, right? This involves taking a PNG image and storing the iteration count as another PNG image inside a custom chunk.
OK I understand. I see where you are coming from. Would we use the fRAc chunk for this? We need to define a few standards before we go in too deep. Any comments? Thanks, Paul. ---------------------------------------------------------- Paul de Leeuw Computers Central Coast Australia Email: pdeleeuw@deleeuw.com.au www: http://www.deleeuw.com.au ABN 72 360 822 562 ----------------------------------------------------------
In article <d174dd4b87.d4b87d174d@bigpond.com>, pdeleeuw <pdeleeuw@telstra.com> writes:
OK I understand. I see where you are coming from. Would we use the fRAc chunk for this? We need to define a few standards before we go in too deep.
I'm not sure if the contents of the fRAc chunk were ever defined. Tim, can you comment on that? You could always make an application-specific chunk. There is the possibility of chunk name clashes with other apps, so I think the libpng folks recommend registering chunks through them somehow. Its been a while since I looked at that, its probably in the libpng docs somewhere. -- Ask me about my upcoming book on Direct3D from Addison-Wesley! Direct3D Book <http://www.xmission.com/~legalize/book/> izfree: Open source tools for Windows Installer <http://izfree.sourceforge.net>
Rich asked:
I'm not sure if the contents of the fRAc chunk were ever defined. Tim, can you comment on that?
Not defined, but I am the owner, so we can define it it. I don't think defining fRAc is that urgent. I would rather do any temporary thing to store data, and when we are clear what we want to store, then define fRAc. The hardest part is honoring the PNG philosophy of "no versions". This means that we decompose the data into subsets that once defined and named will never change. Change is accomplished by creating new items with new names. At one time my thought was to define the notion of "subchunk" within fRAc, and support PNG's philosophy that way. That is, do define a number of never-changing subchunks such as "corners". A real simple way to proceed at first is to write something like a PAR into a comment field or application-specific chunk. Since fRAc has been reserved, I really want to do it right. Originally I imagined that fRAc would be application-independent. That may be a pipe dream. On another subject, it would be very exciting to see what 3D functionality you could contribute. Tim
In article <3DCC1177.29846.5B5FC6@localhost>, Tim Wegner <twegner@swbell.net> writes:
On another subject, it would be very exciting to see what 3D functionality you could contribute.
Oh, there is really an endless list of 3D stuff that can be done. For starters, 3D IFS, 3D L-systems, DEM surfaces, the cubic-connectedness locus, volumetric rendering. Not to mention new techniques of rendering applied to standard 2D data: arbitrary numbers of layers blended together with texturing HW, real-time image rotation at arbitrary angles ('cause its just a textured quad at that point), real-time zooming (just scaling a quad). Decoupling display rate from computation rate gives you trivial "real-time manipulation" with modern hardware. -- Ask me about my upcoming book on Direct3D from Addison-Wesley! Direct3D Book <http://www.xmission.com/~legalize/book/> izfree: Open source tools for Windows Installer <http://izfree.sourceforge.net>
On Fri, 8 Nov 2002, Tim Wegner wrote:
I don't think defining fRAc is that urgent. I would rather do any temporary thing to store data, and when we are clear what we want to store, then define fRAc.
Using the gIFx chunk would be an easy temporary solution. Does anything besides Fractint read Fractint's extention block now?
items with new names. At one time my thought was to define the notion of "subchunk" within fRAc, and support PNG's philosophy that way. That is, do define a number of never-changing subchunks such as "corners".
A real simple way to proceed at first is to write something like a PAR into a comment field or application-specific chunk. Since fRAc has been reserved, I really want to do it right. Originally I imagined that fRAc would be application-independent. That may be a pipe dream.
Here's what I'm thinking right now... Some of the data about a fractal we need to present in such a way that it will be of use by other fractal programs; This would be the public fRAc chunk. And then some data is of no use by anything but Fractint, that could be stored in a private block, and ignored by everyone else without harm. If done right then PNGs generated by other fractal programs could be useful to fractint, of course. I'm wondering about a good way to record what the type of fractal is or it's formula without having a huge table of arbitrary types as fractint has now. We could store the fractal type as a parsable formula string, then anyone who needed to know it would have to decode a structured grammer, which is a bit more work. The formular parser in Fractint does this now. (This would also only apply to iterated functions in {C:z} and not weird stuff like line systems) Indefinite precision numbers would also need to be represented somehow. Not everything would need to be included in every file (like the 3-D stuff) How close does the public chunk description of the fractal need to match in order for other people to make use of it? (continue calulations or zoom from there or whatever) The sub-chunking is probabily the best way to handle storing all of this. It's rather like how everyone else does file formats there days (ID3v2, RealMedia, PNG) And it's much better than XML for this :P
On Fri, 8 Nov 2002, Rich wrote:
In article <d174dd4b87.d4b87d174d@bigpond.com>, pdeleeuw <pdeleeuw@telstra.com> writes:
OK I understand. I see where you are coming from. Would we use the fRAc chunk for this? We need to define a few standards before we go in too deep.
I'm not sure if the contents of the fRAc chunk were ever defined. Tim, can you comment on that?
You could always make an application-specific chunk. There is the possibility of chunk name clashes with other apps, so I think the libpng folks recommend registering chunks through them somehow. Its been a while since I looked at that, its probably in the libpng docs somewhere.
From http://www.libpng.org/pub/png/spec/pngext-1.2.0-pdg.html --8<------------
Chunks can be marked public and private. I think only the Public ones need to be run by them. 4. Chunks Not Described Here The definitions of some public chunks are being maintained by groups other than the core PNG group. In general, these are chunks that are useful to more than one application (and thus are not private chunks), but are considered too specialized to list in the core PNG documentation. 4.1. fRAc Fractal image parameters The fRAc chunk will describe the parameters used to generate a fractal image. The specification for the contents of the fRAc chunk is being developed by Tim Wegner, twegner@phoenix.net. In the future, chunks will be fully specified before they are registered. -------------- Also of Interes, this looks like it could be used to store the iteration counts and stuff.... 3.2. pCAL Calibration of pixel values When a PNG file is being used to store physical data other than color values, such as a two-dimensional temperature field, the pCAL chunk can be used to record the relationship (mapping) between stored pixel samples, original samples, and actual physical values. The pCAL data might be used to construct a reference color bar beside the image, or to extract the original physical data values from the file. It is not expected to affect the way the pixels are displayed. Another method should be used if the encoder wants the decoder to modify the sample values for display purposes. And I believe that Fractint currently stores it's info in a GIF Extention block, so as an interum solution until fRAc is defined is.. 3.5. gIFx GIF Application Extension The gIFx chunk is provided for backward compatibility with the GIF89a Application Extension. The Application Extension contains application-specific information. This chunk contains: [blah blah blah]
3.5. gIFx GIF Application Extension
The gIFx chunk is provided for backward compatibility with the GIF89a Application Extension. The Application Extension contains application-specific information. This chunk contains:
[blah blah blah]
When we started this conversation, I had forgotten about this chunk, even though I was a advocate and author of it at the time :-) This is exactly what gIFx is for, you facilitate migrating from GIF to PNG. For starters we can use gIFx. It's not a permanent solution, but will allow things to work while fRAc is defined. Tim.
participants (4)
-
Cute Skunk -
pdeleeuw -
Rich -
Tim Wegner