From: owner-fractdev-digest@lists.xmission.com (fractdev-digest) To: fractdev-digest@lists.xmission.com Subject: fractdev-digest V1 #2 Reply-To: fractdev-digest Sender: owner-fractdev-digest@lists.xmission.com Errors-To: owner-fractdev-digest@lists.xmission.com 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" 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/ dmj@fractalus.com / my gallery of fractal art: http://www.fractalus.com/ - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Sun, 9 Nov 1997 16:42:15 -0600 From: "Tim Wegner" Subject: (fractdev) broken? fractdev seems to be broken also. Tim - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Sun, 9 Nov 1997 16:51:51 -0600 From: "Tim Wegner" 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 Tim - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Tue, 11 Nov 1997 13:08:54 +0100 (MET) From: "Michael R. Ganss" 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. rms@cs.tu-berlin.de http://www.cs.tu-berlin.de/~rms/AlmondBread/ - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Tue, 11 Nov 1997 10:01:52 -0600 From: "Damien M. Jones" 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/ dmj@fractalus.com / my gallery of fractal art: http://www.fractalus.com/ - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 11 Dec 1997 15:55:44 EST From: RBarn0001 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: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Sun, 9 Nov 1997 18:13:03 -0500 From: Sylvie Gallet 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 OK. Here is my fractal test: 6cntst12 { ; . t=3D 0:32:28= =2E58 ; Copyright Sylvie Gallet, Nov 09, 1997 ; ; 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 ; ; 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 ; ; 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: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Tue, 16 Dec 1997 11:53:51 -0700 From: Rich Thomson 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 rthomson@ptc.com - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Tue, 16 Dec 1997 17:48:16 -0600 From: "Tim Wegner" 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 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 Tim > - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Mon, 29 Dec 1997 18:36:56 +0000 From: robin bussell 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 " peter2@sofha.de "I love Fractint, its an awsome program. " BoyOfDstny@aol.com "I would also like to thank you guyz at the Stone Soup Group for proving wrong the saying, "You get what you pay for" " ewk@edsr.com "THE ONLY reason I have a computer is FRACTINT.(believe it)" hukmut@gccweb.net "P.S. I love you guys" kevin.weedon@diamond.co.uk "Go on with it, thanks for the pleasure you give me, Cornelius" cvmeurs@pi.net "Thanks to all fractint programmers for this fantastic program!" fries@conti.de "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!" gunnar@foxinternet.net "Best wishes from Fractal Fanatic Female in Sweden, Liselotte Frejdig. Keep up the good work!!!" frejdig@algonet.se "Fractint is THE ONLY WORTHWHILE PROGRAM IN THE UNIVERSE! Thank you much!" omomom@iquest.net 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! "Two words... Power Mac." bltaylor@junction.net "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?" pkcnz@imagina.com "on bended knees, deep sigh: Fractint for Mac Os8???? Is that possible? please say "yes!" " mgewuerz@mines.edu "PLEASE ! help me i NEED a copy of Fractint for my Power Macintosh" hienz@hartingdale.com.au "I would kiss the gnarled toes of anyone who would do a port of Fractint over to the Macintosh platform." nok@interport.net "we users will do all we can to make you presidents of the Earth or whatever you prefer..." karo@arkzin.com 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." karo@arkzin.com 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!" hsoj@geocities.com 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" peter2@sofha.de "A version for Windows95, with true-colour (24 bit) support. Please!" o.marshall@student.unimelb.edu.au "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!)" KA5FUN@AOL.COM 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: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Tue, 6 Jan 1998 23:16:25 -0600 From: "Tim Wegner" Subject: (fractdev) GIF encoders Thought I'd wake everyone up and post something 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: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Wed, 7 Jan 1998 19:14:34 +0100 (MET) From: "Michael R. Ganss" 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 among others. - -- Michael R. Ganss Cooper: Look! Ducks! On a lake! Ahhh. rms@cs.tu-berlin.de http://www.cs.tu-berlin.de/~rms/AlmondBread/ - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Wed, 07 Jan 1998 10:52:47 -0600 From: "Damien M. Jones" 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 \\ dmj@fractalus.com \\ 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: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Wed, 07 Jan 1998 12:04:49 -0700 From: Rich Thomson Subject: Re: (fractdev) GIF encoders In article <199801070516.XAA13074@virtual5.c-com.net> , "Tim Wegner" 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 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 rthomson@ptc.com - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Wed, 7 Jan 1998 18:21:35 -0600 From: "Tim Wegner" 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: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 8 Jan 1998 22:07:49 -0600 From: "Tim Wegner" 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: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 8 Jan 1998 22:07:49 -0600 From: "Tim Wegner" 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 > 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: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Fri, 09 Jan 1998 11:20:49 -0700 From: Rich Thomson Subject: Re: (fractdev) GIF encoders In article <199801090407.WAA22659@virtual5.c-com.net> , "Tim Wegner" writes: > > You can also try > > 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 rthomson@ptc.com - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Fri, 9 Jan 1998 17:05:16 -0600 From: "Tim Wegner" 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: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Mon, 12 Jan 1998 10:13:24 -0700 From: Rich Thomson Subject: (fractdev) Re: (fractint) Simplgif update [Rerouted to fractdev] In article <199801100608.AAA27799@virtual4.c-com.net> , "Tim Wegner" 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 rthomson@ptc.com - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Mon, 12 Jan 1998 18:35:33 -0600 From: "Tim Wegner" 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: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Mon, 12 Jan 1998 17:51:09 -0700 From: Rich Thomson Subject: Re: (fractdev) Re: (fractint) Simplgif update In article <199801130029.SAA24236@virtual3.c-com.net> , "Tim Wegner" 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 rthomson@ptc.com - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Mon, 12 Jan 1998 20:39:06 -0600 From: "Tim Wegner" 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: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ End of fractdev-digest V1 #2 ****************************