PainShop Pro Scripting - bit pattern magic

Author

bit pattern magic

Bruce

2007-09-23, 6:20 pm

Hi Folks,

If you like to play with numbers, then you will enjoy Clifford
Pickover's book "Wonders of Numbers". Cliff explores patterns in
sequences of numbers that you would never have thought possible. There
are some amazingly simple algorithms that produce the most interesting
patterns (e.g., faberge' eggs). On of the simplest geometric patterns is
the boolean OR operation.

Make a new raster image (800x800) and color each pixel according to its
x,y coordinate. c[x,y] = (x or y) mod 255 (the mod 255 is just to make
sure that the range stays in 0..255)

My script attached is an attempt to do this but it is painfully slow. I
did take the advice of the "scripting" download and removed all
unnecessary settings but it seems to have a lot of unnecessary screen I/O.

The sample gif attached was generated with a Delphi program in less than
3 seconds. I wasn't patient enough to see how long the PSP script would
take but it looked like going all night until it crashed with a warning
about the history being full!

Can anyone suggest a way to speed up a script or possibly to process in
the background and only refresh the screen at the end? Can the UNDO be
switched off inside a script?

Bruce

Spandex Rutabaga

2007-09-23, 6:20 pm

Bruce wrote:
>
> Hi Folks,
>
> If you like to play with numbers, then you will enjoy Clifford
> Pickover's book "Wonders of Numbers".

I play with the numbers in my bank account but there are never
enough of them to have a really good or even worthwhile game.

> Make a new raster image (800x800) and color each pixel according to its
> x,y coordinate. c[x,y] = (x or y) mod 255 (the mod 255 is just to make
> sure that the range stays in 0..255)
>
> My script attached is an attempt to do this but it is painfully slow.

It is slow because you are executing an interpreted command for
every pixel in your image. In effect you have a 640,000 command
script. Obviously that will take some time to process. You may
find it quicker to write a simple format file, process that file
with Python (or your favorite language), and load the result back
into PSP, all with your script. You could use a human-readable
file such as PBM or a binary file such as graphic RAW for this.

> The sample gif attached was generated with a Delphi program in less than
> 3 seconds. I wasn't patient enough to see how long the PSP script would
> take but it looked like going all night until it crashed with a warning
> about the history being full!

Getting on for a million commands is quite a lot for a command
history.

> Can anyone suggest a way to speed up a script

See above.

> or possibly to process in
> the background and only refresh the screen at the end? Can the UNDO be
> switched off inside a script?

Did you try recording a script, switching off the Undo system
in preferences, saving the script and copying and pasting the
relevant command from this script into yours? (And then perhaps
restoring the state of the undo system at the end of the script.)

> for i in range(1,800):
> for j in range(1,800):

Your script doesn't appear to initialize the (0,0) top left pixel
to any specific color.

Bruce

2007-09-25, 3:18 am

Spandex Rutabaga wrote:
> Bruce wrote:
>
> I play with the numbers in my bank account but there are never
> enough of them to have a really good or even worthwhile game.
>
>
> It is slow because you are executing an interpreted command for
> every pixel in your image. In effect you have a 640,000 command
> script. Obviously that will take some time to process. You may
> find it quicker to write a simple format file, process that file
> with Python (or your favorite language), and load the result back
> into PSP, all with your script. You could use a human-readable
> file such as PBM or a binary file such as graphic RAW for this.
>
>
> Getting on for a million commands is quite a lot for a command
> history.
>
>
> See above.
>
>
> Did you try recording a script, switching off the Undo system
> in preferences, saving the script and copying and pasting the
> relevant command from this script into yours? (And then perhaps
> restoring the state of the undo system at the end of the script.)
>
>
> Your script doesn't appear to initialize the (0,0) top left pixel
> to any specific color.

Hi Spandex

I don't think that 640000 cycles is much for a computer. In C, the same
effect can be achieved in under 1 second. After all, 800x800 is not a
big drawing and how else do you process images if not pixel by pixel?

It is a good idea to consider processing the graphic outside of the
screen refresh but this exposes a significant flaw in Python. No
build-in canvas! No wonder the language has not progressed commercially.
Which is a pity since the syntax is really elegant.

I tried to install the 3rd party PIL library but can't get PSP to find
it. Seems that PSP only looks in its own Python folder. I suspect that
there may also be a version conflict since PSP is tied to a specific
Python library.

But then I thought, I don't want to process outside of PSP. The
intention is to make use of the scripting and graphic features of PSP.

Switching off the undo system does make an improvement but I think that
the screen refresh is the main delay.

regards
Bruce

Fred Hiltz

2007-09-25, 6:16 am

Bruce wrote:
> Spandex Rutabaga wrote:
[snip]
[snip][color=darkred]
> I don't think that 640000 cycles is much for a computer. In C,
> the same effect can be achieved in under 1 second. After all,
> 800x800 is not a big drawing and how else do you process
> images if not pixel by pixel?

The reason is that the interpreted command in your PSP script is a
brush stroke, carrying all the power of the options you see in its
Tool Options palette and its Brush Variance palette, even though
your end result is to set four bytes in the image.

Sure, C can fill an array in a few milliseconds. Use C when you want
simple things done fast. Use PSP when you want powerful graphics. Be
happy that you can make PSP do the job of C at all. Think how long
it would take you to code the PSP Brush tool in C.
--
Fred Hiltz, fhiltz at yahoo dot com

Spandex Rutabaga

2007-09-25, 6:18 pm

Bruce wrote:

> Hi Spandex
>
> I don't think that 640000 cycles is much for a computer.

It's not 640,000 cycles. It is 640,000 individual scripting
commands (including parameters) each of which passes separately
through the Python interpreter before it can become executable
code and do something.

> In C, the same
> effect can be achieved in under 1 second.

Not quite. You actually mean "using a compiled executable
originally written in C which does nothing but set four bytes
per pixel in an array and write the filled array to a file".

> After all, 800x800 is not a
> big drawing and how else do you process images if not pixel by pixel?

Well, my friend, I would just set the color of a pixel. However,
you chose to use a script in which you invoked the brush tool,
set the tool's parameters, chose a material to use with the brush,
defined a brush path and painted a stroke according to the path
and brush settings. You did this 640,000 times. Now you complain
that dragging all that baggage around is slow.

> It is a good idea to consider processing the graphic outside of the
> screen refresh but this exposes a significant flaw in Python. No
> build-in canvas!

I don't know what it means but you don't need it. You have an
image editor that will create images. After that you just need
to get around the fact that setting pixel colors using repeated
pixel-by-pixel applications of a brush command is slow.

> No wonder the language has not progressed commercially.

If it were commercial you would be paying for it. You get it for
free along with the work of other people who have created all
sorts of scripts to work using this language. Perhaps you'd
prefer to pay but I like it the way it is. Opinions differ.

> Which is a pity since the syntax is really elegant.
>
> I tried to install the 3rd party PIL library but can't get PSP to find
> it. Seems that PSP only looks in its own Python folder. I suspect that
> there may also be a version conflict since PSP is tied to a specific
> Python library.
>
> But then I thought, I don't want to process outside of PSP. The
> intention is to make use of the scripting and graphic features of PSP.
>
> Switching off the undo system does make an improvement but I think that
> the screen refresh is the main delay.

Using multiple interpreted commands, each of which is potentially
followed by a screen update, is where you are shooting yourself
in the foot.

John Andrisan

2007-09-25, 6:18 pm

>> I don't think that 640000 cycles is much for a computer.

Change that to running time in minutes at your PC's cpu speed and you might
change your mind.
john

Bruce

2007-09-27, 3:17 am

Spandex Rutabaga wrote:
> Well, my friend, I would just set the color of a pixel.

You are right, this is what I should do. How do you do set the color of
a pixel in PSP9.

Bruce

Fred Hiltz

2007-09-27, 3:17 am

Bruce wrote:
> Spandex Rutabaga wrote:
>
> You are right, this is what I should do. How do you do set the
> color of a pixel in PSP9.

Please go back and read again Spandex's first reply to your OP, in
which she suggests a much faster way to set the colors of the pixels
in an image. Look for "You may find it quicker..."
--
Fred Hiltz, fhiltz at yahoo dot com

Bruce

2007-09-27, 3:17 am

Fred Hiltz wrote:
> Please go back and read again Spandex's first reply to your OP, in
> which she suggests a much faster way to set the colors of the pixels
> in an image. Look for "You may find it quicker..."

Thanks, I have been experimenting with that but I am more interested in
knowing if it is possible to change the color of a single pixel (without
carrying around all of the paint baggage).
Bruce

Fred Hiltz

2007-09-27, 6:20 pm

Bruce wrote:
> Fred Hiltz wrote:
>
> Thanks, I have been experimenting with that but I am more
> interested in knowing if it is possible to change the color of
> a single pixel (without carrying around all of the paint
> baggage).

I do not know any more than the three ways we have already pointed
out to you:

1. Use the Paint Brush. Easy and slow.

2. Write a text file in one of the open image formats. A little
harder but faster.

3. Get a tool designed for the job at hand, i.e., C++ and a graphics
library. Very long to implement, very quick to run.

In short, yes, it is possible.
--
Fred Hiltz, fhiltz at yahoo dot com

Bruce

2007-09-27, 6:20 pm

But I have already tried the 3 obvious methods.

Spandex wrote:
Well, my friend, I would just set the color of a pixel. However,
you chose to use a script in which you invoked the brush tool,
set the tool's parameters, chose a material to use with the brush,
defined a brush path and painted a stroke according to the path
and brush settings.

I'm more interested to know if I can "set the color of a pixel" directly
from the script. In the comment above, Spandex suggested that it was
possible. But, I have searched the command list and don't find any that
allow pixel colors to be set. Who knows, the documentation of these
commands is not that great so it may be hidden there somewhere.

One of the graphics I'm experimenting with is an engineering fan curve
that is very messy. I want to mark a point on the curve and let the
script follow my selected line, changing the pixel colors as it goes.

I'm also interested in exploring bacterial colony growth, fractals and
the amazing Cellular Automata described by Stephen Wolfram, all of which
could be achieved by setting pixel colors.

Bruce

Spandex Rutabaga

2007-09-27, 6:20 pm

Bruce wrote:
>
> Spandex Rutabaga wrote:
>
> You are right, this is what I should do. How do you do set the color of
> a pixel in PSP9.

We don't seem to be communicating properly.

The way you set the color of a pixel *inside PSP 9* is to paint
the pixel or fill a selected pixel. However, you do it you have
to use a tool (or at least a PSP command) to change the pixel.
The program is based on this. There is no other way to do it.

The way to set the color of a pixel rapidly is to find a way to
simply set it directly, without executing a separate PSP command
for every pixel. I suggested saving a file, opening the file with
home-brew software, changing the pixel values, saving the file and
re-reading into PSP. The pixel setting is done *outside PSP 9*
but the whole process, including running the pixel setting
program, can be run from *inside PSP 9* under the control of a
script.