ftp.xmission.com/2014.06.ftp.xmission.com.tar/ftp.xmission.com/pub/lists/fractdev/archive/fractdev.200003

Internet Message Format | 2000-03-23 | 35KB

From: Ron Barnett <[e-mail]>
Subject: RE: Truecolor support
Date: 01 Mar 2000 11:07:55 -0500

Woops! I sent the original with my company email address. Hopefully this
one will make it to the list :-}.

-----Original Message-----
Sent:    March 01 2000 10:55

Tim,
Unfortunately, my new job, which started 8 months ago, is totally consuming
my time. I am responsible for developing a new business in a software
(Laboratory Information Management Systems) company and taking courses to
get Oracle DBA certification. I haven't had time to do anything on
truecolor support, let alone dig much into the code. I thought I might pass
on a few concerns/issues.

It is very unlikely that an algorithm which can be used on the final
iteration values can be found which is of general use. The Vepstas
algorithm will work for Mandelbrot type functions, that is, functions which
are essentially iterated power series. Many of the neat functions which
have transendentals, involve complicated complex products or or are conv
ergent fractals like Newton will not yield smooth coloring with the Vepstas
method. The only general method I have found, and no one else has come up
with an alternative, is exponential smoothing. Unfortunately, this method
must be applied at every iteration, starting with the first iteration. I
have tried all sorts of skipping schemes, and none of them give
satisfactory results. The bailout also needs to be set very high (as is the
case with the Vepstas method). For those who aren't familiar with the
method, the basic scheme is the following. Iterexp is used to reference
into a continuous color map.

for diverent fractals:
     iterexp = iterexp + exp(-cabs(z))

for convergent fractals:
     iterexp = iterexp + exp(-1/(cabs(zold - z)))
where zold is the z value from the previous iteration.

