ftp.xmission.com/2014.06.ftp.xmission.com.tar/ftp.xmission.com/pub/lists/fractdev/archive/v01.n002

Internet Message Format | 1998-01-12 | 42KB

From: [e-mail] (fractdev-digest)
To: [e-mail]
Subject: fractdev-digest V1 #2
Reply-To: fractdev-digest
Sender: [e-mail]
Errors-To: [e-mail]
Precedence: bulk


fractdev-digest        Monday, January 12 1998        Volume 01 : Number 002




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

Date: Fri, 07 Nov 1997 17:11:35 -0600
From: "Damien M. Jones" <[e-mail]>
Subject: (fractdev) Fast FP Mandelbrot

Tim,

I downloaded the source, and of course it won't compile with the old BC5
makefiles I have.  So I extracted the calmanfp routine and inserted it into
the old source, changing a couple of labels so I could compile and test the
new FP code.

This code is considerably faster than previous versions on my four test
points (on my P-166):

      19.6   dev version
      ------------------
 1:    56.46     30.10
 2:    46.57     24.88
 3:    31.86     16.86
 4:     9.72      4.89
 T:   144.61     72.73

Just about twice as fast, very nice.

I'll tinker this weekend and see what I can come up with.

    Damien M. Jones  /  temporary sanity designs  /  http://www.icd.com/tsd/
 [e-mail]  /  my gallery of fractal art: http://www.fractalus.com/


- -
- ------------------------------------------------------------
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"

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

Date: Sun, 9 Nov 1997 16:42:15 -0600
From: "Tim Wegner" <[e-mail]>
Subject: (fractdev) broken?

fractdev seems to be broken also.

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"

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

Date: Sun, 9 Nov 1997 16:51:51 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) broken?

I have now successfully posted messages to both fractint and
fractdev. Normally I don't like test messages on lists, but I'd
appreciate a few on both fractint and fractdev to make sure things
are OK. If possible add some fractal content <g!>

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"

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

Date: Tue, 11 Nov 1997 13:08:54 +0100 (MET)
From: "Michael R. Ganss" <[e-mail]>
Subject: Re: (fractdev) Fast FP Mandelbrot

Damien,

> seconds--about 6% faster than Terje Mathisen's code.  I think the state of
> the art just changed. :)

Great. Excellent work. Be sure to let Terje and Paul Hsie know about
your findings (consider cross-posting to comp.lang.asm.x86). Also, I'd
love to see those benchmarks and the code put on the web.

> I have not applied these changes to my eight-iteration unrolled loop yet,
> but I'm happy because I got to make my routine faster.  Very cool.

I can imagine it will be very difficult to apply these changes to
the unrolled loop, since, as you have pointed out, one change affects
everything else and there may be different instruction orders that are
slower in a non-unrolled loop but faster in an unrolled one. One point
that might be of interest in this context is (as Nick Haines has also
noted and which is why he unrolled, since with the SPARC a mul seems
to be more of a problem than a cmp) that you can save one fp
multiplication by observing the following equivalency (rounding errors
aside):

re=(re*re-im*im)+cr <=> re=(re+im)*(re-im)+cr

Terje said this is no gain for the Pentium, since fadd and fmul take
the same number of cycles (although there is one slight difference in
the number of instructions they can overlap with). I'd be interested
what you think about this issue. On other processors (notably Pentium
Pro and II, see section 25 of Agner Fog's manual) this should very
well make a difference.

- --
Michael R. Ganss        Cooper:  Look!  Ducks!  On a lake!  Ahhh.
[e-mail]        http://www.cs.tu-berlin.de/~rms/AlmondBread/

- -
- ------------------------------------------------------------
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"

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

Date: Tue, 11 Nov 1997 10:01:52 -0600
From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) Fast FP Mandelbrot

Michael,

 - Great. Excellent work. Be sure to let Terje and Paul Hsie know about
 - your findings (consider cross-posting to comp.lang.asm.x86). Also, I'd
 - love to see those benchmarks and the code put on the web.

The original intent was to post all this on the web when it was "finished".
 I think, at this point, I may as well call it finished.  When I get the
web page done, I'll post the code to comp.lang.asm.x86 as well.

 - > I have not applied these changes to my eight-iteration unrolled loop yet,
 - > but I'm happy because I got to make my routine faster.  Very cool.
 -
 - I can imagine it will be very difficult to apply these changes to
 - the unrolled loop, since, as you have pointed out, one change affects
 - everything else and there may be different instruction orders that are
 - slower in a non-unrolled loop but faster in an unrolled one.

