From: fractint-owner@xmission.com (fractint Digest) To: fractint-digest@xmission.com Subject: fractint Digest V1 #4 Reply-To: fractint@xmission.com Sender: fractint-owner@xmission.com Errors-To: fractint-owner@xmission.com 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" Subject: Re: (fractint) Deleting and Renaming Janet sighed: > Oh well 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: fractint@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractint" ------------------------------ Date: Thu, 14 Aug 1997 22:31:28 -0600 From: "Tim Wegner" 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: fractint@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractint" ------------------------------ Date: Thu, 14 Aug 1997 23:50:07 -0400 From: Les St Clair 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 to switch between Fractint and GWS. (to avoid possibly scrambling the image between switches, 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: fractint@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractint" ------------------------------ Date: Thu, 14 Aug 1997 23:50:12 -0400 From: Les St Clair 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) - - Les - ------------------------------------------------------------ Thanks for using Fractint, The Fractals and Fractint Discussion List Post Message: fractint@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractint" ------------------------------ Date: Thu, 14 Aug 1997 22:08:43 -0600 From: Kevin Smith 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 kevster@compusmart.ab.ca - ------------------------------------------------------------ Thanks for using Fractint, The Fractals and Fractint Discussion List Post Message: fractint@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractint" ------------------------------ Date: Thu, 14 Aug 1997 23:15:51 -0500 From: "Paul N. Lee" 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) > 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: fractint@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractint" ------------------------------ Date: Thu, 14 Aug 1997 23:39:46 -0700 From: jpreslar@memphisonline.com 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 to switch between Fractint and GWS. (to avoid possibly > scrambling the image between switches, 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: fractint@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractint" ------------------------------ Date: Thu, 14 Aug 1997 14:05:47 -0700 From: "Jay Hill" 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 ; gumbycat@ix.netcom.com z = c = pixel: z2 = (1/z ^^ p1) z = fn1(c * (1 - z2 ^^ z2)/(1 + z2 ^^ z2)) |z| <= p2 } DomeCity { ; Dome City by Jay Hill ; Jay.R.Hill@cpmx.saic.com 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: fractint@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractint" ------------------------------ Date: Fri, 15 Aug 1997 10:00:09 -0400 From: Lee Skinner Subject: (fractint) Re: Making my Hi Les, >>Of course, the best thing about zooming out is finding interesting new areas to zoom back into<< 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: fractint@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractint" ------------------------------ Date: Fri, 15 Aug 1997 08:14:25 -0600 From: Kevin Smith 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 kevster@compusmart.ab.ca - ------------------------------------------------------------ Thanks for using Fractint, The Fractals and Fractint Discussion List Post Message: fractint@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractint" ------------------------------ Date: Fri, 15 Aug 1997 07:39:47 -0700 From: "Mike or Linda Allison" 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 gumbycat@ix.netcom.com 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 > To: fractint@mail.xmission.com > 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: fractint@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractint" ------------------------------ Date: Fri, 15 Aug 1997 11:04:05 -0600 From: hluna@interware.com.mx (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: fractint@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractint" ------------------------------ Date: Fri, 15 Aug 1997 11:17:39 -0600 (MDT) From: Jason Hine 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: fractint@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractint" ------------------------------ Date: Fri, 15 Aug 1997 11:38:03 -0600 From: Rich Thomson Subject: Re: (fractint) Re: deep zooms In article <199708150343.WAA23092@raid2.fddi.phoenix.net> , "Tim Wegner" 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 rthomson@ptc.com - ------------------------------------------------------------ Thanks for using Fractint, The Fractals and Fractint Discussion List Post Message: fractint@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractint" ------------------------------ Date: Fri, 15 Aug 1997 13:09:46 -0600 From: hluna@interware.com.mx (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: fractint@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractint" ------------------------------ Date: Fri, 15 Aug 1997 17:01:46 -0400 From: Sylvie Gallet Subject: (fractint) Re: Making myself known >> Of course, the best thing about zooming out is finding interesting new= >> areas to zoom back into >> 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: fractint@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractint" ------------------------------ Date: Fri, 15 Aug 1997 17:38:05 -0700 From: "Peter Jakubowicz" 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: fractint@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractint" ------------------------------ Date: Fri, 15 Aug 1997 15:11:41 PST From: NOEL_GIFFIN 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: fractint@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractint" ------------------------------ Date: Fri, 15 Aug 1997 15:42:23 -0600 From: Rich Thomson Subject: (fractint) Re: good general book on fractals In article <199708152131.OAA18423@siskiyou.brigadoon.com> , "Peter Jakubowicz" 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 rthomson@ptc.com - ------------------------------------------------------------ Thanks for using Fractint, The Fractals and Fractint Discussion List Post Message: fractint@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractint" ------------------------------ Date: Fri, 15 Aug 1997 18:44:52 -0400 (EDT) From: aq936@freenet.carleton.ca (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: fractint@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractint" ------------------------------ Date: Fri, 15 Aug 1997 17:42:34 -0600 From: Rich Thomson Subject: Re: (fractint) question for developers In article <009B8D15.FFC3BFC0.17@triumf.ca> , NOEL_GIFFIN 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 rthomson@ptc.com - ------------------------------------------------------------ Thanks for using Fractint, The Fractals and Fractint Discussion List Post Message: fractint@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractint" ------------------------------ Date: Fri, 15 Aug 1997 18:45:59 -0500 From: "Paul N. Lee" 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: fractint@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractint" ------------------------------ Date: Fri, 15 Aug 1997 18:35:03 -0700 From: jpreslar@memphisonline.com 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: fractint@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractint" ------------------------------ Date: Fri, 15 Aug 1997 18:48:19 -0500 From: "Paul N. Lee" 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: fractint@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "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 "majordomo@xmission.com". 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 local-fractint@your.domain.net 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.