I assume this code fragment would have to go in an assembly language
routine for performance. Is anyone actually working on truecolor (and
truecolor is nearly worthless, in my opinion, if you can't make it smooth).
Decomposition and/or potential methods  have some utility (Damien has done
some nice stuff here) , but cannot really be a smooth equivalent to
iteration, which is what, I believe, the users will want.

I apologize If I am going over ground those of you on the developer list
are already aware of. I just wanted to put my 2 cents worth in just in
case.

Ron Barnett

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: "Paul N. Lee" <[e-mail]>
Subject: REQ:  Fractal Census 2000
Date: 17 Mar 2000 23:29:03 -0600

Greetings Fractal Community,

If you would be so kind, I would like to impose upon everyone to take a
moment and please supply some information:

    1.  The number of individuals in your household
        that create fractals.

    2.  The number and names of fractal generating
        programs used by each of these individuals.

    3.  Which fractal program is considered as the
        best or most used by each of these individuals.

Replys are requested to be sent to the following email address:
    MAILTO:[e-mail]

The results will be made available upon completion of the census.

Thank you for your support and co-operation.

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Tim Wegner <[e-mail]>
Subject: Development news
Date: 18 Mar 2000 15:15:44 -0600

The source for the float-only version is now at fractint.org at:

ftp://ftp.fractint.org/frasrcfo20.0.9.zip

The next step is to create an xfractint version based on these
sources. This should not be too hard, and should be a lot cleaner
since many #ifdefs are currently needed to eliminate integer math
from Xfractint.

Scott Boyd has offerred to work a bit on the Xfractint user interface.

Jonathan Osuch and I are gearing up to launch the 32 bit fractint
effort.

Paul De Leeuw has fractint-based Windows truecolor program he is
working on.

The time has come to work out the PNG fRAc chunk. I am looking
into this.

Tim


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: "Paul de Leeuw" <[e-mail]>
Subject: Fractal Chunk fRAc for PNG files
Date: 21 Mar 2000 21:50:27 +1100

This is a multi-part message in MIME format.

------=_NextPart_000_0017_01BF937F.781C1820
Content-Type: multipart/alternative;
    boundary="----=_NextPart_001_0018_01BF937F.781C1820"


------=_NextPart_001_0018_01BF937F.781C1820
Content-Type: text/plain;
    charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Team,=20

My name is Paul de Leeuw, the author of ManpWin. I am interested in =
getting a definition for a fractal chunk in PNG and am interested in =
getting comments on a definition I'm working on.

We should develop a definition which meets the needs of all (and future) =
fractal programs.

Please see attached file.

Comments and suggestions gratefully appreciated.

Many thanks,

Paul.

------=_NextPart_001_0018_01BF937F.781C1820
Content-Type: text/html;
    charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Hi Team, </FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>My name is Paul de Leeuw, the author of ManpWin. I =
am=20
interested in getting a definition for a fractal chunk in PNG and am =
interested=20
in getting comments on a definition I'm working on.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>We should develop a definition which meets the needs =
of all=20
(and future) fractal programs.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>Please see attached file.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>Comments and suggestions gratefully =
appreciated.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>Many thanks,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>Paul.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0018_01BF937F.781C1820--

------=_NextPart_000_0017_01BF937F.781C1820
Content-Type: application/octet-stream;
    name="frachunk.h"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
    filename="frachunk.h"

/***********************************************************************
FRACHUNK.H
Definition of all fractal data to be written to the fRAc chunk
Written by Paul de Leeuw 21/3/2000
***********************************************************************/

#ifndef FRACHUNK_H
#define FRACHUNK_H


struct fractal_info         // for saving data in PNG file
{
/*
This next pointer is to allow the iteration count for each pixel to be =
saved for resumption
of the fractal. As there is no simple reverse method for calculating =
iteration count from
true colour images, the lot needs to be saved. This is very large for a =
standard 1024*768
screen will be 1.57 MBytes if ints are used or 3.15 MBytes if longs are =
used. Hence=20
compression is needed for this data. HELP????????
*/
#ifdef ALLOW_32BIT_ITERATION
    long  *PixelData;
#else
    int   *PixelData;
#endif
   =20
// standard FRACTINT stuff (based on FRACTINT v20.0)

    char  info_id[8];       // Unique identifier for info block
    short iterationsold;    // Pre version 18.24
    short fractal_type;     // 0=3DMandelbrot 1=3DJulia 2=3D ...
    double xmin;
    double xmax;
    double ymin;
    double ymax;
    double creal;
    double cimag;
    short videomodeax;
    short videomodebx;
    short videomodecx;
    short videomodedx;
    short dotmode;
    short xdots;
    short ydots;
    short colors;
    short version;          // used to be 'future[0]'
    float parm3;
    float parm4;
    float potential[3];
    short rseed;
    short rflag;
    short biomorph;
    short inside;
    short logmapold;
    float invert[3];
    short decomp[2];
    short symmetry;
                        // version 2 stuff
    short init3d[16];
    short previewfactor;
    short xtrans;
    short ytrans;
    short red_crop_left;
    short red_crop_right;
    short blue_crop_left;
    short blue_crop_right;
    short red_bright;
    short blue_bright;
    short xadjust;
    short eyeseparation;
    short glassestype;
                        // version 3 stuff, release 13
    short outside;
                        // version 4 stuff, release 14
    double x3rd;          // 3rd corner
    double y3rd;
    char stdcalcmode;     // 1/2/g/b
    char useinitorbit;    // init Mandelbrot orbit flag
    short calc_status;    // resumable, finished, etc
    long tot_extend_len;  // total length of extension blocks in .gif =
file
    short distestold;
    short floatflag;
    short bailoutold;
    long calctime;
    BYTE trigndx[4];      // which trig functions selected
    short finattract;
    double initorbit[2];  // init Mandelbrot orbit values
    short periodicity;    // periodicity checking
                        // version 5 stuff, release 15
    short pot16bit;       // save 16 bit continuous potential info
    float faspectratio;   // finalaspectratio, y/x
    short system;         // 0 for dos, 1 for windows
    short release;        // release number, with 2 decimals implied
    short flag3d;         // stored only for now, for future use
    short transparent[2];
    short ambient;
    short haze;
    short randomize;
                        // version 6 stuff, release 15.x
    short rotate_lo;
    short rotate_hi;
    short distestwidth;
                        // version 7 stuff, release 16
    double dparm3;
    double dparm4;
                        // version 8 stuff, release 17
    short fillcolor;
                        // version 9 stuff, release 18
    double mxmaxfp;
    double mxminfp;
    double mymaxfp;
    double myminfp;
    short zdots;
    float originfp;
    float depthfp;
    float heightfp;
    float widthfp;
    float distfp;
    float eyesfp;
    short orbittype;
    short juli3Dmode;
    short maxfn;
    short inversejulia;
    double dparm5;
    double dparm6;
    double dparm7;
    double dparm8;
    double dparm9;
    double dparm10;
                        // version 10 stuff, release 19
    long bailout;
    short bailoutest;
    long iterations;
    short bf_math;
    short bflength;
    short yadjust;        // yikes! we left this out ages ago!
    short old_demm_colors;
    long logmap;
    long distest;
    double dinvert[3];
    short logcalc;
    short stoppass;
    short quick_calc;
    double closeprox;
    short future[19];     // for stuff we haven't thought of yet

// ManpWin stuff (based on ManpWin v2.6x)
// Note that we could use fractint fields for many of these but I'll put =
in a bit anyhow
// Things like fractal type, inside.. are taken from FRACTINT definition

#ifdef MANPWIN
            // start with complex plane definition
    char *BigHor;        // pointer to BigNum horizontal
    char *BigVert;        // pointer to BigNum vertical
    char *BigWidth;        // pointer to BigNum width
    double hor;
    double vert;
    double width;
    double JuliaReal;
    double JuliaImag;
            // Fractal stuff
    WORD special;        // used for special colours in certain fractals
    BYTE degree;        // for Newton, Power etc
    int LogValue;
    char FractalSubType;    // Some examples of sub types:
                // Newton    B=3Dbasin, S=3Dstripe, N=3Dnormal
                // Bifurcation    Q =3D quad mand, B =3D bifurcation
                // Cubic    B =3D CBIN, C =3D CCIN, F =3D CFIN, K =3D CKIN
                // Rational Map    3 =3D RAT34, 4 =3D RAT44
            // Plotting stuff
    char BlockIndex;        // Higher numbers good for quick view of slow =
fractals
    BYTE PairFlag;        // Pairflag is used to inhibit unwanted rows and =
columns=20
                // to remove excess processing.=20
    int AutoStereoValue;    // AutoStereo depth value
    int biomorph;        // biomorph colour
    int decomp;            // number of decomposition colours
            // 3D stuff
    BYTE _3dflag;        // replay saved file 3D
    double x_rot;        // angle display plane to x axis
    double y_rot;        // angle display plane to y axis
    double z_rot;        // angle display plane to z axis
    double sclx, scly, sclz;    // scale
            // Colour stuff
    BYTE TrueColourFlag;    // Use TrueColour palette generation
    WORD RedStartInt;        // True colour parameters
    WORD GreenStartInt;
    WORD BlueStartInt;
    WORD RedIncInt;
    WORD GreenIncInt;
    WORD BlueIncInt;
    char *PaletteFileName;    // to store palette file name
#endif            // MANPWIN
#ifdef FUTURE_STUFF
    int FilterType;        // Teirazon filter type
    int ConvolutionType;    // Teirazon convolution type
    int ColourType;        // Teirazon colour type: RGB, RBG, BGR, BRG, GRB, =
GBR
    int FDimesnsion;        // More Teirazon stuff
#endif            // FUTURE_STUFF
#ifdef USER_STUFF
    char UserChar1;        // User info
    char UserChar2;
    char UserChar3;
    char UserChar4;
    char *UserCharPtr1;
    char *UserCharPtr2;
    char *UserCharPtr3;
    char *UserCharPtr4;
    int UserInt1;
    int UserInt2;
    int UserInt3;
    int UserInt4;
    long UserLong1;
    long UserLong2;
    long UserLong3;
    long UserLong4;
    float UserFloat1;
    float UserFloat2;
    float UserFloat3;
    float UserFloat4;
    double UserDouble1;
    double UserDouble2;
    double UserDouble3;
    double UserDouble4;
#endif            // USER_STUFF

};


------=_NextPart_000_0017_01BF937F.781C1820--


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Tim Wegner <[e-mail]>
Subject: Re: Fractal Chunk fRAc for PNG files
Date: 21 Mar 2000 07:20:54 -0600

Paul wrote:

> My name is Paul de Leeuw, the author of ManpWin. I am interested in =
> getting a definition for a fractal chunk in PNG and am interested in =
> getting comments on a definition I'm working on.

I have been corresponding for a while with Paul about his program
Manpwin. The time is right to work on the PNG chunk. I'm glad he's
pushing us to get this done :-)