This is true--as it is, my unrolled loop is a bit convoluted, and arranges
the pipeline so that the end of one calculation isn't actually ready when
the next begins.  However, I was able to incorporate some of the changes
and tweak a bit more code, and now the unrolled version is also about 5%
faster.

 - One point that might be of interest in this context is (as Nick Haines
 - has also noted and which is why he unrolled, since with the SPARC a mul
 - seems to be more of a problem than a cmp) that you can save one fp
 - multiplication by observing the following equivalency (rounding errors
 - aside):

I looked at this, and it didn't seem to help any.  Part of the reason is
that in order to make (r+i)(r-i) work, you need an extra copy of a number.
To compute (ri) and (rr)+(ii) you need to only make one duplicate; your
other multiplications can be done in-place.  To do both (ri) and (r+i)(r-i)
you need to make *two* copies, and such a copy amounts to an extra
operation (same amount of time as an arithmetic op on the Pentium).

 - Terje said this is no gain for the Pentium, since fadd and fmul take
 - the same number of cycles (although there is one slight difference in
 - the number of instructions they can overlap with). I'd be interested
 - what you think about this issue. On other processors (notably Pentium
 - Pro and II, see section 25 of Agner Fog's manual) this should very
 - well make a difference.

The PPro/PII have longer latency on the FPU multiply (by two cycles) than
the add; it may be slightly faster to go with the add approach.  I don't
have a PPro here to test with any more.  One reason I held off writing
optimized Mandelbrot code until just recently was until now I didn't have
an Intel processor (I had a Cyrix).

    Damien M. Jones  /  temporary sanity designs  /  http://www.icd.com/tsd/
 [e-mail]  /  my gallery of fractal art: http://www.fractalus.com/


- -
- ------------------------------------------------------------
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"

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

Date: Thu, 11 Dec 1997 15:55:44 EST
From: RBarn0001 <[e-mail]>
Subject: (fractdev) New True Color Algorithm

For all of you interested in true color fractals without the banding you get
from Fractint, and for those of you who want to use formulas other than
polynomials which are needed for the Vepstas method, I HAVE GOOD NEWS!.

I have discovered a new, VERY SIMPLE, algorithm, which I call EXPONENTIAL
SMOOTHING. At each iteration of the function, the negative exponential of the
modulus is summed. On escape, the sum is used in place of the iteration count!
The exponential sum is usually 2 to 10 times smaller than the iteration count,
so a scaling factor, which would be a user defined parameter,  is needed to
spread out the color map. For regular escape fractals, use the formula:

                          sum = sum + exp(-modulus)

for finite difference (convergent) fractals such as Newton use the formula

                         sum = sum + exp(-1/(|OldZ - Z|))

It works with every case I have tried and every weird function I tested. Some
images and a new Windows 3.1 version of Truemand is out on my web site which
uses the new method. Try it, I think you will like it.

Ron Barnett
http:\\members.aol.com\RBarn0001


- -
- ------------------------------------------------------------
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"

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

Date: Sun, 9 Nov 1997 18:13:03 -0500
From: Sylvie Gallet <[e-mail]>
Subject: Re: (fractdev) broken?

Tim,

>> I have now successfully posted messages to both fractint and =

>> fractdev. Normally I don't like test messages on lists, but I'd =

>> appreciate a few on both fractint and fractdev to make sure things =

>> are OK. If possible add some fractal content <g!>

  OK.  Here is my fractal test:

6cntst12           { ; .                                    t=3D  0:32:28=
=2E58
                     ; Copyright Sylvie Gallet, Nov 09, 1997
                     ; <sylvie [e-mail]>
                     ; t=3Dcalc time using a Pentium 166 at 1600 x 1200
  reset=3D1960 type=3Dformula formulafile=3Dcontest.frm formulaname=3Dcon=
test4
  passes=3D1
  center-mag=3D+0.58489317833557530/+0.47265450618693770/154561.9
  params=3D0/1.4 float=3Dy maxiter=3D1023 inside=3Depsiloncross periodici=
ty=3D0
  colors=3DQJDMGAIC7<10>hgdkjgnmkqonsrq<2>zzz<9>opsmorlnrknr<12>YagW`fV_e=
TZe\
  SYd<6>LRZJQYJPX<7>DHM<16>zzz<29>mjSliQkhQ<14>PND<16>zxy<39>PMLOLKNKK<4>=
I\
  FF<16>zzz<2>ywvxvuwutvtrvsq<7>pkfojdojd<13>dWMcUKbUK<9>RKE
  cyclerange=3D0/255
  }

6cntst14           { ; .                                    t=3D  0:05:58=
=2E28
                     ; Copyright Sylvie Gallet, Nov 09, 1997
                     ; <sylvie [e-mail]>
                     ; t=3Dcalc time using a Pentium 166 at 1600 x 1200
  reset=3D1960 type=3Dformula formulafile=3Dcontest.frm formulaname=3Dcon=
test4
  passes=3D1
  center-mag=3D-0.22422483381026530/+0.78771486765280820/1116.796/1/-119.=
999
  params=3D0.4/-0.5 float=3Dy maxiter=3D1023 inside=3Depsiloncross
  periodicity=3D0
  colors=3D8B79B7ogP9C89D8AD8P00AE9<7>DICDICDICDICDJC<27>JVIKWJKWJLXKMXK<=
42>\
  nrgoshptiqtjqtj<6>uwnvxovxowxowxo<2>zzrzzp<5>yymyxlyxlxwkxwk<40>mgPlfOl=
f\
  OkeNkeN<34>UMCTMCTLBTLB<27>652542432321321<16>8A6 cyclerange=3D0/255
  }

6cntst15           { ; .                                    t=3D  0:05:11=
=2E70
                     ; Copyright Sylvie Gallet, Nov 09, 1997
                     ; <sylvie [e-mail]>
                     ; t=3Dcalc time using a Pentium 166 at 1600 x 1200
  reset=3D1960 type=3Dformula formulafile=3Dcontest.frm formulaname=3Dcon=
test4
  passes=3D1
  center-mag=3D+0.55224105523550580/+0.56134568957565560/1883.603/1/-57.5=

  params=3D0.4/-0.5 float=3Dy maxiter=3D1023 inside=3Depsiloncross
  periodicity=3D0 colors=3D58D<117>wwzwwzvvy<123>F00038<9>57C
  cyclerange=3D0/255
  }

        - Sylvie

- -
- ------------------------------------------------------------
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"

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

Date: Tue, 16 Dec 1997 11:53:51 -0700
From: Rich Thomson <[e-mail]>
Subject: (fractdev) switching algorithms?

How does fractint know when to switch from integer to floating-point,
from floating-point to long double, and from long double to arbitrary
precision arithmetic?  Are the switch points hard coded in the zoom
factor? (i.e. switch to floating point after you zoom in by factor X)
- --
  ``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 Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

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

Date: Tue, 16 Dec 1997 17:48:16 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) switching algorithms?

Here's the answer I posted to the fractint list:

Rich asked:

> How does fractint know when to switch from integer to
> floating-point, from floating-point to long double, and from long
> double to arbitrary precision arithmetic?  Are the switch points
> hard coded in the zoom factor? (i.e. switch to floating point after
> you zoom in by factor X)

First a correction - Fractint doesn't really use long double for
fractal calculations. Some values are temporarily held in long
doubles. I did make a long double version of Fractint in a marathon
weekend hack a few years ago, and had about 90% of things working, but
this never saw the light of day except for a few artists who bribed me
for a copy on the promise that they would never report a bug to me
<g!> Long double gives three orders of magnitude deeper zooming. My
current developer version of Fractint has a long double Synchronous
orbits mandelbrot algorithm, but I'm not leaving it in as it is.

There are several methods used, depending on which point in the
code and which direction you are zooming. The original one is to
calculate the pixel grids by repeatedly adding the delta values, and
see if the value across the screen is what it should be. This
algorithm is therefore not hard coded. Pieter Branderhorst wrote this
originally, and most of Pieter's code is very hard to understand, but
his code is (fortunately) also the most robust in Fractint. I have
messed with the precision code from time to time as issues have come
up.

The arbitrary precision limit uses a magnification cutoff and is hard
coded but user settable. There is also a user settable tolerance for
some of the other transitions.

One of the tough problems is having precision detection that works for
all skewed/rotated zoom boxes.

The mishmash of methods is in need of an overhaul. There are known
bugs where it doesn't work right, although it has worked well overall.
But it's not easy, and I've been procrastinating looking at it. It
would do no good to clean up the code if the result worked worse <g!>

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"

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

Date: Mon, 29 Dec 1997 18:36:56 +0000
From: robin bussell <[e-mail]>
Subject: (fractdev) wishlist '97 retrospective

May I firstly extend my warmest holiday greetings and the hope of a
marvellous
new year to fellow Fractdev members, Hi!

The Fractint wishlist has been up for some four months now and has been
quite a success with over 1100 hits and loads of suggestions (ok so I
gave up counting them :-) around 200 anyway!) I present here a
condensation
of some of them as a holiday present and insight into the minds of the
fractint using public....

Oh yeah, for those who wish to know the full list is to be found at:

http://web.ukonline.co.uk/members/robin.b2/olig/fracwish.htm

Firstly some fullsome praise to warm the cockles of your hearts:

  "You have created a great program, and your names are engraved
  in the software history " [e-mail]

  "I love Fractint, its an awsome program. " [e-mail]

  "I would also like to thank you guyz at the Stone Soup Group for
proving
  wrong the saying, "You get what you pay for" " [e-mail]

  "THE ONLY reason I have a computer is FRACTINT.(believe it)"
  [e-mail]

  "P.S. I love you guys" [e-mail]

  "Go on with it, thanks for the pleasure you give me, Cornelius"
   [e-mail]

  "Thanks to all fractint programmers for this fantastic program!"
   [e-mail]

  "Thanks for the best fractal generator ever!"
   Rafael

  "By the way, you guys (and gals) that make and add to the program are
   truly an awesome bunch of folks. You have my admiration. (NOTE: see
the
   contribution policy in the Fractint Help section.) Fract On!"
   [e-mail]

  "Best wishes from Fractal Fanatic Female in Sweden, Liselotte Frejdig.
  Keep up the good work!!!"
  [e-mail]

  "Fractint is THE ONLY WORTHWHILE PROGRAM IN THE UNIVERSE! Thank you
much!"
  [e-mail]

Whew! praise indeed! gosh we're just this bunch of guys you know :-)
Nice
to be appreciated.

Then again sometimes wishes get a little blunt.. especially from the Mac
using contingent ... I thought those guys were supposed to be the
creative
ones! <GDAR>

  "Two words... Power Mac."  [e-mail]

  "Bob in here at 1:16:0 Monday October 27 97
   Make one for MAC"

Then again it looks like there are some pretty desperate fractal starved
mac
users around as these pleas and bribes show:

  "Please, please make it downloadable for the Mac. Is that impossible?"
  [e-mail]

  "on bended knees, deep sigh: Fractint for Mac Os8???? Is that
possible?
   please say "yes!" " [e-mail]

  "PLEASE ! help me i NEED a copy of Fractint for my Power Macintosh"
  [e-mail]

  "I would kiss the gnarled toes of anyone who would do a port
  of Fractint over to the Macintosh platform."
  [e-mail]

  "we users will do all we can to make you presidents of the Earth or
   whatever you prefer..."
   [e-mail]

hmmm... tempting! it would definately be a Good Thing to make fractint
platform independant but I'm certainly not the guy for it... though
according to some it's just a magic wand wave away :-)


  "For all we know, it is written in C, and it shouldn't be such an
  impossible mission." [e-mail]

hmmm!

  "C'mon! MAC is easier to code for, PowerPC chips have a lower error
rate
   with floating point and arbitrary precision math, and it's the
   premiere graphics platform. Make the leap! Think different!"
   [e-mail]

what's that about a lower error rate for arbitrary precision math..??!!

But enough Mac bashing methinks (there's no sport in it :^) ) windows
users
have the same needs it seems:

  "A very little request -- why not make it a true windows 95/NT
program,
  menue based and all... Win 95"
  [e-mail]

  "A version for Windows95, with true-colour (24 bit) support. Please!"
  [e-mail]

  "A 32-bit Win95/Win98 and/or WinNT version with MMX support. (I still
  prefer good old DOS, but it seems that Bill Gates has had his way!)"
  [e-mail]

And so on for many a request... looks like the world is going gooey! As
an
aside it was interesting to see a few requests for MMX support
revealing the extent of the penetration of the intel "MMX is good"
marketing
campaign.. has *anyone* actually seen an application that is noticeably
accellerated by MMX? I've seen a few that just plain won't work without
it
(probably just due to a detection routine and not any real need for the
somewhat limited extra instructions my cynical side suspects :-) )
but no honest to goodness "works with it or without it and does better
with
it" applications... perhaps we can tout the next version of fractint as
having
"MMX support" .... well it'll use the extra L1 cache won't it :)
anyway I'll put my soapbox away now ;-)

So to sum it up, we've had responses from all over the world from
Australia
to Croatia, from Philadelphia to Oxford, even from someone claiming to
be "ontop a missle over the Atlantic" (Dr StrangeFractal? ) many
suggestions
some interesting, some slightly silly, some academically concise, but
all
friendly and I didn't have to expurgate any obscenities either!.... not
a bad
record I think you'll agree.

For the new year I've been thinking of adding in some commenting ability
whereby the fractint developement team can add their own replies to
points
as they're brought up. It'll probably take the form of a scrollable
frame on
the page which is an extending list like the wishlist itself but with an
entry form on a secret page that only we'll know about. Sort of a "work
in
progress" report, combined with a "why we can't do this so please stop
asking"
option :-)

I'll post here when I've got a prototype going then we can go live if it
looks good.

Meanwhile it'd be appreciated by everyone if you could all look in on
the
wishlist regularly and maybe email some answers to people with problems
from
time to time just to show that we *do* care and aren't really just a
bunch of
AI routines churning through genetic algorithms in a bunch of "big iron"
somewhere out there in the cybersphere ;-)

BTW I'd also appreciate any reports of difficulty in loading the page as
I've
had problems getting it all to load via the firewall at work sometimes
and
wonder if it's happening to anyone else out there (it loads fine at home
but
then again I'm loading it direct from the server as it were )

Soooo....
   Here's wishing every one a great new year ahead, may all your
warnings be
 trivial, all your pointers resolve painlessly and of course....

 many happy routines!


 Cheers,
      Robin.


P.S. I'll leave you with these thoughts from the upcoming new generation
of
fractanauts......

            Benjamin in Japan at 10:47:55 Monday November 10 97
 I think fractals are really cool and I like to look at them on the Net.
I think I am da bomb at looking for fractals on the Net. I am 9 years
old.


             JACOB in JAPAN at 5:39:3 Tuesday November 11 97
        Hi MOM and DAD I love you. : ) My brother is very nice to me.

- -
- ------------------------------------------------------------
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"

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

Date: Tue, 6 Jan 1998 23:16:25 -0600
From: "Tim Wegner" <[e-mail]>
Subject: (fractdev) GIF encoders

Thought I'd wake everyone up and post something <g!>

We've had a devil of a time with the fractint GIF encoder. It works
OK most of the time, but for images with many repeated pixels it
sometimes fails. Similarly, the simplgif utility that mashes
multiple-image GIFs into single images fails easily for large images
(try making a 6x6 image with each piece at 600x600 and you'll see
what I mean.) These bugs are probably related because the sources for
PDGIF are based on the same original encoder code in Fractint. Many
of us of stared at the code for hours and can't see any problems.

Today I dug out some ancient encoder code based on the Unix Compress,
and it seemed to work well. There is no copyright in the sources,
although there are some names and an attribution to compress.

We're now working on removing the 2048x2048 pixel limit of Fractint,
which will expose the encoder bug even more. I don't think it would
be too hard to rip out the encoder and put in a new one.

Does anyone know of some good GIF encoder code that we could use, or
should I go ahead and use the code I found. I'm not sure where I got
it - possibly CompuServe. I'll see if I can track down the original.

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"

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

Date: Wed, 7 Jan 1998 19:14:34 +0100 (MET)
From: "Michael R. Ganss" <[e-mail]>
Subject: Re: (fractdev) GIF encoders

Tim,

I've used ppmtogif.c from netpbm in AlmondBread. I haven't had any
problems with it thus far and application extensions can be worked in
pretty easily as far as I remember. It has a bsd-style license. You
can get it from
<URL:ftp://ee.utah.edu/Misc/pbmplus/netpbm/ppm/ppmtogif.c> among
others.

- --
Michael R. Ganss        Cooper:  Look!  Ducks!  On a lake!  Ahhh.
[e-mail]        http://www.cs.tu-berlin.de/~rms/AlmondBread/

- -
- ------------------------------------------------------------
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"

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

Date: Wed, 07 Jan 1998 10:52:47 -0600
From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) GIF encoders

Tim,

 - We're now working on removing the 2048x2048 pixel limit of Fractint...

Woo-hoo!  That's one limit I'll be happy to see gone. :)

 - Does anyone know of some good GIF encoder code that we could use, or
 - should I go ahead and use the code I found. I'm not sure where I got
 - it - possibly CompuServe. I'll see if I can track down the original.

I would have suggested some code we used a while back, but I've just found
a problem with the reader not liking certain GIFs.  Since I haven't had
time to determine whether it's the LZW part or file parsing, and the LZW
compress and decompress routines are so similar, I didn't want to suggest
possibly buggy code.  And there's no telling when I'll get a chance to work
on it.

Damien M. Jones   \\
[e-mail]  \\  http://www.icd.com/tsd/  (temporary sanity designs)
                    \\  http://www.fractalus.com/ (fractals are my hobby)


- -
- ------------------------------------------------------------
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"

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

Date: Wed, 07 Jan 1998 12:04:49 -0700
From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) GIF encoders

In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> Does anyone know of some good GIF encoder code that we could use, or
> should I go ahead and use the code I found. I'm not sure where I got
> it - possibly CompuServe. I'll see if I can track down the original.

I have found the freely available GIF encoders/decoders to be of
varying quality.  The one in pbmplus has failed on occasion.  I have a
GIF image which reproduces this bug faithfully, but the subject matter
isn't fit for CDA audiences.

Basically the giftopnm code sometimes encounters bad data causing one
of the inner routines to fail with an error code that isn't checked by
the caller and the program goes into an infinite loop.  The author has
promised an update, but it hasn't materialized yet.  (He says he has a
much improved version in both reliability and performance.)

You can also try <URL: http://locke.ccil.org/~esr/giflib/index.html>
which contains a library for dealing with GIF files.  I haven't
tweaked this to compile properly on my machine at home, so I don't
know how well it will work for you.  (Then again, I have Borland
compilers.)
- --
  ``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 Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

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

Date: Wed, 7 Jan 1998 18:21:35 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) GIF encoders

Thanks Michael, Damien, and Rich. I'll investigate all your
suggestions. However I think the code I have (based on compress)
looks good. I'll post something soon and let folks beat up on it.

Whatever works for simplgif I'll probably put in Fractint as well.

Note we are talking about encoding, not decoding. The decoder
Fractint uses is based on a compression routine by Steve Bennett that
I downloaded from compuServe a decade ago. It is fast and reliable,
very well crafted. I've never had a confirmed bug report from the
decoder. Obviously, when we get to bigger images, both the encoder
and decoder are stressed.

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"

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

Date: Thu, 8 Jan 1998 22:07:49 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) GIF encoders

Michael,

> I've used ppmtogif.c from netpbm in AlmondBread.

Turns out this is based on the exact routine I found, which is in
turn based on the Unix compress!

Thanks, it makes me feel better to realize the compress routine is
widely used.

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"

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

Date: Thu, 8 Jan 1998 22:07:49 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) GIF encoders

Rich,

> Basically the giftopnm code sometimes encounters bad data causing one
> of the inner routines to fail with an error code that isn't checked by
> the caller and the program goes into an infinite loop.

Fortunately I have a good decoder, I only need a decoder.

> You can also try <URL: http://locke.ccil.org/~esr/giflib/index.html>
> which contains a library for dealing with GIF files.

This looked very promising until I realized it was Borland only. But
thanks, this was a very useful reference.

I think I'm in good shape with the compress lzw code, we shall see.

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"

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

Date: Fri, 09 Jan 1998 11:20:49 -0700
From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) GIF encoders

In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> > You can also try <URL: http://locke.ccil.org/~esr/giflib/index.html>
> > which contains a library for dealing with GIF files.
>
> This looked very promising until I realized it was Borland only. But
> thanks, this was a very useful reference.

How did you determine that?  Because I have a borland compiler at home
and I need to hack it more in order to make it work without crashing.
- --
  ``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 Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

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

Date: Fri, 9 Jan 1998 17:05:16 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) GIF encoders

Rich asked:

> How did you determine that?  Because I have a borland compiler at home
> and I need to hack it more in order to make it work without crashing.

The PC make file says it is for Turbo C, and many programs (all the
programs that have screen graphics) use BGI (Borland) drivers. But I
mispoke - I meant *PC support* is Borland only. It supports Unix (GNU
C), and I could probably make it work with djgpp. I could probably
make it work with Microsoft C if I didn't try any of the programs
that use graphics video modes.

I am filing this code away for future reference. Meanwhile, until I
see a proplem, the compress-based encoder looks like exactly what I
need.

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"

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

Date: Mon, 12 Jan 1998 10:13:24 -0700
From: Rich Thomson <[e-mail]>
Subject: (fractdev) Re: (fractint) Simplgif update

[Rerouted to fractdev]

In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> Be warned that simplgif does not save fractal data. Also make sure
> you have lots of disk space. Simplgif warns you how much it needs.

What exactly is simplgif's algorithm for combining the pieces?
- --
  ``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 Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

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

Date: Mon, 12 Jan 1998 18:35:33 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Simplgif update

Rich asked:

> What exactly is simplgif's algorithm for combining the pieces?

Simplgif opens a flat file equal to x*y bytes. Simplgif then opens
each subimage of the MIG and writes each pixel to the correct
location in the flat file, one subimage at a time. SImple, but
effective, if you have a large, fast disk.

This will be obsolete soon because we are removing the 2048 pixel
limit from the developer's version. But right now consensus is we
should release version 19.6 with the better lzw encoder as 19.6a or
19.7. The 2048 limit removal will have to wait longer.

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"

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

Date: Mon, 12 Jan 1998 17:51:09 -0700
From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Simplgif update

In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> Simplgif opens a flat file equal to x*y bytes. Simplgif then opens
> each subimage of the MIG and writes each pixel to the correct
> location in the flat file, one subimage at a time. SImple, but
> effective, if you have a large, fast disk.

It seems to me this "large, flat file" approach is only needed because
the image pieces have all been merged into one "MIG" file.  If the
images were kept as separate files, then you shouldn't need more than
2N pixels worth of memory for outputting a final image of N pixels per
scanline.  Is there any purpose tot he "MIG" file other than preparing
input for simplgif anyway?
- --
  ``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 Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

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

Date: Mon, 12 Jan 1998 20:39:06 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Simplgif update

Rich wrote:

> It seems to me this "large, flat file" approach is only needed because
> the image pieces have all been merged into one "MIG" file.

No, the MIG is really nothing more than the concatenation of the
separate GIFs. There's little difference between the GIFs being
separate or merged in a MIG. If anything, having them in a MIG is a
bit simpler.

> If the
> images were kept as separate files, then you shouldn't need more than
> 2N pixels worth of memory for outputting a final image of N pixels per
> scanline.

Your basic point is well taken (though I don't think in separate
files has anything to do with it.) If one were willing to
simultaneously decompress all the images, no intermediate file would
be needed at all. Even if the requirement is to totally decompress
one image at a time, if the subimages are read left-to-right, the
file only needs to be as high as the subimages. That's a whole lot
less than a file for the whole image.

> Is there any purpose to he "MIG" file other than preparing
> input for simplgif anyway?

The only point of the MIG is to make the files safer by putting them
together. This is easily done with GIF, because as I said, with just
minor changes to the subimage headers, and the addition of one
overall image descriptor, the LZW doesn't even need to be
decompressed. The images are (almost) just concatenated.

The history of why simplgif is the way it is is this. Lee Crocker and
Bert Tyler wrote a public domain set of routines called pdgif. I'm
not sure they ever released it. When we needed to mash the GIFs in
the MIG, Bert volunteered to take pdgif and write the code. He did so
in a brute force way, writing the big file. Part of the idea was that
simplgif could read any GIF however complex, whether interlaced, a
MIG, or whatever, and convert it to a plain single image. The desire
to convert any GIF motivated the brute approach.

It's not a hard programming job to take any good GIF code or library
and make a MIG->GIF encoder. If one knows that the MIG is from
Fractint, along the lines you suggest it could be made more
efficient.

My adaptation of Bert's simplgif uses pdgif's decoder to write the
file, then uses the gifencod/gifcompr files from the modified UNIX
compress to do the encoding. I don't use pdgif's encoder at all
because it is buggy.

If anyone wants to see this code let me know. I could make simplgif
make a smaller temporary file along the lines you suggest, but I'm
not sure it would be worth it, given that in the developer's version
simplgif is not needed at all - giant GIFs are made directly.

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"

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

End of fractdev-digest V1 #2
****************************