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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