The first job is to define the content. Then there are some technical
issues as to how the chunk should be put together. We don't need
to solve these first (the first job is just to decide what to put in), but
let me get them on the table so everyone is aware, even though the
first job is not the technicalities but the content.

1. PNG has a design philosophy not to use revision numbers. This
means that once a chunk is defined it doesn't change. If you need
something later, a new chunk is created. When fRAc was first
proposed, I discussed this with the PNG team. It isn't practical to
define everything we'll ever need for fractals up front, so I proposed
that the fRAc chunk be designed with "subchunks". Each one of
these would be permanent. That way we wouldn't litter the PNG
chunk  name space with multiple chunks, because all these would
be inside fRAc. This implies that we should identify reasonable
subchunks. The generalized center-mag coordinates would be an
example of something that deserves its own subchunk. We don't
have to do this just because it was the original idea, but it would be
very un-PNG-like to have a chunk with an internal revsion number
and a constantly increasing number of parameters, so we should
try to avoid this. I'll raise this on the PNG list and see if the years
of experience have altered thinking on this.

2. A huge problem with Fractint parameter storage in GIFs is that
we just wrote binary numbers to the GIF file. Anyone familiar with
Xfractint knows that Ken Shirriff had to write all kinds of byte-order
and IEEE floating point conversion routines to decode the fractint
binary numbers. For this reason values should be probably be
written in text. This also would allow seemless support for arbitrary
precision.

