ftp.xmission.com/2014.06.ftp.xmission.com.tar/ftp.xmission.com/pub/lists/fractint/archive/v01.n004

Internet Message Format | 1997-08-14 | 64KB

From: [e-mail] (fractint Digest)
To: [e-mail]
Subject: fractint Digest V1 #4
Reply-To: [e-mail]
Sender: [e-mail]
Errors-To: [e-mail]
Precedence:


fractint Digest        Friday, August 15 1997        Volume 01 : Number 004



In this issue:

    Re: (fractint) Deleting and Renaming
    Re: (fractint) Re: deep zooms
    Re: (fractint) Deleting and Renaming
    (fractint) Speed testing
    Re: (fractint) Re: deep zooms
    Re: (fractint) Speed testing
    Re: (fractint) Deleting and Renaming
    Re: (fractint) Just a few to warm up with
    (fractint) Re: Making my
    (fractint) Info request: error message
    Re: (fractint) Just a few to warm up with - me again!
    (fractint) Alternative fractal software for fractal newbies :)
    (fractint) Truecolor question
    Re: (fractint) Re: deep zooms
    (fractint) flarium update
    (fractint) Re: Making myself known
    [none]
    (fractint) question for developers
    (fractint) Re: good general book on fractals
    Re: (fractint) Re: Making my
    Re: (fractint) question for developers
    Re: (fractint) question for developers
    (fractint) Re:
    Re: (fractint) Truecolor question

See the end of the digest for information on subscribing to the fractint
or fractint-digest mailing lists and on how to retrieve back issues.

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

Date: Thu, 14 Aug 1997 22:06:08 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractint) Deleting and Renaming

Janet sighed:

> Oh well <sigh> it didn't hurt to ask. :)

Yes, by all means, it always pays to ask. We developers definitely
respond to interested users :-) Just keep in mind we have so many
ideas from ourselves and others, that we have to have priorities to
stay sane ...  well, at least maintain the present level of sanity
:-)

Tim


- ------------------------------------------------------------
Thanks for using Fractint, The Fractals and Fractint Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractint"

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

Date: Thu, 14 Aug 1997 22:31:28 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractint) Re: deep zooms

Brock wrote:

> Attached to this letter is a .PAR file with a few of the par's that you kind
> people have posted... It seems that the ones with "Sylvie Gallet" in them do
> not work for me. I must be missing something-- any help would be good.

You are missing the "frm:" in front of two formulae. After fixing
that, all the images work for me. The ones to fix are Gallet-9-02 and
acc_man_mod; changes these formula names to frm:Gallet-9-02
and frm:acc_man_mod.

Incidently, I do not recommend permanently storing formulas inside
PAR files. This feature is just for convenience, to faciltate a quick
look when you download. After you've had a look, it is best to
separate the formulas and put them in their own file with the .frm
extension, and remove the "frm:" from the formula names.

Every fractint formula lover should get George Martin's orgfrm
program and collection of formulas. It's on spanky.triumf.ca
someplace, maybe someone could tell us exactly where. Fractint tries
hard to find a formula, and will search all the formula files it can
find. George's program will look through all your formulas and locate
duplicates, and organize them.

Tim



- ------------------------------------------------------------
Thanks for using Fractint, The Fractals and Fractint Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractint"

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

Date: Thu, 14 Aug 1997 23:50:07 -0400
From: Les St Clair <[e-mail]>
Subject: Re: (fractint) Deleting and Renaming

Hi Janet,

>If there's not an easier way to delete and rename files<

It's not the answer you were looking for, but here's one possible solutio=
n:

If you're using windows..
1. Get hold of Graphics Workshop for Windows (shareware, for free
evaluation)
2. Fire up the program and disable "thumbnail view"
3. Navigate to your chosen directory.
4. Now you have a screen with all of the image file names in nice columns=
,
sorted alphabetically
5. There's two handy icons on the toolbar -
5.1 Delete (icon is a paper shredder!)
5.2 Rename - just hit this button and type the new name, don't even need =
to
type the extension. Very quick.
6. Use <alt><tab> to switch between Fractint and GWS. (to avoid possibly
scrambling the image between switches, <tab> to the info screen before
switching from Fractint to GWS.)

just a thought, Les




- ------------------------------------------------------------
Thanks for using Fractint, The Fractals and Fractint Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractint"

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

Date: Thu, 14 Aug 1997 23:50:12 -0400
From: Les St Clair <[e-mail]>
Subject: (fractint) Speed testing

Charles Crocker wrote:

>>What I want to propose is a test that will tie a fractal speed rating t=
o
a
computer. I have juggled the numbers in this parameter file to run in
exactly 100 seconds on my Quantex Pentium 90.<<

