ANN: Colorpattern Toolkit available for download

[Wilhelm Sanke]

Eventually I managed to put together a public version of the toolkit 
that I hope is presentable as a first attempt. I needed to weed out 
remnants of earlier solutions and to do some initial streamlining of 
various different approaches that actually tried to address the same 
problems. Especially it took some time to transform a number of scripts 
that manipulated colors of  fields and graphics to the present format 
that is based on changing backcolors of chars in a field, which is 
actually much faster, but poses extra problems (see below).

The toolkit at present consists of three parts: A standalone splash 
stack, the toolkit stack, and a first rudimentary help stack containing 
basic information about the toolkit (not much more than in this post) 
and some additional examples how to create specific categories of 
patterns.You need to start with the standalone "Colorpattern Toolkit 
Intro" and go to the toolkit from there. The help stack can be accessed 
both from the "Intro" and "Toolkit" stacks, but also opened 
independently in the Metacard or Revolution IDE.

A number of additional functions I have experimented with are left out 
to restrict stack size to a tolerable level, but the toolkit contains 
all the functions necessary to produce color patterns like shown in my 
"Pattern Art" galleries on my website <http://www.sanke.org/MetaMedia>.

The files can be downloaded from here: 
<http://www.sanke.org/Software/PatternToolkitWin.zip> (3.6 MB) and 
<http://www.sanke.org/Software/PatternToolkitMacOS.sit> (2 MB) or from 
pages "Pattern Art" or "Sample Stacks" of  <http://www.sanke.org/MetaMedia>.

Requirements:

The program needs a computer with at least about  2 GHz speed and 1 GB 
RAM for satisfactory performance.

Performance time for the different functions (manipulating the colors 
and spatial order of the 19.200 color units) is between 400 milliseconds 
and 4 seconds on the average (for the above described configuration on a 
Windows computer), with some functions needing more time.
Such a "fast" average speed is a basic requirement, because before you 
arrive at a satisfactory image you usually need to apply quite a number 
of consecutive (or repetitive) color transformations.

MacOS computers with their slow graphics pose a special problem. It is 
almost impossible to work with the toolkit on my 667 MHz Powerbook - 
unless you have ample time and patience; my wife's iBook with 1.3 GHz 
and 1.2 GB RAM is somewhat faster, of course, but still not 
satisfactory. The slow performance can be felt especially when the new 
color values are added "on screen" in real time, however, also 
processing within and between arrays (offscreen) is much slower than on 
a Windows machine.
My older Windows 98 computer with 1 GHz and only 256 MB RAM is very much 
faster than both Macs.
For a future separate MacOS version I intend to move most color 
transformations offscreen, which would however eliminate some 
interesting visual effects.

The problem of the "engine leak":

Working with the toolkit you should take into account the "engine leak" 
bug of the Revolution engine, apparent especially on WindowsXP, to a 
lesser degree for MacOS, a bug which is interestingly completely absent 
on Windows 98 (see also my post "Near completion of Color Pattern 
Toolkit: IDE, engine, and font problems (part two)" of Nov 25, 2005 (and 
following posts)).

The program gradually and progressively gets slower. Sometimes it even 
seems to freeze for a while - the engine is "choking" - which may last 
in extreme cases for two to three minutes for the execution of one 
script that would normally take 1 second. After that the engine may 
return to normal speed, but probably not quite. Quitting the IDE or the 
standalone - not only closing the stack - once in a while is recommended.

Basic structure of the toolkit:

There are about 200 functions - many of which are just slight variants 
of a common basic algorithms - ordered in five "groups" to produce color 
patterns and to manipulate them by changing colors and spatial order of 
the color units;

1. "Primary patterns" which form the basis for further processing

This group contains "random" and "preset" options. With "random" the 
start RGB values and the incremental XYZ color values are chosen 
randomly along with the "scope" factor that describes the extension of 
color changes for a chosen number of color units (in the direction(s) 
specified in the individual functions).
With "preset" the presently existing values for RGB, XYZ, and "scope" 
are being used, which can be set by using sliders.

2. "Color tranformations"

Various ways to change colors: Rotating RGB values, complementary 
colors, extracting gray values, add/subtract color values to existing 
values combined for RGB or separate for each RGB value, "diffuse" 
colors, produce "warmer colors", "pastellize" colors etc.

3. "Spatial transformations":

Duplicating (multiplying) parts of the image, mirrors and partial 
(including diagonal) mirrors, distortions, stretching and enlarging 
parts, flipping the image (horizontally and vertically), shifting, rotating.

4. "Overlays"

Different kinds of overlays inside a given image: right-left, 
top-bottom, diagonal, horizontal + rotated vertical version of image, 
crosswise and "twisted" overlays etc.
All of these overlays can use any combination of the RGB values, i.e. 
for each of these functions there are 7 options, which can be set in  
three RGB check boxes.
There is an additional possibility to produce overlays of *two* 
previously produced and internally stored images with the options 
combine "positive", "negative" and "multiplied".

5. "Transitions"

Transforming existing color structures into segments containing equal 
colors - option "plain" - or "gradients", producing gradient segments 
reaching from the first to the last color value of a horizontal, 
vertical or diagonal extension of a segment. Segment sizes can be chosen 
or created with random options (comprising options that produce several 
segments of different size during one pass). Of course producing 
gradients across the whole width or height of an image is possible.-

Storing image data:

There are six possibilities to store the image data in the stack itself  
for further processing (or even permanently) or during sessions and four 
options to save the images or the image data in external files: "export 
as PNG" (this interestingly produces the smallest file size), "export as 
JPEG", "save array data", "save HTMLtext" of the image. The array and 
HTMLtext files can be read in again from the toolkit to resume 
processing of the stored image data. Reading in an external data file is 
fastest for the HTMLtext files, but the HTMLtext files are generally 
bigger than the array data.