3. I do not favor just putting the old fractint parameters in fRAc.
There are some problems in the way we originally did things and
this is a good time to break with the past.

4. Let me point out that PNG does have a system for preserving
GIF extension blocks. I don't know if anyone uses this :-) This
might or might not be a good idea, but for starters we could use
this feature. The original intent was to allow a way to non-
destructively convert GIF to PNG without losing the extension
blocks. It also allows conversion software that doesn't know about
Fractint to convert PNG to GIF. The downside is that time has
gone by, and it might not be worth the trouble to mess with the GIF
extension block chunks. Once fRAc is defined, the conversion
program could convert straight to fRAc. This is another issue we
need to think about.

I have suggested to Paul that he use either a text comment chunk
or make his own Manpwin chunk for now.  You could do a lot
worse than put PAR files in a text block. Note that PNG has
mechanisms for compressed text chunks.

I'll look at this some more this weekend.

Tim


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: Re: Fractal Chunk fRAc for PNG files
Date: 21 Mar 2000 10:35:56 -0700


In article <38D722D6.16261.24C10F@localhost>,
    Tim Wegner <[e-mail]>  writes:

> I have suggested to Paul that he use either a text comment chunk
> or make his own Manpwin chunk for now.  You could do a lot
> worse than put PAR files in a text block. Note that PNG has
> mechanisms for compressed text chunks.

My suggestion is this:

Include (as text, with an option for compression) everything needed to
regenerate the image:

    colormap
    formula definition
    L-system definition
    IFS definition
    parameter settings