>>test               { ; P90 1024X768 time  0:01:40.02

>> On an AMD DX4-120 it took 2:15.23. The Pentiums are obviously
appreciably more efficient. The question is what about the newer Pentiums=

and other variations.<<

Here's a comparison using a Dell PII-266:

test_PIIa          { ; PII-266 @ 1024x768 time =3D 0:00:48.34
                     ; Running under Windows 95
(106% faster)

test_PIIb          { ; PII-266 @ 1024x768 time =3D  0:00:47.24
                     ; Win 95/ "showdot" turned off
(112% faster, switching showdot off speeds it up!)
 =

test_PIIc          { ; PII-266 @ 1024x768 under DOS        t=3D  0:00:43.=
77
                     ; Running under DOS
(128% faster)

On other tests (under Win 95) I found the Pentium II to be approx 30%
faster than a P166.
(obviously PII technology wasn't designed with Fractint in mind<g>)

- - Les

- ------------------------------------------------------------
Thanks for using Fractint, The Fractals and Fractint Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractint"

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

Date: Thu, 14 Aug 1997 22:08:43 -0600
From: Kevin Smith <[e-mail]>
Subject: Re: (fractint) Re: deep zooms

Tim Wegner wrote:

> Every fractint formula lover should get George Martin's orgfrm
> program and collection of formulas. It's on spanky.triumf.ca
> someplace, maybe someone could tell us exactly where. Fractint tries
> hard to find a formula, and will search all the formula files it can
> find. George's program will look through all your formulas and locate
> duplicates, and organize them.

The url is: http://spanky.triumf.ca/www/fractint/fractint.html

Regards

Kevin P. Smith
[e-mail]

- ------------------------------------------------------------
Thanks for using Fractint, The Fractals and Fractint Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractint"

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

Date: Thu, 14 Aug 1997 23:15:51 -0500
From: "Paul N. Lee" <[e-mail]>
Subject: Re: (fractint) Speed testing

Les St Clair wrote:
>
> Charles Crocker wrote:
> >
> > > What I want to propose is a test that will tie a fractal speed
> > > rating to a computer.  I have juggled the numbers in this
> > > parameter file to run in exactly 100 seconds on my Quantex
> > > Pentium 90.
> > >
> > > test               { ; P90 1024X768 time  0:01:40.02
> >
> > > On an AMD DX4-120 it took 2:15.23.  The Pentiums are obviously
> > > appreciably more efficient.  The question is what about the
> > > newer Pentiums and other variations.
>
> Here's a comparison using a Dell PII-266:
>
> test_PIIa          { ; PII-266 @ 1024x768 time = 0:00:48.34
>                      ; Running under Windows 95
> (106% faster)
>
> test_PIIb          { ; PII-266 @ 1024x768 time =  0:00:47.24
>                      ; Win 95/ "showdot" turned off
> (112% faster, switching showdot off speeds it up!)
>
> test_PIIc          { ; PII-266 @ 1024x768 under DOS        t=  0:00:43.77
>                      ; Running under DOS
> (128% faster)
>
> On other tests (under Win 95) I found the Pentium II to be
> approx 30% faster than a P166.
> (obviously PII technology wasn't designed with Fractint in mind<g>)
>

I am curious as to the amount of RAM, the size of the Virtual Memory,
and the type of hard-drive (EIDE or SCSI) and the drives access times on
these machines.

I have been gathering my own stats for a few weeks now in various areas
of performance, and am always interested in the full details for my
studies.

P.N.L.

- ------------------------------------------------------------
Thanks for using Fractint, The Fractals and Fractint Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractint"

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

Date: Thu, 14 Aug 1997 23:39:46 -0700
From: [e-mail]
Subject: Re: (fractint) Deleting and Renaming

Les St Clair wrote:
>
> Hi Janet,
>
> >If there's not an easier way to delete and rename files<
>
> It's not the answer you were looking for, but here's one possible solution:
>
> If you're using windows..
> 1. Get hold of Graphics Workshop for Windows (shareware, for free
> evaluation)
> 2. Fire up the program and disable "thumbnail view"
> 3. Navigate to your chosen directory.
> 4. Now you have a screen with all of the image file names in nice columns,
> sorted alphabetically
> 5. There's two handy icons on the toolbar -
> 5.1 Delete (icon is a paper shredder!)
> 5.2 Rename - just hit this button and type the new name, don't even need to
> type the extension. Very quick.
> 6. Use <alt><tab> to switch between Fractint and GWS. (to avoid possibly
> scrambling the image between switches, <tab> to the info screen before
> switching from Fractint to GWS.)
>
> just a thought, Les

Thanks, Les, for the recommendation and handy instructions!

Janet

- ------------------------------------------------------------
Thanks for using Fractint, The Fractals and Fractint Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractint"

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

Date: Thu, 14 Aug 1997 14:05:47 -0700
From: "Jay Hill"<[e-mail]>
Subject: Re: (fractint) Just a few to warm up with

Linda,

Now 4sg0001g  was interesting, and as usual I zoomed out to look around.
Nearby I found this.  I'll put it on my web page in a day or so.
http://www.geocities.com/CapeCanaveral/Lab/3825

Jay


frm:040797-001 { ; by Linda Allison
  ; [e-mail]
z = c = pixel:
z2 = (1/z ^^ p1)
z = fn1(c * (1 - z2 ^^ z2)/(1 + z2 ^^ z2))
|z| <= p2
}

DomeCity           { ; Dome City by Jay Hill
  ; [e-mail]
  reset=1920 type=formula formulafile=allison.par
  formulaname=040797-001 function=log
  center-mag=-0.40122352673824270/-0.05838366175140746/110./1.0/159
  params=0.555/0/9/-9 float=y maxiter=500 inside=bof60 invert=-1/0/0
  decomp=256
  colors=xn_RXu<2>SZvT_wSZv<24>FKjEJiDIhCHgBGf<4>7C`6B_6AY59W<4>35N25M24K2\
  3J12H01F<8>019018017016016015014003001001<13>los<13>SNCQL9QL9QL8QK7<24>t\
  jWukXvlYxn_xn_wmZwmZ<28>RL7QK6QK7QL9<2>UQHVSKXUO<9>los<9>788<3>222000001\
  <10>21D22E22F23G23I<7>37R37S48U58W<4>7Cd8De8De<24>QWt
  }




- ------------------------------------------------------------
Thanks for using Fractint, The Fractals and Fractint Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractint"

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

Date: Fri, 15 Aug 1997 10:00:09 -0400
From: Lee Skinner <[e-mail]>
Subject: (fractint) Re: Making my

Hi Les,

>>Of course, the best thing about zooming out is finding interesting new
areas to zoom back into<g><<

Yes, indeed!!

>>am_mod11           { ; "Prairie Sunset"                     t=3D =

0:33:36.86

Absolutely stunning!  I also liked your stormclouds image.

>>...sorry it's another s-l-o-w one.

Faster computers are coming - but this will only challenge us more - ther=
e
may always be slow ones!

Lee

- ------------------------------------------------------------
Thanks for using Fractint, The Fractals and Fractint Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractint"

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

Date: Fri, 15 Aug 1997 08:14:25 -0600
From: Kevin Smith <[e-mail]>
Subject: (fractint) Info request: error message

Hi everyone

I'm attempting to save a formula file and parameter file as separate
files in my fractint directory as test01.frm and test01.par
respectively. I also edit the formula names in the files to reflect the
required files. When I attempt to generate the images, an error message
occurs that it can't find the file and it is unable to open the file in
the required directory. What am I doing wrong?


- --
Regards

Kevin P. Smith
[e-mail]

- ------------------------------------------------------------
Thanks for using Fractint, The Fractals and Fractint Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractint"

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

Date: Fri, 15 Aug 1997 07:39:47 -0700
From: "Mike or Linda Allison" <[e-mail]>
Subject: Re: (fractint) Just a few to warm up with - me again!

Great Jay!  Did you zoom back into it again?  I did!  Here's what I got
(new colormap, too).

DomeCity-zoom      { ; Zoom into Jay Hill's Domecity, which is zoom into
                     ; fractal by LAllison
                     ; changed colormap, too
                     ; Linda Allison [e-mail]
  reset=1920 type=formula formulafile=all-frms.frm
  formulaname=040797-001 function=log
  center-mag=-0.40147432236812600/-0.05044919062026389/2200/1/159
  params=0.555/0/9/-9 float=y maxiter=500 inside=bof60 invert=-1/0/0
  decomp=256
  colors=0D0<7>020000000001<14>8Ru9Ty9Sx<25>12L00J00I<16>000300600800<2>I1\
  0L10O20R30<2>Z50a60c70e80<2>lC0nD0oE0qF0<3>wM0xN0xO0yQ0<2>zV0zW0yT0<2>sJ\
  0qF0nE0mE0<6>T50Q30O30<4>C00<11>100000100200<5>B0BD0DE0G<20>k0x<8>K0N<18\
  >402000<2>010020040<26>0d00f00e0<21>0D0
  }

I'm really leaving now.  Mike is threatening to leave without me if I don't
go offline and get in the car!!

Boeff says "woof!"
Linda
http://www.geocities.com/~gumbycat
(last partial update 8/15/97)
http://www.fortunecity.com//tattooine/stephenson/5/abpf.html
(the last 16 fractals uploaded to alt.binaries.pictures.fractals,
last updated 8/13/97)


- ----------
> From: Jay Hill <[e-mail]>
> To: [e-mail]
> Subject: Re: (fractint) Just a few to warm up with
> Date: Thursday, August 14, 1997 2:05 PM
>
> Now 4sg0001g  was interesting, and as usual I zoomed out to look around.
> Nearby I found this.  I'll put it on my web page in a day or so.
> http://www.geocities.com/CapeCanaveral/Lab/3825
>


- ------------------------------------------------------------
Thanks for using Fractint, The Fractals and Fractint Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractint"

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

Date: Fri, 15 Aug 1997 11:04:05 -0600
From: [e-mail] (Horacio Luna)
Subject: (fractint) Alternative fractal software for fractal newbies :)

    Hi, I just want to recommend a program that I found when I was
fooling around, its name is Flarium, it is so easy to handle, that
people who finds fractint a little dificult to begin, would be able to
acomplish amazing things. Of course, as it is not as complex as
fractint, someone who knows what to do with fractint, will find flarium
very limited. If you are interested or just courious, give it a try, I
found it in www.download.com, just write fractals in the search text
field.

Best regards

Horacio


- ------------------------------------------------------------
Thanks for using Fractint, The Fractals and Fractint Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractint"

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

Date: Fri, 15 Aug 1997 11:17:39 -0600 (MDT)
From: Jason Hine <[e-mail]>
Subject: (fractint) Truecolor question

Howdy folks...

    I'm trying to decipher just what's going on in that little bonus program
called TRU.C which comes with Fractint.  I'm able to compile it, and run it on a
.TGA image created with the truecolor=yes command, but I'm not sure I understand
the output.  Specifically, is the iteration number for each pixel a direct
interpretation of the actual number of iterations calculated for each pixel?  If
so, then:
    a) What is the iteration number for a section of the lake?
    b) Why are values larger than my max iter setting in Basic Options
       ('x') being listed when I run TRU?

    Also, if anyone has any suggestions for info on the binary structure of
GIF files, I'd be interested in hearing from you.  Thanks for your input, and
the rest of the interesting posts!  I'm so psyched for this mailing list...

    Jason "Whee!" Hine

- ------------------------------------------------------------
Thanks for using Fractint, The Fractals and Fractint Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractint"

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

Date: Fri, 15 Aug 1997 11:38:03 -0600
From: Rich Thomson <[e-mail]>
Subject: Re: (fractint) Re: deep zooms

In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> Incidently, I do not recommend permanently storing formulas inside
> PAR files. This feature is just for convenience, to faciltate a quick
> look when you download. After you've had a look, it is best to
> separate the formulas and put them in their own file with the .frm
> extension, and remove the "frm:" from the formula names.

I'm curious why fractint doesn't just unify all the different
"parameter files" into a single file.  IFS, L-System, formula files
and PAR files could all be unified into a single text file.  Is there
a reason for the split?
- --
  ``Between stimulus and response is the will to choose.''  -- Steven Covey
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
     3D Paint: The Power to Create in 3D;        Rich Thomson
     email me for more info                [e-mail]

- ------------------------------------------------------------
Thanks for using Fractint, The Fractals and Fractint Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractint"

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

Date: Fri, 15 Aug 1997 13:09:46 -0600
From: [e-mail] (Horacio Luna)
Subject: (fractint) flarium update

    I was browsing the net looking for some amazing fractals, then I
found a very interesting place:

    http://home1.gte.net/itriazon/Sharon.htm

    It worts the time.

    By the way, in the same place I found a link for flarium's home
page, but if you want to download the program without visiting Sharons's
(what a shame), here is the address:

    http://home1.gte.net/itriazon/itriazon.htm

    Regards

    Horacio


- ------------------------------------------------------------
Thanks for using Fractint, The Fractals and Fractint Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractint"

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

Date: Fri, 15 Aug 1997 17:01:46 -0400
From: Sylvie Gallet <[e-mail]>
Subject: (fractint) Re: Making myself known

>> Of course, the best thing about zooming out is finding interesting new=

>> areas to zoom back into<g>

>> am_mod11         { ; "Prairie Sunset"                     t=3D  0:33:3=
6.86

  Great image, Les!

  Cheers,


- ------------------------------------------------------------
Thanks for using Fractint, The Fractals and Fractint Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractint"

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

Date: Fri, 15 Aug 1997 17:38:05 -0700
From: "Peter Jakubowicz" <[e-mail]>
Subject: [none]

Hi. I've been playing with Fractint for a while now, having a lot of fun
with it, but I feel as if I don't understand what I'm doing very deeply. I
know the book that originally was written to accompany the program is long
gone out of print because I've been searching for it. Is there a good
general tutorial on the program out there? And what is a good general book
on fractals, something somehere between pop science and a rigorous
mathematical treatment?


- ------------------------------------------------------------
Thanks for using Fractint, The Fractals and Fractint Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractint"

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

Date: Fri, 15 Aug 1997 15:11:41 PST
From: NOEL_GIFFIN <[e-mail]>
Subject: (fractint) question for developers

    I understand that there has been a lot of pressure on the
Fractint developers to add true-colour support, and I understand
that there is also an effort being made to make fractint a 32 bit
program, to use a flat memory model and to make the code more portable.

    I have some concern for existing features like colour cycling
and palette editing, if true-colour displays are adopted. Won't Fractint
have to switch graphics modes to utilize both truecolour and palette
editing? Isn't this rather a problem in the windows 3.1 and win95
environment. I'm not sure about win95 but I know that windows must be
restarted after switching video modes. This makes this type of dual
support next to impossible to implement in a program. What is the
current line of thinking on this? Does this mean that Fractint will
primarily remain a dos program or at least non-windows?

    Cheers,
    Noel

- ------------------------------------------------------------
Thanks for using Fractint, The Fractals and Fractint Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractint"

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

Date: Fri, 15 Aug 1997 15:42:23 -0600
From: Rich Thomson <[e-mail]>
Subject: (fractint) Re: good general book on fractals

In article <[e-mail]> ,
    "Peter Jakubowicz" <[e-mail]>  writes:
> [...] And what is a good general book
> on fractals, something somehere between pop science and a rigorous
> mathematical treatment?

I recommend Heinz-Otto Peitgen's "Chaos and Fractals".  It covers
everything: M-set, dynamical systems, bifurcation diagrams, L-systems,
etc.
- --
  ``Between stimulus and response is the will to choose.''  -- Steven Covey
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
     3D Paint: The Power to Create in 3D;        Rich Thomson
     email me for more info                [e-mail]

- ------------------------------------------------------------
Thanks for using Fractint, The Fractals and Fractint Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractint"

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

Date: Fri, 15 Aug 1997 18:44:52 -0400 (EDT)
From: [e-mail] (Michael Traynor)
Subject: Re: (fractint) Re: Making my

Lee Skinner writes:
>
>Faster computers are coming - but this will only challenge us more - there
>may always be slow ones!

May?

Computers only handle what is currently possible with the software because
we keep the requirements down to what they can handle.  With fractint's
current zoom capacity of 10^1600, it is already beyond the capacity of
computers to produce the entire standard mandelbrot image at 10^1600, in
1024x768 chunks.

Math is bigger than physics and everything that inhabits its realm.

Now, finding images worth doing, slow or fast, is another thing entirely, and
one that Lee Skinner (among many others) does much better than I.

- --
Mike Traynor

People who like this sort of thing will find this the sort of thing they like.
    Abraham Lincoln

- ------------------------------------------------------------
Thanks for using Fractint, The Fractals and Fractint Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractint"

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

Date: Fri, 15 Aug 1997 17:42:34 -0600
From: Rich Thomson <[e-mail]>
Subject: Re: (fractint) question for developers

In article <[e-mail]> ,
    NOEL_GIFFIN <[e-mail]>  writes:
>     I have some concern for existing features like colour cycling
> and palette editing, if true-colour displays are adopted. Won't Fractint
> have to switch graphics modes to utilize both truecolour and palette
> editing? Isn't this rather a problem in the windows 3.1 and win95
> environment. I'm not sure about win95 but I know that windows must be
> restarted after switching video modes. This makes this type of dual
> support next to impossible to implement in a program. What is the
> current line of thinking on this? Does this mean that Fractint will
> primarily remain a dos program or at least non-windows?

For a windows/win95 environment, there are two approaches:

1. require the user to set their video mode to what the program wants.
2. require the program to conform to the video mode the user has set.

I personally am annoyed by programs of the #1 flavor.  For fractint to
be a #2 flavor, this means that:

    a) "truecolor" renderings would have to be dithered to the current
    color palette on a screen that isn't in truecolor mode.

    b) color cycling would either be emulated or disabled when you
    aren't using a palette mapped display.

    Note that palette editing can still be done and applying a colormap
    to an image can still be done, but the operation is more complex
    than simply modifying the CLUT on the video card.

These are just the facts of life under Windows.

For DOS, its conceivable you could switch to the truecolor video mode;
but again, you wouldn't have color cycling via the hardware in 24-bit
mode.  It can be emulated, but the emulation is so slow at that point
I don't think it will make people happy.  PC busses are just too slow
for 24-bit color cycling emulation.

Think of fractint like this:


          color palette -+
                 |
                 V
    parameters -> "fractal"   -------> frame buffer ----> image
           (iteration
            count)

fractint uses the video hardware to handle the last stage of that
pipeline -- mapping iteration counts to colors.  When in 24-bit mode,
the palette editor and so on can still be used, but in that case fractint
itself must take the iteration count and pump it through the palette
table to get the 24-bit pixel that is stored in the frame buffer.

Similarly, when viewing 24-bit images under a limited color palette,
fractint could do the obvious thing of picking a video hardware
palette that selects the "best" 256 colors to represent the 24-bit
image in a dithered fashion.  Even here "palette editing" is useful,
because the palette defines the transformation of an iteration count
into a pixel.  Furthermore, this view of a palette leads to palette
depths limited only by the memory on your machine.  The fact that
palettes are 256 entries deep is an artifact of fractint's assumption
that a palette used to map iteration counts to (R,G,B) values is
identical to the palette used by the video hardware on a PC.  This is
a reasonable assumption for most programs.

Once you divorce this notion out of your code, you can have code that
uses the hardware when possible, but isn't simply SOL when the
hardware doesn't fit your model exactly.  I think the biggest thing
limiting the future of the DOS fractint is its memory consumption and
not its use of truecolor vs. 8bit.  At least that's how I understand
it from recent comments from Tim :).  I am a newbie in the fractint
developer community.
- --
  ``Between stimulus and response is the will to choose.''  -- Steven Covey
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
     3D Paint: The Power to Create in 3D;        Rich Thomson
     email me for more info                [e-mail]

- ------------------------------------------------------------
Thanks for using Fractint, The Fractals and Fractint Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractint"

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

Date: Fri, 15 Aug 1997 18:45:59 -0500
From: "Paul N. Lee" <[e-mail]>
Subject: Re: (fractint) question for developers

NOEL_GIFFIN wrote:
>
> I understand that there has been a lot of pressure on the
> Fractint developers to add true-colour support, and I understand
> that there is also an effort being made to make fractint a 32 bit
> program, to use a flat memory model and to make the code more
> portable.
>
> I have some concern for existing features like colour cycling
> and palette editing, if true-colour displays are adopted.
> Won't Fractint have to switch graphics modes to utilize both
> truecolour and palette editing?  Isn't this rather a problem
> in the windows 3.1 and win95 environment.  I'm not sure about
> win95 but I know that windows must be restarted after switching
> video modes.
>

You don't have to reboot Win-95 to change the video mode to another
resolution, there are various utilities that make this easier, like
Microsoft's QuickRes.  But why would the display mode have to change
when creating an image in either format?  You may not be able to view it
correctly if your display is under one other than what was being
generated, but it wouldn't stop the program from doing both.

>
> This makes this type of dual support next to impossible to
> implement in a program.  What is the current line
> of thinking on this?  Does this mean that Fractint will
> primarily remain a dos program or at least non-windows?
>

- ------------------------------------------------------------
Thanks for using Fractint, The Fractals and Fractint Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractint"

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

Date: Fri, 15 Aug 1997 18:35:03 -0700
From: [e-mail]
Subject: (fractint) Re:

Peter Jakubowicz wrote:
>
> Hi. I've been playing with Fractint for a while now, having a lot of fun
> with it, but I feel as if I don't understand what I'm doing very deeply.  Is there a good general tutorial on the program out there?

Try Linda Allison's site at:
http://www.geocities.com/Paris/5519/

She has written some really good tutorials on using Fractint which were
of great help to me when I first started (Well, ok, they still are!) Her
fractals are beautiful, too.

Janet

- ------------------------------------------------------------
Thanks for using Fractint, The Fractals and Fractint Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractint"

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

Date: Fri, 15 Aug 1997 18:48:19 -0500
From: "Paul N. Lee" <[e-mail]>
Subject: Re: (fractint) Truecolor question

Jason Hine wrote:
>
> Also, if anyone has any suggestions for info on the binary
> structure of GIF files, I'd be interested in hearing from you.
>


     Encyclopedia of Graphics File Formats, 2nd Edition
         written by James D. Murray and William vanRyper
         published by O'Reilly & Associates, Inc.
         http://www.ora.com/



====== GIF ======
Also Known As: Graphics Interchange Format
- --------------------------------------------------------------------
 Type                      Bitmap
 Colors                    1 to 8 bit
 Compression               LZW
 Maximum Image             Size64Kx64K pixels
 Multiple Images Per File  Yes
 Numerical Format          Little-endian
 Originator                CompuServe, Inc.
 Platform                  MS-DOS, Macintosh, UNIX, Amiga, others
 Supporting Applications   Too numerous to list
 See Also                  Chapter 9, Data Compression

Usage
Originally designed to facilitate image transfer and online storage for
use by CompuServe and its customers, GIF is primarily an exchange and
storage format, although it is based on, and is supported by, many
applications.

Comments
A well-defined, well-documented format in wide use, which is quick, easy
to read, and reasonably easy to uncompress. It lacks, however, support
for the storage of deep-pixel images.

Vendor specifications are available for this format.

Code fragments are available for this format.

Sample images are available for this format.

The following software packages can process this format:

Microsoft Windows Software:
ò       CompuPic
ò       Graphics Viewer
ò       GraphX Viewer
ò       Graphic Workshop for Windows
ò       LView Pro
ò       Paint Shop Pro
ò       PhotoLab
ò       Picture Man
ò       Ulead Viewer
ò       VuePrint
ò       WinJPEG

MS-DOS Software:
ò       Graphics Display System (GDS)
ò       gif2dxf
ò       Graphic Workshop
ò       IMDISP
ò       PICLAB
ò       QPV
ò       VPIC

OS/2 Software:
ò       GBM (Generalized Bitmap Module)
ò       PMJPEG (Presentation Manager JPEG)

UNIX Software:
ò       xli
ò       xv (X Viewer)

Source Code:
ò       FBM (Fuzzy Pixmap Manipulation)
ò       GBM (Generalized Bitmap Module)
ò       giftrans
ò       Extended Portable Bitmap Toolkit (pbmlus)
ò       Piclab Source
- --------------------------------------------------------------------

GIF (Graphics Interchange Format) is a creation of CompuServe and is
used to store multiple bitmap images in a single file for exchange
between platforms and systems. In terms of number of files in existence,
GIF is perhaps the most widely used format for storing multibit graphics
and image data. Even a quick peek into the graphics file section of most
BBSs and file archives seems to prove this true. Many of these are
high-quality images of people, landscapes, cars, astrophotographs, and
anthropometric gynoidal data (you guess what that is). Shareware
libraries and BBSs are filled with megabytes of GIF images.

The vast majority of GIF files contain 16-color or 256-color
near-photographic quality images. Gray-scale images, such as those
produced by scanners, are also commonly stored using GIF, although
monochrome graphics, such as clip art and document images, rarely are.

Although the bulk of GIF files are found in the Intel-based MS-DOS
environment, GIF is not associated with any particular software
application. GIF also was not created for any particular software
application need, although most software applications that read and
write graphical image data, such as paint programs, scanner and video
software, and most image file display and conversion programs, usually
support GIF. GIF was instead intended to allow the easy interchange and
viewing of image data stored on local or remote computer systems.

  File Organization
- ---------------------
GIF is different from many other common bitmap formats in the sense that
it is stream-based. It consists of a series of data packets, called
blocks, along with additional protocol information. Because of this
arrangement, GIF files must be read as if they are a continuous stream
of data. The various blocks and sub-blocks of data defined by GIF may be
found almost anywhere within the file. This uncertainty makes it
difficult to encapsulate every possible arrangement of GIF data in the
form of C structures.

There are a number of different data block categories, and each of the
various defined blocks falls into one of these categories. In GIF
terminology, a Graphics Control Extension block is a type of Graphics
Control block, for instance. In like manner, Plain Text Extension blocks
and the Local Image Descriptor are types of Graphic Rendering blocks.
The bitmap data is an Image Data block. Comment Extension and
Application Extension blocks are types of Special Purpose blocks.

Blocks, in addition to storing fields of information, can also contain
sub-blocks. Each data sub-block begins with a single count byte, which
can be in the range of 1 to 255 and indicates the number of data bytes
that follow the count byte. Multiple sub-blocks may occur in a
contiguous grouping (count byte, data bytes, count byte, data bytes, and
so on). A sequence of one or more data sub-blocks is terminated by a
count byte with a value of zero.

The GIF format is capable of storing bitmap data with pixel depths of 1
to 8 bits. Images are always stored using the RGB color model and
palette data. GIF is also capable of storing multiple images per file,
but this capability is rarely utilized, and the vast majority of GIF
files contain only a single image. Most GIF file viewers do not, in
fact, support the display of multiple image GIF files or may display
only the first image stored in the file. For these reasons, we recommend
not creating applications that rely on multiple images per file, even
though the specification allows this.

The image data stored in a GIF file is always LZW compressed. See
Chapter 9 for a discussion of LZW and other compression methods (and
also see the sidebar below). This algorithm reduces strings of identical
byte values into a single code word and is capable of reducing the size
of typical 8-bit pixel data by 40 percent or more. The ability to store
uncompressed data, or data encoded using a different compression
algorithm, is not supported in the current version of the GIF format.

  LZW Is Not Free
- -------------------
If you are creating or modifying software that implements the LZW
algorithm, be aware that under certain circumstances, you will need to
pay a licensing fee for the use of LZW.

Unisys Corporation owns the patent for the LZW codec (encoding/decoding
algorithm) and requires that a licensing fee be paid for each software
program that implements the LZW algorithm.

Many people have concluded that the Unisys licensing claim applies only
to LZW encoders (software that creates LZW data) and not to LZW decoders
(software that only reads LZW data). However, Unisys believes that its
patent covers the full LZW codec and requires a licensing fee even for
software that reads, but does not write, LZW data.

For more information about the entire issue of LZW licensing, refer to
the section called "LZW Legal Issues" in Chapter 9. For a popular
alternative to graphics file formats that use LZW, consider using the
Portable Network Graphics (PNG) file format.

There are two revisions of the GIF specification, both of which have
been widely distributed. The original revision was GIF87a, and many
images were created in this format. The current revision, GIF89a, adds
several capabilities, including the ability to store text and graphics
data in the same file. If you are supporting GIF, you should include
support for both the 87a and 89a revisions. It is a mistake to support
only the 89a version, because many applications continue to produce only
87a version files for backward compatibility.

  File Details
- ----------------
The "GIF87a" section here discusses features common to both versions;
the "GIF89a" section describes only the features added in GIF89a.

  GIF87a
- ----------
Version 87a is the original GIF format introduced in May 1987 and is
read by all major software applications supporting the GIF format.

Figure GIF-1 illustrates the basic layout of a GIF87a file. Each file
always begins with a Header and a Logical Screen Descriptor. A Global
Color Table may optionally appear after the Logical Screen Descriptor.
Each of these three sections is always found at the same offset from the
start of the file. Each image stored in the file contains a Local Image
Descriptor, an optional Local Color Table, and a block of image data.
The last field in every GIF file is a Terminator character, which
indicates the end of the GIF data stream.

Figure GIF-1: GIF87a file layout
 ______________________________
|          missing             |
|______________________________|

  Header
- ----------
The Header is six bytes in size and is used only to identify the file as
type GIF. The Logical Screen Descriptor, which may be separate from the
actual file header, may be thought of as a second header. We may
therefore store the Logical Screen Descriptor information in the same
structure as the Header:

typedef struct _GifHeader
{
  // Header
  BYTE Signature[3];     /* Header Signature (always "GIF") */
  BYTE Version[3];       /* GIF format version("87a" or "89a") */
  // Logical Screen Descriptor
  WORD ScreenWidth;      /* Width of Display Screen in Pixels */
  WORD ScreenHeight;     /* Height of Display Screen in Pixels */
  BYTE Packed;           /* Screen and Color Map Information */
  BYTE BackgroundColor;  /* Background Color Index */
  BYTE AspectRatio;      /* Pixel Aspect Ratio */
} GIFHEAD;


Signature is three bytes in length and contains the characters GIF as an
identifier. All GIF files start with these three bytes, and any file
that does not should not be read by an application as a GIF image file.

Version is also three bytes in length and contains the version of the
GIF file. There are currently only two versions of GIF: 87a (the
original GIF format) and 89a (the new GIF format). Some GIF87a file
viewers may be able to read GIF89a files, although the stored image data
may not display correctly.

  Logical Screen Descriptor
- -----------------------------
The Logical Screen Descriptor contains information describing the screen
and color information used to create and display the GIF file image.

The ScreenHeight and ScreenWidth fields contain the minimum screen
resolution required to display the image data. If the display device is
not capable of supporting the specified resolution, some sort of scaling
will be necessary to properly display the image.

Packed contains the following four subfields of data (bit 0 is the least
significant bit, or LSB):

 Bits 0-2 Size of the Global Color Table
  Bit 3   Color Table Sort Flag
 Bits 4-6 Color Resolution
  Bit 7   Global Color Table Flag

The Size of the Global Color Table subfield contains the number of bits
in each Global Color Table entry minus one. For example, if an image
contains 8 bits per pixel, the value of this field is 7. The total
number of elements in the Global Color Table is calculated by shifting
the value one to the left by the value in this field:

NumberOfGlobalColorTableEntries =
     (1L << (SizeOfTheGlobalColorTable + 1));

The Size of the Global Color Table subfield is always set to the proper
size even if there is no Global Color Table (i.e., the Global Color
Table Flag subfield is set to 0). If the Color Table Sort Flag subfield
is 1, then the Global Color Table entries are sorted from the most
important (most frequently occurring color in the image) to the least
important. Sorting the colors in the color table aids an application in
choosing the colors to use with display hardware that has fewer
available colors than the image data. The Sort flag is only valid under
version 89a of GIF. Under version 87a, this field is reserved and is
always set to 0.

The Color Resolution subfield is set to the number of bits in an entry
of the original color palette minus one. This value equates to the
maximum size of the original color palette. For example, if an image
originally contained eight bits per primary color, the value of this
field would be 7. The Global Color Table Flag subfield is set to 1 if a
Global Color Table is present in the GIF file, and 0 if one is not.
Global Color Table data, if present, always follows the Logical Screen
Descriptor header in the GIF file.

BackgroundColor in the Logical Screen Descriptor contains an index value
into the Global Color Table of the color to use for the border and
background of the image. The background is considered to be the area of
the screen not covered by the GIF image. If there is no Global Color
Table (i.e., the Global Color Table Flag subfield is set to 0), this
field is unused and should be ignored.

AspectRatio contains the aspect ratio value of the pixels in the image.
The aspect ratio is the width of the pixel divided by the height of the
pixel. This value is in the range of 1 to 255 and is used in the
following calculation:

        PixelAspectRatio = (AspectRatio + 15) / 64;

If this field is 0, then no aspect ratio is specified.

  Global Color Table
- ----------------------
The Logical Screen Descriptor may be followed by an optional Global
Color Table. This color table, if present, is the color map used to
index the pixel color data contained within the image data. If a Global
Color Table is not present, each image stored in the GIF file contains a
Local Color Table that it uses in place of a Global Color Table. If
every image in the GIF file uses its own Local Color Table, then a
Global Color Table may not be present in the GIF file. If neither a
Global nor a Local Color Table is present, make sure your application
supplies a default color table to use. It is suggested that the first
entry of a default color table be the color black and the second entry
be the color white.

Global Color Table data always follows the Logical Screen Descriptor
information and varies in size depending upon the number of entries in
the table. The Global Color Table is a series of three-byte triples
making up the elements of the color table. Each triple contains the red,
green, and blue primary color values of each color table element:

typedef struct _GifColorTable
{
  BYTE Red;          /* Red Color Element       */
  BYTE Green;        /* Green Color Element     */
  BYTE Blue;         /* Blue Color Element      */
} GIFCOLORTABLE;

The number of entries in the Global Color Table is always a power of two
(2, 4, 8, 16, and so on), up to a maximum of 256 entries. The size of
the Global Color Table in bytes is calculated by using bits 0, 1, and 2
in the Packed field of the Logical Image Descriptor in the following
way:

ColorTableSize = 3L * (1L << (SizeOfGlobalColorTable + 1));

The Header, Logical Screen Descriptor, and Global Color Map data are
followed by one or more sections of image data. Each image in a GIF file
is stored separately, with an Image Descriptor and possibly a Local
Color Table. The Image Descriptor is similar to a header and contains
information only about the image data that immediately follows it. The
Local Color Table contains color information specific only to that image
data and may or may not be present.

  Local Image Descriptor
- --------------------------
The Local Image Descriptor appears before each section of image data and
has the following structure:

typedef struct _GifImageDescriptor
{
  BYTE Separator;    /* Image Descriptor identifier */
  WORD Left;         /* X position of image on the display */
  WORD Top;          /* Y position of image on the display */
  WORD Width;        /* Width of the image in pixels */
  WORD Height;       /* Height of the image in pixels */
  BYTE Packed;       /* Image and Color Table Data Information */
} GIFIMGDESC;

Separator contains the value 2Ch and denotes the beginning of the Image
Descriptor data block.

Left and Top are the coordinates in pixels of the upper-left corner of
the image on the logical screen. The upper-left corner of the screen is
considered to be coordinates 0,0.

Width and Height are the size of the image in pixels.

Packed contains the following five subfields of data (bit 0 is the LSB):
  Bit 0 Local Color Table Flag
  Bit 1 Interlace Flag
  Bit 2 Sort Flag
 Bits 3-4 Reserved
 Bits 5-7 Size of Local Color Table Entry

The Local Color Table Flag subfield is 1 if a Local Color Table is
associated with this image. If the value of this subfield is 0, then
there is no Local Color Table present, and the Global Color Table data
should be used instead.

The Interlace Flag subfield is 1 if the image is interlaced and 0 if it
is non-interlaced. (See the description of Image Data for an explanation
of interlaced image data.)

The Sort Flag subfield indicates whether the entries in the color table
have been sorted by their order of importance. Importance is usually
decided by the frequency of occurrence of the color in the image data. A
value of 1 indicates a sorted color table, while a value of 0 indicates
a table with unsorted color values. The Sort Flag subfield value is
valid only under version 89a of GIF. Under version 87a, this field is
reserved and is always set to 0.

The Size of Local Color Table Entry subfield is the number of bits per
entry in the Local Color Table. If the Local Color Table Flag subfield
is set to 0, then this subfield is also set to 0.

  Local Color Table
- ---------------------
If a Local Color Table is present, it immediately follows the Local
Image Descriptor and precedes the image data with which it is
associated. The format of all Local Color Tables is identical to that of
the Global Color Table. Each element is a series of 3-byte triples
containing the red, green, and blue primary color values of each element
in the Local Color Table:

typedef struct _GifColorTable
{
  BYTE Red;            /* Red Color Element */
  BYTE Green;          /* Green Color Element */
  BYTE Blue;           /* Blue Color Element */
} GIFCOLORTABLE;

The number of entries and the size in bytes of the Local Color Table is
calculated in the same way as the Global Color Table:

ColorTableSize = 3L * (1L << (SizeOfLocalColorTable + 1));
ColorTableNumberOfEntries = 1L << (SizeOfLocalColorTable
     + 1);

A Local Color Table only affects the image it is associated with and, if
it is present, its data supersedes that of the Global Color Table. Each
image may have no more than one Local Color Table.

  Image data
- --------------
GIF files do not compress well when stored using file archivers such as
pkzip and zoo. This is because the image data found in every GIF file is
always compressed using the LZW (Lempel-Ziv-Welch) encoding scheme, the
same compression algorithm used by most file archivers. (See the sidebar
about LZW at the beginning of this article.) Compressing a GIF file is
therefore a redundant operation, which rarely results in smaller files
and is usually not worth the time and effort involved in the attempt.

Normally when LZW-encoded image data is stored in a graphics file
format, it is arranged as a continuous stream of data that is read from
beginning to end. The GIF format, however, stores encoded image data as
a series of data sub-blocks.

Each data sub-block begins with a count byte. The value of the count
byte may range from 1 to 255 and indicates the number of data bytes in
the sub-block. The data blocks immediately follow the count byte. A
contiguous group of data blocks is terminated by a byte with a zero
value. This may be viewed as either a terminator value or as a sub-block
with a count byte value of zero; in either case, it indicates that no
data bytes follow.

Because GIF files do not contain a contiguous stream of LZW-encoded
data, each sub-block must be read and the data sent to an LZW decoder.
Most sub-blocks storing image data will be 255 bytes in length, so this
is an excellent maximum size to use for the buffer that will hold the
encoded image data. Also, the LZW encoding process does not keep track
of where each scan line begins and ends. It is therefore likely that one
scan line will end and another begin in the middle of a sub-block of
image data.

The format of the decoded GIF image data is fairly straightforward. Each
pixel in a decoded scan line is always one byte in size and contains an
index value into either a Global or Local Color Table. Although the
structure of the GIF format is quite capable of storing color
information directly in the image data (thus bypassing the need for a
color table), the GIF specification does not specify this as a possible
option. Therefore, even 1-bit image data must use 8-bit index values and
a 2-entry color table.

GIF image data is always stored by scan line and by pixel. GIF does not
have the capability to store image data as planes, so when GIF files are
displayed using plane-oriented display adapters, quite a bit of
buffering, shifting, and masking of image data must first occur before
the GIF image can be displayed.

The scan lines making up the GIF bitmap image data are normally stored
in consecutive order, starting with the first row and ending with the
last. The GIF format also supports an alternate way to store rows of
bitmap data in an interlaced order. Interlaced images are stored as
alternating rows of bitmap data. If you have ever viewed a GIF file that
appeared on the screen as a series of four "wipes" that jumped across
the screen as the image was displayed, you were viewing an interlaced
GIF file.

Figure GIF-2 compares the order of rows stored in an interlaced and
non-interlaced format. In the non-interlaced format, the rows of bitmap
data are stored starting with the first row and continuing sequentially
to the last row. This is the typical storage format for most bitmap file
formats. The interlaced format, however, stores the rows out of the
normal sequence. All the even rows are stored first and all the odd rows
are stored last. We can also see that each successive pass usually
encodes more rows than the previous pass.

GIF uses a four-pass interlacing scheme. The first pass starts on row 0
and reads every eighth row of bitmap data. The second pass starts on the
fourth row and reads every eighth row of data. The third pass starts on
the second row and reads every fourth row. The final pass begins on the
first row and reads every second row. Using this scheme, all of the rows
of bitmap data are read and stored.

Figure GIF-2: Arrangement of interlaced and non-interlaced scan lines
 _________________________
|       missing           |
|_________________________|

Why interlace a GIF image? Interlacing might seem to make the reading,
writing, and displaying of the image data more difficult, and of course
it does. Does this arrangement somehow make the image easier to display
on interlaced monitors? The answer lies in one of the original purposes
of GIF.

GIF was designed as an image communications protocol used for the
interactive viewing of online images. A user connected to an information
service via a modem could not only download a GIF image, but could also
see it appear on his or her display screen as it was being downloaded.
If a GIF image were stored in a non-interlaced format, the GIF image
would display in a progressive fashion starting at the top of the screen
and ending at the bottom. After 50 percent of the download was
completed, only the top half of the GIF image would be visible. An
interlaced image, however, would display starting with every eighth row,
then every fourth row, then every second row, and so on. When the
download of an interlaced GIF image was only 50 percent complete, the
entire contents of the image could be discerned even though only half
the image had been displayed. The viewer's eye and brain would simply
fill in the missing half.

Interlacing presents a problem when converting a GIF image from one
format to another. A scan-line table must be created to write out the
scan lines in their proper, non-interlaced order. The following sample
code is used to produce a scan-line table of an interlaced image:

WORD i, j;
WORD RowTable1[16];
WORD RowTable2[16];
WORD ImageHeight = 16;            /* 16 lines in the GIF image */
for (i = 0; i < ImageHeight; i++)    /* Initialize source array*/
     RowTable1[i] = i;
j = 0;
for (i = 0; i < ImageHeight; i += 8, j++)  /* Interlace Pass 1 */
     RowTable2[i] = RowTable1[j];
for (i = 4; i < ImageHeight; i += 8, j++)  /* Interlace Pass 2 */
     RowTable2[i] = RowTable1[j];
for (i = 2; i < ImageHeight; i += 4, j++)  /* Interlace Pass 3 */
     RowTable2[i] = RowTable1[j];
for (i = 1; i < ImageHeight; i += 2, j++)  /* Interlace Pass 4 */
     RowTable2[i] = RowTable1[j];

The array RowTable1[] contains the mapping of the scan lines in a
non-interlaced image, which in this example are the values 0 to 15 in
consecutive order. The array RowTable2[] is then initialized by the
interlacing code to contain the mapping of the scan lines of the
interlaced image:

RowTable1[]  RowTable2[]
0            0
1            8
2            4
3            9
4            2
5            10
6            5
7            11
8            1
9            12
10           6
11           13
12           3
13           14
14           7
15           15

We can restore the non-interlaced image by stepping through the values
stored in RowTable2[]. The 0th row of the non-interlaced image is the
0th row of the interlaced image. The first row of the non-interlaced
image is the eighth row of the interlaced image. The second row of the
non-interlaced image is the fourth row of the interlaced image, and so
on.

  Trailer
- -----------
The Trailer is a single byte of data that occurs as the last character
in the file. This byte value is always 3Bh and indicates the end of the
GIF data stream. A trailer must appear in every GIF file.

  GIF89a
- ----------
Version 89a is the most recent revision of the GIF image file format and
was introduced in July of 1989. Although the GIF89a format is very
similar to GIF 87a, it contains several additional blocks of information
not defined in the 87a specification. For this reason GIF89a image files
may not be read and displayed properly by applications that read only
GIF87a image files. Many of these programs do not not attempt to display
an 89a image file, because the version number "89a" will not be
recognized. Although changing the version number from "89a" to "87a"
will solve this problem, the GIF image data may still not display
properly, for reasons we shall soon see.

Figure GIF-3 illustrates the basic layout of a GIF89a image file. Just
as with version 87a, the 89a version also begins with a Header, a
Logical Screen Descriptor, and an optional Global Color Table. Each
image also contains a Local Image Descriptor, an optional Local Color
Table, and a block of image data. The trailer in every GIF89a file
contains the same values found in 87a files.

Version 89a added a new feature to the GIF format called Control
Extensions. These extensions to the GIF87a format are specialized blocks
of information used to control the rendering of the graphical data
stored within a GIF image file. The design of GIF87a only allowed the
display of images one at a time in a "slide show" fashion. Through the
interpretation and use of Control Extension data, GIF89a allows both
textual and bitmap-based graphical data to be displayed, overlaid, and
deleted as in an animated multimedia presentation.

The four Control Extensions introduced by GIF89a are the Graphics
Control Extension, the Plain Text Extension, the Comment Extension, and
the Application Extension, summarized here and described in greater
detail in the sections below.

Graphics Control Extension blocks control how the bitmap or plain-text
data found in a Graphics Rendering block is displayed. Such control
information includes whether the graphic is to be overlaid in a
transparent or opaque fashion over another graphic, whether the graphic
is to be restored or deleted, and whether user input is expected before
continuing with the display of the GIF file data.

Plain Text Extension blocks allow the mixing of plain-text ASCII
graphics with bitmapped image data. Many GIF images contain
human-readable text that is actually part of the bitmap data itself.
Using the Plain Text Extension, captions that are not actually part of
the bitmapped image may be overlaid onto the image. This can be
invaluable when it is necessary to display textual data over an image,
but it is inconvenient to alter the bitmap to include this information.
It is even possible to construct an 89a file that contains only
plain-text data and no bitmap image data at all.

         (lot's more available)

- ------------------------------------------------------------
Thanks for using Fractint, The Fractals and Fractint Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractint"

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

End of fractint Digest V1 #4
****************************

To subscribe to fractint Digest, send the command:

    subscribe fractint-digest

in the body of a message to "[e-mail]".  If you want to
subscribe something other than the account the mail is coming from, such
as a local redistribution list, then append that address to the
"subscribe" command; for example, to subscribe "local-fractint":

    subscribe fractint-digest [e-mail]

A non-digest (direct mail) version of this list is also available; to
subscribe to that instead, replace all instances of "fractint-digest"
in the commands above with "fractint".

Back issues are available for anonymous FTP from ftp.xmission.com, in
pub/lists/fractint/archive.  These are organized by date.