Conference rusure::math

I was able to reproduce the dragon on the cover of Mandelbrot's book
(in only 5 colors instead of the 25 due to lack of resolution on my
PRO/350 color display), but it took an amazing amount of number
crunching; in fact, I did the calcs on the VAX and copied a display
file over to look at it.  Based on that, it seemed out of the question
to try some of the 3D dragons based on quaternions.

Finding the right starting point to get the dragon was an interesting
sub-problem.

I may have a bit of free time and will try to re-do the program for
a uVax workstation in the near future.

- Jim

I am also working on a pair of programs on the Vax for the Mandelbrot 
set.  It uses the VT125 ReGis set at a resolution of 230x230 (damned 
odd-y mapping!).  It also is compute intensive if you include too much 
of the actual Mandelbrot Set.  However, if you select areas close to the 
set, but without much overlap into the set, you get real nice results.  
Only four colors though :-(.  I'll post them here when complete.

 [} Mike {] 

It's only a start;

	CASTOR::DR5:[RABAHY]ZOOM.FTN

Enjoy,
David.

RE: .1  Jim would you be willing to make your software available?  I have
	access to a PRO 380 with color and a VAX and would was in the process
	of doing the same sort of thing when someone directed me here.

		Thanks,
		Tony

A quick & dirty black and white version (I've only got a VT62 at home
and a VT100 at the office) is available at:
DONJON::USER1:[GOLDSTEIN.PDT]MANDEL.{FOR,EXE} .
It lets you specify the upper left corner, gap, size of grid, and
number of iterations to test for membership.  You can optionally
watch it compute, one line per pixel, then feed in your choice of
five ASCII characters that represent proximity to the set. 

This way, you can play around with low-resolution until you home in
on a nice area.  One nice place to start is the vicinity of
(-.743898,.104508) with a gap of .000001 on a small (20,20) grid.
Then home in on part of it.

Now if I only had a VT241!

Fred

The VAX version for the VT125/240/241 is available at 
OVDVAX::SYS$DATA_DISK:[KIER]  MANDLBROT.FOR and MANDLZOOM.FOR.

It uses 200x200 resolution with tick marks at 1/20th each axis.  Ranges 
and tick interval are displayed in right margin.

Forgive the code, I got a little sloppy toward the end with my 
technique.  Its hard to do any significant test of this thing via a 
2400baud line.

	Enjoy,
		 [} Mike {] 

I've placed a copies of a few of the programs I'd written some time
ago to play with the self squared dragons from Mandelbrot's book
in ADVAX""::USER1:[JROTH.BITMAP.DRAGON]...

There are 3 programs that create data files and a kludge to
display them using REGIS.

The program CMAP creates a contour map of LOG(LOG(ABS(Zn))),
where Zn is the n'th iterate of Z := Z**2 - C for a given area
of the C plane.  LMAP is a conformal mapping of this function
to map Z := L*Z*(1-Z) and is handy for hunting for values of
L to use in creating self squared dragons since the best ones
arise via points lying within the 'sprouts' of the L map.

DRAGON creates self squared dragons as outlined in Mandelbrots
book, assigning colors to the body of the dragon as well as the
contour map of the corona surrounding the dragon as in CMAP/LMAP.

The data generator programs are set for a (200,400) grid, but are
parameterized and can be used for other pixel aspect ratios and
screen sizes.

The program DMAP reads the data files produced by these programs
and lets you play with them after a fashion.

There are a few data files also laying around in the directory.

Higher resolution and greater color map range would be very desirable.
I did experiment briefly with loading the map on a PC/350 but it was
a bit of a pain since the files were quite large; I may work on it again
though since there is a /380 available with DECNET.  I had wanted to do
an 'unnatural images' demo similar to the natural images demo we used
use on the PC/350 but ambition dwindled before I finished it all.

I'll be interested in seeing what others have done in this area...

- Jim

================================================================================
 EDEN::ENGEL              CT Development/Support Notes        31-JUL-1985 18:02 
 Note 680.0                     -< MandelZoom >-                     1 response 
--------------------------------------------------------------------------------
 
This document describes a version of the MANDELZOOM algorithm which
runs on the VAX and creates image files for the PRO.
 
The purpose of this program is to explore the Mandelbrot set.  For
background information on Benoit B.  Mandelbrot, his set, or this
algorithm, see the August 1985 issue of Scientific American.
 
The primary feature of our implementation is the ability to generate
images with 256x240 pixel resolution using up to 4096 distinct colors.
 
A color map file is used to assign colors to contours of the set.  A
contour is defined by the number of iterations required to cause the
points within the contour to flee the set.  (Actually this is a somewhat
fuzzy statement, but sufficient to get a feel for what's going on.)
 
The Mandelbrot set is completely contained within a circle of radius two
around the origin of the cartesian (complex) plane.  To create an image
you need to specify a window, a color map file, and a few other
switches.
 
A window is defined by its lower left corner and its height.  The width
is automatically set to 1.6 times the height to match the PRO's aspect
ratio.
 
A color table file consists of up to 4096 sets of integers: n r g b.
The first number is ignored (use it to keep track of index numbers).
The next three numbers represent the color's red, green, and blue
components.  These integers must be in the range zero to fifteen.  The
numbers can be separated by spaces, tabs, or carriage returns.  Do not
use commas or other punctuation.  For an example, refer to the COLOR.TAB
file.
 
The switches will be explained as we step through a sample session:
 
The files you should have obtained:
                               EVE::[DAHL]MANDEL.DOC
                               EVE::[DAHL]MANDEL.EXE
                               EVE::[DAHL]COLOR.TAB
                               EVE::[DAHL]GRID.EXE
 
Make sure you have at least 180 free blocks of disk space.
 
        Run MANDEL
 
        Lower left corner (x,y)? -1.5 -.0000005
 
This sets the lower left corner of the window at the given (x,y) point.
 
        Offset by [-3,-2] (0 or 1)?  0
 
Don't worry about it.  If it makes no sense type 0.  If it does, you may
figure out why this is handy when we explain the GRID.EXE program.
 
        Scale? .000001
 
This sets the height of the window.  The four corners of the window
become: (x,y) (x,y+scale) (x+1.6*scale,y) (x+1.6*scale,y+scale).
 
        Maximum iterations?  80
 
This number should be at least as large as the number of colors you've
defined in your color table file.  The further you zoom in on the set
the larger you should make this number.  At low magnification 10 is
fine.  Try numbers in the range 10 to 512.
 
        File name to save picture (.IMG)? test
 
Pick any file name you like.  Keep it less than eight characters long.
File will be called test.img.  Running GRID.EXE on test will produce
testg.img.
 
        Computing contours:  0123456789
 
This is where the number crunching is done.  If you've missed the set it
will go super fast.  It slows down as the maximum number of iterations
increases.
 
        Min Color Index=52 Max Index=79
 
This tells you the range of contour indices you've encountered.  Use
this information to tailor your color map.
 
        Color table file name? color.tab
 
Tell it the name of your color table file.
 
        48 entries in color table.
 
Its telling you how many colors you defined in your file.
 
        Shift table to min index (0 or 1)?  1
 
Enter 0 if you want the contour indices to map directly to your color
indices.  Enter 1 if you want the minimum contour index to map to color
index 1 and so on.
 
        Writing image file:  0123456789
 
The output file is being written.
 
To view the image you will need to copy the file to the [IMAGES]
directory on your PRO.  Then run the "Display Images" application
described in a separate note.
 
Once you've created an image you may want to enlarge a portion of it.
To facilitate this we've included the GRID.EXE program.  It will
superimpose a white grid on top of an image file.  View the resulting
file (testg.img if the input was test.img) the same way you would any
other image file.  By clever choice of window coordinates you can easily
determine the coordinates of any grid box.  Note that there are sixteen
by ten divisions to the grid.
 
Send comments, suggestions, window coordinates and color table files to:
 
                               EDEN::ENGEL
                               EDEN::DAHL
 
Enjoy!
 
Tone Engel  (Principal Author)
Tom Dahl    (Creative Advisor)
 
================================================================================
 EDEN::DAHL               CT Development/Support Notes        31-JUL-1985 22:05 
 Note 680.1                     -< MandelZoom >-                         1 of 1 
--------------------------------------------------------------------------------
 
PS.  The files are on device USER: on EVE. so the full spec is:
 
	EVE::USER:[DAHL]
 
In this directory is a sample zooming sequence of six files:
 
	M3.IMG
	M31.IMG
	M311.IMG
	M3111.IMG
	M31111.IMG
	M311111.IMG
 
Each one is ten times the detail of the previous; thus the sequence spans
a range of 100,000 powers of enlargement.  Excersize for the student: determine
from one frame where the next one is zoomed in on.
						-- Tom
 
Thu 1-Aug-1985 08:09 Maynard Time

ref the VT241 Mandelbrot give in .6.

It gives a beautiful picture with

	x = -1.5
	y = -0.0000005
	s =  0.000001
				(these are the numbers suggested in .7)
Suggestion:

	Displaying the picture with MANDLZOOM currently takes quite awhile.
	It seems to me that with a simple modification, the program could
	draw fast horizontal vectors instead of hundreds of adjacent points
	of the same color.

	(for even more speed, program could select some points and do a
	fill or a flood, but this would probably be too difficult for a quick
	enhancement)

	Another slowdown is that the program seems
	to be currently outputting a "W(In)" to set the color to n for each
	point.  Even if the program insists on outputting each point separately,
	I'd imagine that the vt241 only needs "W(In)" when n changes.

/Eric

RE: .6

I just wanted to let you know that I appreciate your effort in developing
these programs.  I don't know much about the theory (I plan on reading the
Scientific American article), but I enjoy the pictures.  Is there some
algorithm that can be used to pick new values for the program that will
generate interesting pictures?  For example, how did you pick the values
you did in your mandelb.com file?  Or the values given in reply .8?  It
takes such a long time to display the pictures I don't want to waste time
with useless values?

	Mike

RE: .8

Are the image files that are generated for the PRO bitmap images or gidis
files?  I am not familiar with the "display images" application on the
PRO, but I do know that you can display gidis files using SIGHT.

	Mike

Re bitmap images...

The files are bitmap images, one 64 (16 bit) word per scan line,
4 scan lines per disk block, 240 scan lines of red, green, then blue
(60 blocks per color = 180 blocks).  The NATIMG is a nice utility
for displaying them and I had planned to make my programs output
to it but as a prior note shows its been done already.  The results
are very impressive!

See CTNOTES for more goodies by the same people...

I tried the other REGIS program mentioned earlier and find my own,
crude as it is, a lot faster since it draws vectors of adjacent pixels
so if you're limited to REGIS that may be worth trying.

- Jim

RE: .12

I guess I didn't make myself clear in .11.  A friend of mine here in PK3
has a PRO-350 and the only way he has of displaying images is with an
application called the "GIDIS frame viewer".  You imply in your response
that there is an application something like a "BITMAP frame viewer".
Where can I get a copy of this application?  The PRO is on the network so
we can copy the application.

Also, in your response you mention REGIS.  Do you have a utility that will
convert these bitmap images to REGIS?  How about SIXELs?  If so, then the
images can be displayed on a VT240, which is what I would like to do.

	Mike

If you ever saw the 'natural images' demo, this is the program I
referred to.  You can find a copy along with a number of astounding
.IMG files in EVE::USER:[DAHL]...  You simply copy NATIMG.TSK over to
your PRO and run it from the toolkit.  It displays all files it finds
of the form *.IMG in the directory [IMAGES].  You need a color monitor.

A recent CTNOTE has further info.

The images produced by this display are spectacular.

The programs I referred to in a prior note produce REGIS output
and do group adjacent pixels into vectors; try running DMAP
and specifying DRAGON3.LLM (logarithmic magnitude map file) and
DRAGON3.HUE (the color map), they're in ADVAX::USER1:[JROTH.BITMAP.DRAGON].

- Jim

Re: reponses for VT241 Mandlzoom

Yep, I know I'm wasting bandwidth...  I am running through a 2400 baud 
Infotron stat-mux to a LAT-11 to an overloaded 11/780 so I was working 
for quick and dirty ways of getting it out.  Testing iterations are 
painful!  What I did was to try to get a fixed number of characters to 
go out the port each time that would ensure DMA transfer if available 
(such as if I changed to a DMF-32 port).

I agree that there are numerous ways to modify it for better 
efficiency...  I would suggest that setting the pixel vector multiplier 
to n where n is the number of pixels of like color would be best for 
areas of the screen that are largely one color.  I'm currently in the 
middle of an extended work break and can't get to it.  If someone does 
it, please post the location of the code here.

As for the points I selected... SWAG and trial and painful effort.  If 
anyone wants to modify this to use arrow key directed graphic cursors to 
figure out the corner location and span for the next zoom, I would 
greatly appreciate it.  Also, you might consider changing the initial 
point from the lower left corner to the center of the viewing area.  Its 
frustrating not to know whats below and to the left of your focal point.

I made a version for my Atari 130XE which has 16colors with 80x80 
resolution, but unfortunately the precision of the floating point is too 
low to allow reasonable zooming (*sigh*).

	 [} Mike {] 

================================================================================
  SARAH::F_KLEINSORGE     CT Development/Support Notes        2-AUG-1985 15:29  
  Note #680.2                   -{ MandelZoom }-                        2 of 2  
--------------------------------------------------------------------------------

	Having just gotten the SIGGRAPH course notes...

	People interested in more about Mandelbrot and Julia Sets might
	want to obtain:

	Frontiers Of Chaos, MAPART by H.-O. Peitgen and P.H. Richter
	of the University of Bremen.

	The book contains text by, B.B. Mandelbrot, G. Eilenberger and
	H.W. Franke.  It also contains many high quality color examples,
	as well as the mathmatical procedures to produce your own.

	-Fred

	ISBN 3-920699-65-3

As long as we're on the subject, does anyone have any other algorithms
to produce fractal images?  The Mandelbrod set is nice, but it tends
to whet one's appetite for more and different flavors of fractal.
Is there a generalized, simple (like Mandelbrod's) algorithms to
produce a set with fractal value n, where n can be changed by the
user?

I think the George Lucas application of this runs on a Cray.  Something
a bit less intensive might be nice...

Re .-1

	See ADVAX::USER1:[JROTH.BITMAP.DRAGON] for fractal dragons,
Lambda maps, Mu maps with a variety of options.

	If you have a PC350 or 380 and a color monitor, there are
some programs and results in the [.PC350] subdirectory.  The .IMG
files therein can be displayed via the NATIMG task.  The fortran
programs there are a bit crude (lots of scaffolding still in place),
so they may not be too useful to anyone else at present.

	I have not had the time (the weather's too nice) to do any
dragons over the quaternions, or mappings of Julia sets, but have a
pretty good idea of how to do them.  But not just now.

- Jim

I need some help in understanding the Mandelbrot set.  I read the article
that appeared in the August issue of the Scientific American and I have
a question.  I interpreted the article as saying that the pictures that
appeared in the article were mappings of the complex plane.  Given the
correct function and a range of values I should be able to reproduce these
pictures.  My question is, is this interpretation correct?  If so, what
values do I have to plug into Mike Kier's or Jim Roth's programs in order
to reproduce these pictures?

	Mike

Both of these seem to work pretty well, although both could probably use 
some additional magnification.

$run mandlbrot
-1.17170929
.257522663
.00000342405
picture1

$run mandlbrot
-1.5
-0.0000005
.000001
picture2


	 [} Mike {] 

Since not everyone bothers to report their work here,
let me say that this algorithm (for drawing the Mandelbrot set)
seems to be spreading wildly around DEC.

Tony Lekas (LASSIE::LEKAS) has a nice version for the PRO 380.
LASSIE::PETTENGILL is also knowledgable about this version.
(Data generated on a VAX.)

Steve Klein (NOVA::KLEIN) has a nice version for a VT240 on a VAX.
NOVA::RAVAN is also knowledgable about this version.

I have a program that takes Tony's data and outputs it on a VT240.

Re: .15 or so:

> ...	What I did was to try to get a fixed number of characters to 
> go out the port each time that would ensure DMA transfer if available 
> (such as if I changed to a DMF-32 port).

Nice idea but probably not worth the effort.  The crossover between DMA
and non-DMA is just about where performance breaks even...the cost of
setting up map registers for DMA is what determines the break-even point.

The best approach is to try to write a large number of characters in one
operation, which is kinda tough to do from high-level languages.  Writing
redundant information (just to get a lot of bytes in the output buffer) is
not the way to go about this, however.

On another note, has anybody written to Cornell for an order form for those
pictures?  If there's a quantity discount then perhaps there are enough folks
who'd like 16-inch (~41cm) color glossies to make a quantity.  (\If/).

  John

RE: .20

I tried these sets of numbers, but neither set generates the pictures from
the article that I can remember.  One picture I remember shows a
figure-eight-looking object laying on its side.  How can I reproduce that
figure? I don't have the article here so can't cite the page number, but I
think you know the one I mean.

	Mike

Re: .-1, where to look for inteesting patterns...

Roughly speaking, areas near the boundry between the set of points
which diverge to infinity and the set which converges to a stable
set of limit points are the interesting places to look.

These points will lie along the cardioid curve bounding the main
region:

	x = .5*cos(theta)-.25*cos(2*thete),
	y = .5*sin(theta)-.25*sin(2*theta)

This curve is studded with circular sprouts, which are further studded, etc.
For example, in plate A on page 18 of the Scientific American article, there
is a sprout with a 29 way branching 'eye' (if you look closely, you can count
the branches) emanating from the tip.  This sprout is therefore bonded to the
main region at the point given by theta = pi*(1-1/29), or about x = -.741224,
y = .107802, with a window size of about .01.  So centering the window
a little to the left and above gives the picture in plate A, and the other
plates B,C, D, and E are easily seen to be successive magnifications of the
regions therein. [know that the area marked 'A' on page 17 is wrong]

Points near the boundry take more iterations to approach asymptotic
divergence, this seems to be the basis everyone uses for assigning colors
to the points.  For example, I estimate LOG(LOG(ABS(Zn))) after n iterations
and assign a color based on that. (I break off the iteration early if the
point grows too large and extrapolate the final value, actually)
I don't know by what method the green contours on the plates of page 18 of
Dewdney's article were done, but note that they correspond to the small
whirlpools exactly!  There must be a simple way of determining that.

To create images of self squared dragons you can compare points which have
not diverged after n iterations to the table of stable attractor points for
that mapping and assign a color based on that -  this is how the 25'th order
dragon on the cover of Mandelbrot's book was colored in.  (I also tried
assigning a color based on the phase angle of the points which did not
diverge, but it wasn't all that interesting.)

If you specify a color like 'G 0,1' to the DMAP program, you'll see a
plot of the points which have not diverged, as 0 is assigned to these
points (for the Lambda and Mu maps) and thus the actual boundry will
be visible.

Anynow, I hope this information is useful...  its mainly a matter of choosing
a sprout with a reasonable amount of branching (try theta = pi*(1-1/p),
with p = a small prime number in the range of 7 to 29 in the expressions
for x and y above) and then zooming in from there.

- Jim

The approximate (Xcenter, Ycenter, Width) values to reproduce plates
A thru D on page 18 of Dewdney's article are:

A:	-.746224, .110302, .01
B:	-.745224, .112552, .0015
C:	-.745224, .113052, .0003
D:	-.745429, .113009, .00006

The colors are up to you, use lots of iterations...

- Jim

I've got a TOPS-10 MACRO version which does a pretty good job.  Displays
on a VT241 (finally figured out some use for color).  It lets you position
a cursor on the screen to define the corners of a smaller square to zoom
in on.  

The limitation of 4 colors is really disgusting!  One suggestion, due
to Robert Praetorius, is to calculate a histogram of counts for the whole
grid.  For example, if HISTO(50)=383 that means that 383 points out of
the whole grid took 50 iterations to blow up.

Using this histogram, you can assign the color levels so that there are
approximately equal amounts of red, green and blue in the result.
How I envy you guys with 4096 colors!

I am working on a PDP-10 multiprocessor version of the program in case
our dual processor doesn't have enough to do.

The spread of Mandelthings within DEC is obviously a plot by big BLUE to
sap the strength of our company by occupying the time of many employees
and many VAXen.  It's also a pretty simple and colorful application for
a multiprocessor, since each point of the grid is independent of any other.

Other people at DEC I've heard are working on Mandelbrot set displays
are Paul Winalski and John Hallyburton.

I am considering writing a program to compute and display the Mandelbrot set on
a Pro (yes, I know how long it will take).  My current concern is coloring the
set and its environment. 

There are several problems involved.  The first is selecting some attribute of
each point to be mapped to its color.  For example, the recent _Scientific
American_ article proposes using the number of iterations required for the
magnitude to exceed two.  In previous responses, Jim Roth has advanced using
log(log(abs(Zn))), where Zn is the value obtained after n iterations. However,
this function has an infinite range, and Jim does not explain how it is mapped
to a color.  He also indicates the iteration is not carried to completion if
the magnitude grows too large, but does not indicate what method is used to
extrapolate the value.  Which method is better?  How many iterations are
required to produce a good picture?

The second problem is selecting the actual colors to be used.  The range of the
previously mentioned values may become restricted as smaller parts of the set
are selected, so several people have advocated examining the set to determine
the range, then selecting the mapping from that range to the colors used.  This
will most likely involve doing the calculations twice or performing a
significant amount of i/o to disk to store the results, so I would like to
select the mapping before doing the calculations.  Two ideas I have for this
are to examine a random selection of points to get an approximation of the
range or to select a color scheme that will not be sensitive to small ranges,
for example, instead of progressing from light red to medium red to dark red,
it would progress from red to green to blue  . . . to dark red to dark green .
. . .  Thus, a large range would show many small bands of quickly changing
color, and a small range would show larger bands.  The large case might not be
as striking as it would be if the colors changed more gracefully, but at least
the small case would show up nicely, instead of being almost invisible.  Would
these ideas work?

The third problem is selecting the progression of colors.  Ideally, the points
would be black (0, 0, 0) in the Mandelbrot set and red (15?, 0, 0) far away
from it.  What comes between?

There is another problem, not related to coloring.  After I have the basics
working, I would like to leave a program running indefinitely:  Given a
repertoire of pictures, the program would display them, changing the screen
about once a minute.  Meanwhile, the processor would be busy computing another
picture to be added to the list.  Once this is done, it would display the
latest picture with the others (perhaps more frequently).  It would also select
an "interesting" place to examine for the next picture.  This place might be
selected from a small part of the latest picture or from somewhere else.  I
would like ideas on how to have a program select an "interesting" place. 
Should I look for rapidly changing areas of a picture?  Should I select an area
at random, examine a number of points in it, and make some determination from
that? 


				-- edp 

Re .29

	Actually my first experiments were on a PC350 in black and white;
I had just gotten a copy of "The Fractal Geometry of Nature" and wished
to produce plots of dragons such as the 5 by 5 order one on the cover,
and explored the lambda map as a way of finding the parameters to produce
a dragon of given bifurcation order and twist, etc.  It occurred to me
to also plot the lambda (or mu) map in colors, but I didn't explore all that
far before putting it aside, and only had a monochrome monitor.

	I would highly recommend biting the bullet and writing a work file
of contour values, as the computation for many interesting patterns is really
extensive, and selecting the colors is an artistic problem after the data is
ready.  I've computed quite a few patterns and then played with the color
map many times before being satisfied.

	The idea of LOG(LOG(ABS(Zn))) stems from a comment Mandelbrot made
in passing with reference to a picture of a sprout in his book: that the
shaded regions were bounded by 'lemniscates' (ribbons?) representing
contours of the sets of points where ABS(Zn) < R.

	Consider the iteration

		Z(k+1) = Z(k)**2 - Mu,

	If |Z| >> |Mu|, this is approx

		Z(k+1) ~= Z(k)**2
		Z(k+2) ~= Z(k)**4,
		Z(k+j) ~= Z(k)**(2**j),
		Ln(Z(k+j)) ~= (2**j)*Ln(Z(k)),
		Ln(Ln(Z(k+j))) ~= j*Ln(2)+Ln(Ln(Z(k))),

	So, you can stop iterating when the magnitude of Z is large and save
Ln(Ln(Z(k))) (a fractional interpolation), and the iteration number (integer).
I used a cutoff of 256 which guarantees the range of |Z| will lie in the
interval [256,65536) and logs base 2.

	Snarf a copy of ADVAX::USER1:[JROTH.BITMAP.DRAGON.PC350]CMAP350.FOR
for working code. (Using integers saves space, rather than storing floating
point numbers, and bytes don't have enough range). Positioning the radix
point based on the maximum number of iterations you specify makes full use
of all 15 bits.

	The colors can then be defined as linear interpolations of
selected ranges of the 15 bit numbers above onto colors via a small table.
This can give subtle shading of the regions around objects similar to the
pictures in various articles I've seen.  I got good firey prominances and
the like that way.

	I write natural image .IMG files and display them with the NATIMG
task.  Also keeping statistics of how many iterations per scan line on the
average lets you know roughly how to start assigning colors, tho a random
shot with a previous color map from a prior image often looks good.

	You can use a little theory such as mentioned in a prior note
to get some symmetry to your patterns, just random shots often gives
random turbulence, it's nice to have some order beneath the surprising
complexity I think.  Often hundreds or a thousand iterations are needed
when zooming in since points close to the boundry take longer to start
converging.

	The possibility of automating the process is interesting, but
I could never figure a way of systematically finding interesting patterns
except by probing around 'by hand'.  For example, I gave the coordinates
of the sequece of pictures in Dewdney's article; how could you really
'discover' that neat figure eight thing in the final picture? that's
a real difficult pattern matching problem!

	In my [.PC350] directory there are a number of .IMG files you could
look at.  The programs are kludgy tho since I don't really know what I'm
doing and am just trying things out. This log business is an important
refinement to consider.

	What I've been too lazy to do is make an online color map
setup; that would be really neat, to just move a cursor to a spot and say
'put a range of hues here'.  That would be much better than copying .IMG
files repeatedly...  it would be a nice program for other purposes as well.

- Jim

One very simple way of assigning colors (which I used for my VTxxx 
and Atari versions) is to simply take the iteration count modulus the 
number of colors:

Color number to use = mod(iteration count, available colors)

or if you want to reserve "background" for the Mandlebrot set itself:

Color number to use = mod(iteration count, available colors - 1) + 1

and 

If iteration count > max iterations then color to use = 0



	 [} Mike {] 

Since I have only a VT241 with 3 colors (plus black for the set itself) one
of the major problems is assigning colors to make the pictures look interesting.
I have mentioned the histogram method before.  It results in each of the
three colors being used in about equal proportions, but is non-linear, and
often doesn't show some interesting details.  One other technique which a
colleague of mine suggested is something he calls the "band" method of coloring.
Using the number of iterations as the array value, you shift that number
right by a few bits, then keep only the 2 low order bits of that result
and assign a color based on that value.  This is a linear scheme with one
strange property: "blue" in one area of the picture is not necessarily the
same contour as "blue" in another area.  The advantage of this method is
that it shows a lot of detail, even with a limited number of colors.
I usually make a first plot using the histogram method, then re-plot
using the band method.  The key to the band method seems to be to select
the two bits you use with care: if you use the lowest-order bits, the contours
change too fast, if you select very high-order bits, you lose detail.
It is a real advantage to have the array of calculated values laying around
so you can re-do the coloring using different schemes.

Some more Mandelbrot programs, all in directory
ELUDOM::LSE$:[WINALSKI.MANDELBROT]

MANDEL_F.FOR
MANDEL_D.FOR
MANDEL_H.FOR
GIDIS.INC      (FORTRAN include file)
MANDEL.COM     (sample batch job to run the program)

    These three programs calculate the Mandelbrot function on a 240x800 or
    240x960 pixel grid, depending on your input.  The output is in MANDEL.DAT,
    in "Lekas Normal Form," suitable for plotting by my MANDEL_SIXEL_n programs
    or by Tony Lekas's GIDIS plotter for the PRO.  You supply the complex
    coordinates for the upper left corner of the plot, the right real
    coordinate, and the number of iterations used to decide if a point is in
    the set.  From this, the program calculates the lower imaginary coordinate
    (using the aspect ratio for the pixels) and the real and imaginary inter-
    pixel intervals.
    
    MANDEL_F performs calculations in F-floating, MANDEL_D in D-floating,
    and for real masochists, there's MANDEL_H, which uses H-floating.

    For VT241s, you should ask for a plot 800 pixels on the X axis by 240 on
    the Y axis.  For the PRO-380, ask for 960x240 [I think].  The aspect ratio
    in the programs is hard-wired for the VT241.  You will have to change it
    for the PRO.

MANDEL_SIXEL_4.PLI
MANDEL_SIXEL_8.PLI
MANDEL_SIXEL_16.PLI
MANDEL_SIXEL_32.PLI
MANDEL_ALT_32.PLI

    These programs take a Mandelbrot data file in "Lekas Normal Form" (such as
    a MANDEL.DAT file from MANDEL_F) and produce a SIXEL graphics file suitable
    for TYPEing on a VT241.  To use them, you DEFINE logical name MANDEL to be
    the file name of the .DAT file.  The program produces a "name.SIXEL" file
    containing the SIXEL data.  The MANDEL_SIXEL_n files use the histogram
    method and plot 4, 8, 16, and 32 contours, cycling through the colors.
    MANDEL_ALT_32 assigns colors using the number of iterations modulo 3.
    
    To compile these programs, you must say PLI/G_FLOAT.
    You can direct the output to a different filename than MANDEL.DAT by defining
    a logical name MANDEL.  See the MANDEL.COM file for sample input.

MANDEL_F_SEG.FOR
MANDEL_D_SEG.FOR
MANDEL_H_SEG.FOR
MANDEL_PASTE.FOR
SPIDER_1_RUN.COM

    These programs are versions of MANDEL_F, MANDEL_D, and MANDEL_H modified
    to take advantage of the parallelism available in a VAXcluster.
    SPIDER_1_RUN is an example of a command procedure that parcels out the work
    for a Mandelbrot calculation into 8 segments, creates 8 batch jobs to run
    the segments, then pastes the resulting data files into a master file in
    "Lekas Normal Form."  SPIDER_1_RUN.COM is set up with the queue names in
    use on the TL&E VAXcluster, but it should be very easy to hack the DCL
    to use the queues available on your own cluster.  Note that the MANDEL_PASTE
    program reads its parameters from DCL symbols rather than input data.

ELUDOM::LSE$:[WINALSKI.MANDELBROT] also contains many .SIXEL plots of
interesting places I've found around the Mandelbrot set.  Feel free to copy
any of these files.

--PSW

I still need actual numbers to use for the colors.  I have an artistic ability
in this area of almost zilch -- can someone provide numbers that will create
a nice rainbow?  Jim, I believe several of the .IMG files in your account
involve objects that change gradually across the spectrum of colors -- do you
have the algorithm for selecting such colors?


				-- edp

Re coloring the images...

To be honest, I twiddled them by hand...  My iteration routine does a sort
of 'block' normalization of the resulting map of positive 15 bit integers
to keep the range of the largest number near 2**15 [large in the sense of
the extrapolated value of the Zn in question], and I simply 'dumped' the
first few files I created to have a look at the values.  Didn't really
know what to expect otherwise...

Then I defined a color map (.HUE file) with entries of the typical form

	MapLow, MapHigh, RedLow, RedHigh

The resulting table filled in by the .IMG creator was simply searched for
contour map magnitudes falling in the low and high ranges and did a linear
interpolation of the corresponding color.  To handle colors made up of
several primaries, just duplicate the range 'in parallel' for the
other color components.  Once I created a few typical images, then I
could just try one of the old .HUE files to get a quick look.

A better solution would be to edit the colors on the PRO with a cursor, this
is definitely on my stack of hacks to do...

A hue-lightness-saturation option would be nice too.  Also special effects
such as the stripes in one of Dewdney's pictures would be nice; I had a
very close reproduction of the sequence of pictures he had.  By the way,
if you look closely at the cover picture and the picture of the mini
region in the article, you can actually see faint contour lines in the
reddish region around the edge of the picture, its just perceptable.

These methods will result in images as good as the state of the art
published elsewhere if we had decent display hardware: aside from the
limited bitmap resolution some of my images look 'just like' those
pictures.

Another note mentioned histogram color mapping, this must be worth looking
into.

As an aside, I looked at the generated code in the iteration routine
in one of my programs.  It may be worth coding the inner loop in assembler
to make optimal use of registers and save a bit of time.

Finally, I've written a program to generate images of fractal dragons in
3 dimensions (such as the ones done by Alan Norton at IBM a while back
for Siggraph), but the results so far are a bit dissapointing.  He must
have had a lot of heuristic hacks to smooth out the images, mine look
pretty fuzzy, but are recognizable.  There are a number of things I
can try still tho. The image illumination and projection program is
very inefficient too, but that can be cleaned up later.  Now, *this* must
be a job for vax clusters!

- Jim

Re .35:

> To be honest, I twiddled them by hand...

The images I was referring to with gradually changing colors were not images
of the Mandelbrot set, but images of more mundane things, such as spheres.

> As an aside, I looked at the generated code in the iteration routine
> in one of my programs.  It may be worth coding the inner loop in assembler
> to make optimal use of registers and save a bit of time.

I will be writing most of my code in Macro-11.  I think I can get the time for
the innermost loop down to about 100 microseconds per iteration (on a Pro, not
a VAX).  Let me know if you are interested. 


				-- edp

One other thing I've tried with the Mandelbrot set is antialiasing the
image, but its a fourfold increase in computation.  It's definitely
worthwhile for fractal dragons, and gives nice results on complex
Mu map iterations as well; probably one would want to apply it only
after a really interesting place is found.  I used the usual
1-2-4 weighted filter mentioned in computer graphics textbooks and have
tried it with both 256 by 240 (low res) and 512 by 240 (medium res)
pictures.

Another special effect that's nice is to produce clouds of fractal dust
ala the earlier notes on fractals and superpose this with a Z map -- nice
for rendering dragons of measure zero.

--

Some other people who are playing with 3 dimensional images on the PRO
are Tom Dahl and Tone Engel (EDEN::), and Wim Engelese (don't know the node
off hand).

- Jim

RE: .29

I've used the count of iterations to reach abs(z(k))>2 and it gives good 
pictures.  I haven't tried ln(ln(z(k))).  My upper limit on count has varied 
from 100 to 5000, with 100 giving quite good pictures.  

The way to map colors depends a lot on the resolution of your display 
and the number of simultaneous colors available.  It looks like the 
SciAm pictures were done with about 1024x1024 resolution and thousands 
of simultaneous colors.  I'll try to be general in the following but bear 
in mind that I've used a LA50 (b+w), VT240 (4-level gray) and VT241 (4 
colors).  What I'd like to use is a Rainbow which gives 16 simultaneous 
colors.

We start with a picture described by numbers I with Imin <= I <= Imax
and a set of colors C(K) with goes from 0 <= K <= Kmax, 

The two simplest methods (I'm making up these terms, since I've never 
seen this written down) of mapping are: 

	contour bands:	consecutive values of I map to different colors, 
		up to a maximum, and then they repeat.
		This programs rather simply:

		if ( MOD( I , J ) .eq. K ) then use C(K)

	intensity mapping: this represents increasing I by colors which 
		increase in some property.  
		If we have a table of I(K) values this
		programs as 

		if ( I < I(0) ) then use C(0)
		if ( I(K-1) <= I < I(K) ) then use C(K)

And these can be combined by using contour bands and then choosing color 
A and color B by intensity mapping.  It looks to me like the SciAm 
article uses intensity mapping and combined mapping.

Kier uses a modified contour mapping in which he takes J=Kmax+1=4
Roth uses an intensity mapping.  Appellof uses an intensity mapping in which 
the I(K) are chosen to divide the picture into approimately equal areas. 
The band method he mentions is Kier's method preceded by a division of I 
by a power of 2.

I've used the combined method with J=2 and I(K) chosen to divide the range 
[Imin,Imax] into Kmax equal parts.  This gives good results on a LA50, 
VT240 and VT241.  I do a quick sample over the desired space to get an 
estimate of Imin.  This estimate is quite good, since in most areas, 
there are a large number of points with I=Imin.  Then I set Imax to 
Imin+Kmax*6, because I've found that this provides the maximum detail I 
can see on a VT240 with a grid of 230x230.  It also speeds up the 
computation.

This gives me about eighteen contour bands in three colors.

Next question is how to choose the colors in the set C(K).  On a VT241, 
the set black, green, yellow, red looks good.  I'm trying to map black, 
dull red, yellow, bright white (the black-body temperature colors), but 
the 241 is giving me trouble.  A more general way is to 
choose colors in a line or simple curve through the color solid.  See 
Page 148 of the VT125 User's Guide for a rather techie presentation of a 
widely known concept.  For example, the colors can move from medium gray 
through slate blue to intense blue.  Or from dark green to light yellow. 
Or from red through orange to yellow. This kind of thing gets more 
tineresting when you have more than three simultaneous colors 
to play with.

I agree with Roth that choosing the colors on esthetic grounds while you 
are looking at the screen will give best results.  It looks to me like 
most of the colors in the SciAm pictures were chosen this way.

Several people have asked for a way to choose interesting regions of the 
complex plane automatically.  I've interpreted this as not uninteresting 
regions, that is regions which are neither far from nor inside the 
Mandelbrot set.  My quick scan tells me the range of iteration counts 
within the current square, and I save the coordinates of all points with 
the count at the middle of this range.  Then I pick one of these points
for the center of my next square, and cut the size of the side in half.
The result is a randomly generated sequence of not uninteresting 
pictures.  Of course, an enlightened human search will usually find 
really interesting pictures much faster than this rather dumb search.

My own program, a modification of Kier's, is optimized for my vice: 
impatience.  I want to see results as soon as possible.  So the same 
program does the computation and displays the results as it goes along.  
It draws Regis vectors, which improves performance as predicted in these 
notes, but only by about a factor of four.  It draws vectors all over 
the screen, to maximize the initial rate of useful information, and 
gradually fills in the spaces.  On a display with a block fill 
primitive, I could block in the picture and refine it, but on a VT241 
this is a lose.

What I plan to do next is use an asynchronous QIO to allow the user to 
interrupt the display and control the position, mapping and color.  I 
may also put back the intermediate file.

This program, in its current state, is in

	PULSAR::DISK$WORK:[WALLY.MANDEL.PUBLIC]MANDELBROT.FOR

The looping version is in 

	PULSAR::DISK$WORK:[WALLY.MANDEL.PUBLIC]MANDELOOP.FOR

Wally

A suggestion for choosing "interesting" regions:  Interesting regions are, I'd
guess, those that (a) are neither too complex nor too simple; (b) show a broad
range of variation in "simplicity" - lakes of things in the set with complex
curlicues of boundary points, etc.

One thing that seems as if it would capture "complexity" is the (spatial)
Fourier transform.  Regions completely filled with a lot of random variation -
"too complex" - should have just about all their Fourier coefficients at high
frequencies.  "Uniform" pictures should have most of their coefficients at
low frequencies.  What you are looking for is pictures with a wide range of
frequency components, with a fairly even distribution of energy across the
range.  (Energy is by physical analogy; it's been a long while since I looked
at this, but it's related to something like the square of the coefficient.)

So, the proposed automatic zoomer would sub-divide the current picture into
some number of regions - perhaps 4 equal-size rectangles, perhaps 5 - those
4 plus one concentric with the original rectangle, so as to minimize the
chance of missing interesting stuff along sub-region boundaries, compute the
FT of each (not much precision needed, there are probably good approximate
algorithms to use), and would choose the best, by some measure (maybe just
maximum range of frequencies with cooefficients larger than some cutoff; maybe
something a bit more elaborate).

Instead of looking at Fourier coefficients, the coefficients with respect to
some other orthogonal transform would be either easier to compute or would
give better choices.  There are a bunch of standard transforms used in image
processing work - Hankel and Walsh transforms come to mind - that might be
appropriate.

I have neither the equipment nor the time to try this out; if anyone does, let
us all know what happens.
							-- Jerry

I thought to compute the transform of the images and see what happens, but
have not tried it yet.  Since logarithmic spirals and circular inversions
figure so prominently, a circularly symmetric transform may be the most
appropriate. Also an N'th iteration of the function is analytic, having
real and imaginary parts, so a full complex transform would be the best.
A complex cepstrum may be nice too...  It's surprising that someone
else hasn't published something on this in fact.

I've had the library order a few papers on the Mandelbrot set, and would
like to study these when they arrive before going further though.  There
seem to be many interesting relationships out there - the contour lines
of constant ABS(Zn) are claimed to be identical to the electrostatic
equipotentials that would arise if the Mandelbrot set were a charged
conductor!  It's plausable, but not clear just why.

It still seems more of an artistic problem of attractively centering and
then coloring in the images and you can see certain features showing up
systematically (such as the number of arms of each spiral and how many
sets intertwine vs the rational angle the sprout you're magnifying
is bonded at).  I've spent more time playing with that than actually
exploring the set (a real way to waste time).

- Jim

There is a note file for discussing the Mandelbrot set, programs and tools
for calculating and plotting it, and related topics in:

	PICA::SYS$NOTES:MANDELBROT.NOT

--PSW

re: .41
No such file.
							-- Jerry

Re .41

I think he means PIXEL:: (listed in EASYNOTES)

- Jim