On this page I continue to update a log of fixes to and additions to ConjPic®, my computer program ConjurePicture (ConjPic for short) for the creation of images using Iterated Function Systems (a branch of Fractal Geometry). This is primarily for my own use in developing the software, but may be of some use to someone doing similar work. See ConjurePicture.
Go Home.
To-do list
I am just starting back (28 July 01) on adding to my ConjPic program for generating images, pictures, and movies using iterated function systems (IFS), a branch of fractal geometry. It is amazing to see that the last time that I dug into the coding (in Visual Basic), was about two years ago! I have just been too preoccupied with my Web site. But now, I want to get back in and seriously mess around with the code. Here are "just" a few of the things that I want to do.
1. Do an overview of the more than 200 subprograms that make up my ConjPic program -- some being as simple as three or four statements, others being a bit more involved, such as matrix transformations of transformations, detailed file manipulation, and the sequencing of movie time sequences (scripts).
2. Fix a problem in which, having generated a set of IFS images and building a picture from them consisting of a superposition of the images, I find -- in some cases -- that the program has lost track of the colors assigned to some or all of the transformations. That might occur in only those cases in which I plagiarize from one image to serve as the basis for building another. That might be easy to test for, but not necessarily easy to fix.
3. Augment the file-manipulation facilities. At the moment, I can store an image or a picture (as a bmp file) and convert it to a jpg or gif file via other software (Hijaak Pro). What I have only partially developed is the ability to store, in a properly sequenced way, the IFS codes for generating images -- and structures of those, in turn, for generating pictures and movies. Visual Basic is very deficient in not having the file support that I need -- the ability to store variable-length binary records. I have to program all the nasty details of file positioning and record and byte counting from scratch. I need that capability in order to be able to build a library of image templates -- the sets of IFS codes. Then, rather than having to build a mountain from scratch each time that I need one, I can delve into a library of such images and either use one directly or modify it further. Besides, the compression ratios are favourable, ranging from 500:1 to 1,000,000:1.
4. I need to add more types of distortion (transformation) of the seed image into transformed images of the seed within an IFS.
5. Augment the ability to copy an image or picture (or, more correctly, their structured sets of IFS codes) such that I can also rotate those transformed sets as well as just translating them along x or y, and expanding or shrinking them, as now exists. That is going to be rather tricky. It will be helped, however, by a technique which I came across a couple of years ago by which, instead of using 2 x 2 matrices to handle transforms in two dimensions, one uses 3 x 3 matrices. For a 3D system, one would use 4 x 4s. The other type -- 2 x 4s -- is only used for building houses!
6. Improve the capability of generating matched pairs of images so as to create stereograms (matched-pair type). That is working now; however, it only handles a somewhat simplistic way of doing so. That also implies the ability to create not just ordinary movies (as is working now), but movies in stereo. The stereograms referred to here are true-color matched pairs, without the need for anaglyph (red-blue) glasses.
7. Add the ability to do IFS transformations in three dimensions, not just the two that I use now.
8 Augment these efforts by the use of L-systems algorithms, simulating biological growth, and other aspects of plant modeling, as is exemplified so well in the wonderful Xfrog software of Greenworks in Germany. See Web 330 and Web 335.
9. Add ray-tracing, so as to account for and render the effects of sunlight bouncing all over, and of surface texture! That will be tricky, because the virtual surfaces that I generate do not have a description in three-dimensional space comprised of differentiable mathematical functions. The surface is comprised of a set of points, each of which is the end point of a Markov chain of possible branching alternatives.
10. The ability to have the program "look at" a photograph and reduce it to a set of IFSs from which the picture can be regenerated.
11. The ability to use much of the above for pattern-recognition -- of, for example, faces. I know what the basic algorithm is for this. It was invented by Michael Barnsley, the inventor of the IFS. See Iterated Systems: http://www.iterated.com/, the corporate home of Michael Barnsley, inventor of iterated function systems, co-founder of Iterated Systems, and author of Fractals Everywhere. A must-see site!
Admittedly, goals 7 to 10 are very ambitious, but it does no harm to keep them in mind! I can dream, can't I?
Apart from these technical goals, there is one that I also have in mind that is more humanitarian, if I may be so bold. There are people who have very limited use of hands, but who might like to create images. Such people already have available special hardware and software by which they can use their eyes to pick out letters and menu buttons (perhaps by staring and blinking?), allowing them to do word processing. I would like to do what I can to expand their repertoire to use similar facilities and my program so that they can conjure up images. There is a small company in the Ottawa area that has developed the word-processing system. Its clients are overjoyed! One of them is a paralyzed scientist who had been hoping for years to have the ability to type documents. I am not one of those who sneer at what they consider to be the mundane ability to type!
When I did an end-of-file on a recent message, my Norton AntiVirus software got activated. Did the Sircam virus get me after all? It did a scan of all of my files, which took at least ten minutes, maybe twenty. Everything seems to be OK. I have 72,392 files scanned! About 25,000 of those are re the Internet. I do save a lot of bookmarks! Too many books, too -- according to my wife!
Image of green mountain, and how it was built
I have made a bit of progress yesterday (31 July 01) with my ConjPic (Conjure Picture) program for conjuring up images using iterated function systems (IFS) (fractals). Progress was made on two fronts: (a) rendering vs branching; and, (b) how to build a mountain.
Rendering vs branching
In my previous message I had reported that I had neglected to even use my ConjPic program for two years, as I had become preoccupied with building my Web site. One problem that I had stated was that, in building a picture as an overlay of several images, the program did not appear to preserve color assignments of the transforms within an IFS (image), or from one image to the next within a picture. That came as a surprise to me, as I had tested out this feature as having worked at the time. So, what was the problem? On further testing yesterday, it turns out that this apparent failure to preserve color relationships holds only when I ask the program to do the impossible, and by that, here is what I mean.
Over two years ago, I had developed several techniques for rendering the generated image so as to modify the color to be assigned to each pixel before it is plotted. For example, one technique treated the question as to how one could simulate the buildup of snow on an object from falling snowflakes. Another technique was more sophisticated, and involved a two-pass effort under which, in the first pass at the calculated total picture, a pixel-density representation of the picture (i.e., overlay of images) was calculated. On a second pass of the image, the pixel density in the vicinity of the pixel to be plotted ( a kind of rolling average in two dimensions) was then used to calculate the color of the pixel to be plotted.
When building a picture from a set of individual images, I had programmed two modes of doing so. One is to just let the computer choose the images already built, and to just assign them in their chronological sequence to form the list of images that are to comprise the picture. The other mode is to force the user to manually enter both (a) the number of the next image to form the picture set, and (b) whether that image needed to be rendered in the sense stated above for the two-pass rendering process. It turns out that, since programming that, I had developed an additional rendering process involving only one pass, but which involves an even more complex procedure involving branching relationships and color assignments within an IFS, by means of which color could be propagated from one part of the IFS to another through the linkage of the transforms of the IFS. This involves a hierarchy of stem-and-branch stuctures, with up to three stems (transforms) serving as sources of branches, and with up to six levels of branches for the descendents of each stem.
A few days ago, in building a picture from a set of IFSs, I had used the manual procedure for building a picture, and had specified the rendering option. Bad choice. So, although the problem was my faulty perception of what choice to make, I will modify the program to add a few words in that choice option message to remind the user that rendering is not the same as branching.
How to build a mountain
I have spent hours on different occasions trying to find a systematic way in which to design a generic IFS that will generate a reasonable-looking mountain. Why should that be much more difficult than building a pine tree of at least comic-book quality? The pine tree is easy, as is illustrated elsewhere on my site. I have constructed mountains before; however, they were always on an ad-hoc basis. Today, for the first time, I have discovered a systematic way in which to build a mountain -- one in which repetitive aspects of a mountain are generated naturally from the underlying design of the IFS.
For an example of a mountain generated today, see Figure Mount1.jpg. Snow on green mountain. Shown there also is the single IFS template that generates that picture -- a single image in this case.
The key to this new discovery is in making two of the transforms of the IFS into skewed rectangles (trapezoids), one being the pink one in the bottom area on the right, the second being the very skewed parallelogram appearing as lines of dashed black and green at the bottom, just right of centre. This image consists of seven transforms linked by three stem transforms serving as the origin of branches, proceeding to two levels of branching for each stem. The total data to generate the picture is 200 bytes. The data-compression ratio calculated by ConjPic is 1,455.84:1 before applying jpg compression. The bmp file size is 1,023,030 bytes, generated from plotting 291,169 points. One might, therefore infer that the actual data-compression ratio, before applying jpg-compression, is 1,023,030 / 200 = 5,115.15. The jpg image occupies 77,922 bytes (76.0 KB). Another way of considering this is that the total compression ratio, including jpg-compression, is 77,922 / 200 = 389.6.
Conclusion
This new ability to build mountains in a systematic way will make that process easier in future. It also makes it much more amenable to the making of movies, because the mountain can now be modified in a systematic way -- at least under my method of movie-making -- by the variation of the value of a single parameter, to change, for example, a rocky footpath into a mountain in as many steps as one pleases. In retrospect, the picture would have been better had the shimmer effect on the water been more pronounced.
For some progress made soon after the above (On 5 Aug 01.), see: Picture MtSand1.jpg. Sand and mountains at dawn.
To be continued . . .
Go Home.
You can e-mail me at waynerp@sympatico.ca