Storing the array data *internally* will increase stack size by about 
300 KB for each stored image, meaning the stack size of the toolkit will 
increase to about 10 MB when all 6 storage slots are being used, but 
there is a button to delete all internal image data (with the exception 
of the "image" itself, i.e. the field containing the color chars).


Issues of using char color:

Manipulating the backcolor of chars is considerably faster (more than 10 
times) than changing the color values of a comparable number of fields 
or graphics. Also chars in a single field do not slow down the overall 
performance of both IDEs as it happens with a greater number of fields 
or graphics. However, backcolors of chars present some problems not 
occuring when using fields or graphics.

For example, for the 120X160 color chars of the image field you 
automatically get an extra 119 chars, namely CRs, which you have to 
consider in your scripts when changing colors and spatial structure. One 
way I overcome this problem - in case spatial order is of importance for 
the functions - is to put the 19200 (times 3) color values into a 
two-dimensional array (eliminating the 119 CRs), change colors and 
locations inside the array, and then put back the array values into the 
chars using a correctional CR variable.

One feature - or another bug - of Revolution can be watched when new 
color values are imposed over the old backcolors of chars: When the new 
backcolors are drawn "onscreen" they appear with a smaller size in such 
a way that the underlying old colors still "shine" through. Only after a 
simulated mouseclick on the field - or after hiding and showing the 
color field  - the new colors will be adjusted to their proper size. 
This effect can be watched at best by choosing option "multiple 
horizontal" of button "random horizontal" of  group "primary patterns".

Crossplatform problems with fonts:

Until recently I used the space character of font "Wingdings" with a 
textsize and textheight of four for each value. This worked perfectly on 
my WindowsXP computer and my Powerbook and produces the best visual 
representation of the image colors (the images of my pattern galleries 
were created on the basis of these properties).

But I had to notice that Wingdings is displayed differently on my wife's 
iBook, on my Windows98 computer, and even on the WindowsXP machine with 
older versions of the Metacard/Revolution engine; I verified these 
findings by testing on a number of other computers at my workplace. Such 
problems of course would not arise when fields or graphics are used as 
color units.

After a lot of experimenting I now chose font "Courier New" with a 
textsize of  6 and a textheight of 4 (thus causing overlapping of chars) 
to produce the 4x4 pixels color units. This produces the same kind of 
fine-grained images as before unless you apply the "interrupted" options 
of "primary patterns" where each second char in horizontal, vertical, or 
diagonal direction is left out (this was the basis for my "Scottish 
plaids" images). The visual representation is much better here with 
Wingdings, but after applying the next transformation, e.g. using 
"horizontal overlay" of a diagonally interrupted primary pattern, the 
effect of using "Courier New" equals that with Wingdings.
Using "Courier New" appears to be stable on all computers I have used 
for testing so far.

Help file:

Future versions of the help file will come with more detailed 
descriptions of how to work with the many and diverse possibilities of 
the toolkit. It will also contain more strategies and recipes to produce 
specific categories of patterns. At present it contains 6 examples 
structured in a number of successive steps.

For the time being I offer a very general recommendation how to proceed:

Because of the complex structure of the small universe "toolkit" and a 
great deal of  built-in "randomness" it is in many cases difficult to 
anticipate the effects of the various interrelated options.

Therefore "intelligent design" is not applicable here, you should rather 
choose an approach of "intelligent evolution", connected with the 
principle of "serendipity" (see Horace Walpole), to unexpectedly come 
across fortunate constellations and discoveries. Or to quote another 
writer, you could apply "intelligence guided by experience" - the way 
Archie Goodwin solved his problems in the Nero Wolfe stories by Rex Stout).

I am aware that such a remark may arouse suspicions and a defensive 
discussion in medievally fundamentalistic circles, those in the USA not 
excluded. But that remark is certainly true for my "Colorpattern Toolkit".


Why a standalone "intro" stack produced with the standalone builder of 
the alternative Metacard IDE?:

Revolution does not like modified answer and ask dialogs as added 
substacks (I use dialog versions that can be placed anywhere in the 
stack area or on the screen). Any time you would open the stack in 
Revolution you would get warnings, and it is impossible to produce 
standalones with the Revolution standalone builder when these dialogs 
are already embedded as substacks. By the way, even with standard 
dialogs it is impossible for some still undetected reason to transform 
the toolkit stack into a standalone inside the Rev IDE.-

I chose the option to encrypt the toolkit and to configure it in a way 
that it works only in conjunction with the standalone splash stack 
"Colorpattern Toolkit Intro". On the other hand the toolkit is offered 
as freeware.

Those who should be interested in what is going on inside the toolkit 
stack can inspect the two sample stacks I have already mentioned in my 
posts to the Revolution list: <www.sanke.org/Software/ScanTest2700.zip> 
and stack <www.sanke.org/Software/RevTestStacks.zip>, the latter of 
which is also attached to Bugzilla 2217.
These stacks show the underlying principles of producing color patterns 
which I use in my toolkit (many other approaches are possible) and can 
be used as a starting point for individual experimenting. Anybody 
interested in more detailed information about specific functions can 
contact me (on the list or off-list), and I will at least provide an 
outline of the applied algorithms. I am also considering to put together 
a few (unencrypted) sample stacks with a smaller matrix of color units 
to demonstrate particular possibilities of creating color patterns.


Enjoy if you like to play with colors,

Wilhelm Sanke