One weakness of the previous method of storing information in the
image file was that if the image was generated from a formula, you had
to have the .frm file in order to zoom the image.

I know some artists have relied on this fact to "hide" their formulas
and keep them proprietary.  If that is desired, simply remove the
parameter chunk from the PNG file rather than store an incomplete or
brain-dead parameter block.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.xmission.com/~legalize/who/>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: "Paul de Leeuw" <[e-mail]>
Subject: Re: Fractal Chunk fRAc for PNG files
Date: 22 Mar 2000 23:34:05 +1100

Team,

I am currently using a tEXt chunk for ManpWin to store local versions of the
parameter file and it works fine. The real difficulty I am having is that
true colour images have 16.777 Million possibilities per pixel for 24 bit
colour. Reversable algorithms for determining the iteration count per pixel
is very difficult. Hence it is necessary to store 16 (or 32) bits per pixel
to enable regeneration of the iteration count matrix. This info needs to go
into a special chunk. See below.

Any comments appreciated,

Thanks,

Paul.

/***********************************************************************
FRACHUNK.H
Definition of all fractal data to be written to the fRAc chunk
Written by Paul de Leeuw 21/3/2000
***********************************************************************/

#ifndef FRACHUNK_H
#define FRACHUNK_H


struct fractal_info         // for saving data in PNG file
{
/*
This next pointer is to allow the iteration count for each pixel to be saved
for resumption
of the fractal. As there is no simple reverse method for calculating
iteration count from
true colour images, the lot needs to be saved. This is very large for a
standard 1024*768
screen will be 1.57 MBytes if ints are used or 3.15 MBytes if longs are
used. Hence
compression is needed for this data. HELP????????
*/
#ifdef ALLOW_32BIT_ITERATION
    long  *PixelData;
#else
    short *PixelData;
#endif

bla bla bla
----- Original Message -----
Sent: Wednesday, 22 March 2000 04:35


>
> In article <38D722D6.16261.24C10F@localhost>,
>     Tim Wegner <[e-mail]>  writes:
>
> > I have suggested to Paul that he use either a text comment chunk
> > or make his own Manpwin chunk for now.  You could do a lot
> > worse than put PAR files in a text block. Note that PNG has
> > mechanisms for compressed text chunks.
>
> My suggestion is this:
>
> Include (as text, with an option for compression) everything needed to
> regenerate the image:
>
>     colormap
>     formula definition
>     L-system definition
>     IFS definition
>     parameter settings
>
> One weakness of the previous method of storing information in the
> image file was that if the image was generated from a formula, you had
> to have the .frm file in order to zoom the image.
>
> I know some artists have relied on this fact to "hide" their formulas
> and keep them proprietary.  If that is desired, simply remove the
> parameter chunk from the PNG file rather than store an incomplete or
> brain-dead parameter block.
> --
> <http://www.xmission.com/~legalize/> Legalize Adulthood!
>     ``Ain't it funny that they all fire the pistol,
>       at the wrong end of the race?''--PDBT
> [e-mail] <http://www.xmission.com/~legalize/who/>
>
> --------------------------------------------------------------
> Thanks for using Fractdev, The Fractint Developer's Discussion List
> Post Message:   [e-mail]
> Get Commands:   [e-mail] "help"
> Administrator:  [e-mail]
> Unsubscribe:    [e-mail] "unsubscribe fractdev"


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: Re: Fractal Chunk fRAc for PNG files
Date: 22 Mar 2000 13:15:53 -0700


In article <002501bf93fa$fe27ee00$[e-mail]>,
    "Paul de Leeuw" <[e-mail]>  writes:

> struct fractal_info         // for saving data in PNG file
> {
> /*
> This next pointer is to allow the iteration count for each pixel to be saved
> for resumption
> of the fractal. As there is no simple reverse method for calculating
> iteration count from
> true colour images, the lot needs to be saved. This is very large for a
> standard 1024*768
> screen will be 1.57 MBytes if ints are used or 3.15 MBytes if longs are
> used. Hence
> compression is needed for this data. HELP????????
> */

You can store the iteration count per-pixel as a PNG image with
1-channel and 16-bits/channel for 16-bit iteration counts.

You can pack 32-bits/pixel if you store it as a 2-channel image
(grayscale w/alpha) and store the two 16-bit chunks of a 32-bit
quantity in the two channels.  Similarly for higher bits/pixel.

There is compressible coherency in the iteration count, so by storing
the iteration count as its own PNG image you reduce the disk storage
costs of the iteration count considerably.

However, this leads to two PNG streams: one for the color data and
another for the iteration count data.  Once the image is finished
rendering you can get rid of the iteration count data and just keep
the colors.  (It could be re-used on a zoom if you have a zooming
algorithm that exploits zoom-to-zoom coherency, but watch out for
aliasing; you'll have to do some manual infinite mipmap like tricks to
pull it off correctly.)

You can package the two PNG streams into a single file.  If you do
this, I'd suggest a raw concatenation of the two PNG images with the
color image first.  Then the two PNG streams can't be separated on the
hard drive and the image stream can always be read by PNG aware
clients.  I suppose you could even package up the second PNG stream as
an application specific data chunk inside the first stream, but that
seems more complicated.  I don't know how the png library or image
viewing programs deal with extraneous appended data to the PNG stream;
if lots of programs complain about this unexpected data, it might be
better to wrap the PNG iteration count 'image' inside one or more
application chunks.  (You may need more than one if you overflow the
valid size of a chunk, but I can't recall what that limit is right
now.)
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.xmission.com/~legalize/who/>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: "Scott D. Boyd" <[e-mail]>
Subject: Xfractint menu questions
Date: 23 Mar 2000 22:43:25 -0600

This message is directed to all the Xfractint users out there.

I am working on cleaning up the user interface of Xfractint so that the prompts
are more appropriate to Linux/Unix users. (Such as changing the function-key
prompts to Shift-n prompts. I have a couple of questions for other people
running Xfractint with Linux (or other Unix-based OS's):

1.Can anyone use the `Delete' key for the Main Menu selection: "select video
mode   <del>". In my case, `Delete' doesn't work. I have to press the `Enter'
key only when this menu item is highlighted. (I know we can't select a video
mode, but still I have to press `Enter' to draw the fractal.) If the delete key
works for you, please also let me know what OS you are using. (Linux, HP-UX,
Solaris, *BSD, etc.) I just want to make sure that this isn't happening only to
me because of some hidden, arcane setting in some keyboard-map file.

2. While going thru one of the source files that deals with the main menu, I
realized that everything below "restart Fractint  <ins>" is missing, such as
color-cycling, pallette editing, make starfield, etc. Is this common to all
Xfractint installations? I can remove a certain condition in the source file,
re-compile, and the menu items will show up. Color-cycling still won't work,
(when I press the C key, I get a beep) but the others will.

Please email me with your results. I realize that there may not be many
Xfractint users subscribed to the fractint-development mailing list, so I'm
also posting this to the regular fractint users mailing list. If you are
reading this on *that* list, please respond directly to me, so as not to
clutter up the regular fractint list with answers to a development question.

Thanks,
Scott D. Boyd
--
email:  [e-mail]
http://www.fastlane.net/~sdboyd/
Introducing Windows 2000 !! -- Now reduced to only 65,000 bugs !!



Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: "Scott D. Boyd" <[e-mail]>
Subject: Follow up to my prev. Xfractint questions
Date: 24 Mar 2000 12:21:25 -0600

On Thu, 23 Mar 2000, I asked:
>
> 1.Can anyone use the `Delete' key for the Main Menu selection: "select video
> mode   <del>". In my case, `Delete' doesn't work. I have to press the `Enter'
> key only when this menu item is highlighted. (I know we can't select a video
> mode, but still I have to press `Enter' to draw the fractal.) If the delete key
> works for you, please also let me know what OS you are using. (Linux, HP-UX,
> Solaris, *BSD, etc.) I just want to make sure that this isn't happening only to
> me because of some hidden, arcane setting in some keyboard-map file.
>
I failed to mention that I can also press "D" for this menu item. But the
original question still stands: "Can anyone use the "Delete" key? (My "Insert"
key works, but not the "Delete" key.)

> 2. While going thru one of the source files that deals with the main menu, I
> realized that everything below "restart Fractint  <ins>" is missing, such as
> color-cycling, pallette editing, make starfield, etc. Is this common to all
> Xfractint installations? I can remove a certain condition in the source file,
> re-compile, and the menu items will show up. Color-cycling still won't work,
> (when I press the C key, I get a beep) but the others will.
>
I have discovered that I was having this problem because I wasn't using the
`-private' option when I start Xfractint. I was using `-fixcolors 256' instead.
So no need to answer question #2.

Thanks,
Scott D. Boyd
--
email:  [e-mail]
http://www.fastlane.net/~sdboyd/
Introducing Windows 2000 !! -- Now reduced to only 65,000 bugs !!

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: "Paul de Leeuw" <[e-mail]>
Subject: Re: Fractal Chunk fRAc for PNG files
Date: 25 Mar 2000 09:03:52 +1100

Phil,

I like the sound of this one. If I can get compression, it would be great. I
would insist that if it were to be saved as a PNG file that it would be
viewable by any standard PNG viewer.

Would the two images (real colours and iteration count per pixel) conflict?
How would I set this up (I am a bit new to PNG and have only used the
standard PNGLIB library functions)?

Any help gratefully appreciated.

Many thanks,

Paul.
----- Original Message -----
Sent: Thursday, 23 March 2000 07:15


bla bla

>
> You can store the iteration count per-pixel as a PNG image with
> 1-channel and 16-bits/channel for 16-bit iteration counts.
>
> You can pack 32-bits/pixel if you store it as a 2-channel image
> (grayscale w/alpha) and store the two 16-bit chunks of a 32-bit
> quantity in the two channels.  Similarly for higher bits/pixel.

bla bla

> --------------------------------------------------------------
> Thanks for using Fractdev, The Fractint Developer's Discussion List
> Post Message:   [e-mail]
> Get Commands:   [e-mail] "help"
> Administrator:  [e-mail]
> Unsubscribe:    [e-mail] "unsubscribe fractdev"
>


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: Re: Fractal Chunk fRAc for PNG files
Date: 24 Mar 2000 15:31:58 -0700


In article <105201bf95dc$da936620$[e-mail]>,
    "Paul de Leeuw" <[e-mail]>  writes:

> I like the sound of this one. If I can get compression, it would be great. I
> would insist that if it were to be saved as a PNG file that it would be
> viewable by any standard PNG viewer.

Then you have two choices -- either embed the iteration counts inside
the PNG color image as an application-specific chunk that really
contains another PNG image (watch out for chunk size overflow); or
save two files: one for the color and another for the iteration count.
PNG applications are supposed to skip chunks they don't understand, so
a custom chunk shouldn't throw off a well written viewer or utility
program.

If you save two files, it has the advantage that someone can share
their partially computed with someone else without having to send all
the iteration count data as well.  Of course the other person can't
continue the calculation where the first person left off in that case.
If that is desired, they can simply send the two files and not just
the color image.

> Would the two images (real colours and iteration count per pixel) conflict?

I'm not sure what you're asking here?

> How would I set this up (I am a bit new to PNG and have only used the
> standard PNGLIB library functions)?

Probably the easiest thing to do while you're developing is to store
two files: one for the color image and another for the iteration count
data.  When storing the iteration count data (are you using 16-bit
iteration counts or 32?), you just extract the bytes from the
iteration count and "pretend" they are color channels.

For 16-bit iteration counts you can simply create a 16-bit grayscale
image file and you don't have to worry about the byte extraction.
That's probably the easiest to start with and 64K iterations is a
lot-- but I know how you fractal guys are, you always want more... like
me :-).
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.xmission.com/~legalize/who/>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"