Starting at square one with image processing

[Wilhelm Sanke]

On Sun Jul 8, James Hurley jhurley0305 at sbcglobal.net wrote:

> Second: It is also clear, on closer inspection, that Run Rev is not  
> fast enough for user created paint tools such as a pencil or brush.  
> The poor man's pencil I described earlier is hit and miss if the  
> pencil is moved too fast. I presume this is because it takes too long  
> to continually reset the imagedata as the mouse is  moved. Best to  
> stick to button commands it seems.
>
> Jim



Hello Jim,

your inventive script for the pencil tools proves once more that there 
are more than one or two approaches to achieve specific effects in 
x-talk languages. This is what most of us appreciate very much, and it 
surely challenges the creativeness of x-talk programmers.

After the wonderful sunny Sunday - fine weather is rare these days in 
the middle of Europe - I took a second look at the various questions and 
put together a sample and test stack "Hurley's Pencil" 
<http://www.sanke.org/Software/HurleysPencil.zip>.

The stack contains two images that can be reset after applying the 
pencil graphics (and it repeats most of the text of this post) and a 
radio-button group to change the paintcompression.

There are now three different graphics to be dragged around on the images:

The red graphic contains a modified version of your original script,  
changing 4 pixels at once instead of 1 pixel on mousemove and using a 
variable "movedobject" instead of the name of the graphic to start and 
stop dragging.

The yellow graphic contains an alternative script using a somewhat 
different approach based on my own basic format for the handling of 
imagedata. It enables you also to easily change the number of pixels 
involved when dragging the graphic.

In the script of the green graphic
line "set the imagedata of img "mine2" to idata"
has been moved from the "mousemove" handler to the mouseup "handler", 
causing the image to be redrawn only after the moved graphic has been 
released.

There are at least two basic problems for imagedata manipulation:

1. Processing imagedata with RLE paintcompression is up to 12 times 
faster  than with PNG (in extreme cases).

See Bugzilla 5113 and the accompanying test stack
<http://www.sanke.org/Software/TestStackPaintcompression.zip>

Contrary to the Metacard IDE, Revolution sets the paintcompression to 
PNG on startup. If you use Revolution, set the paintcompression to RLE 
to speed up all imagedata processes. You can test the speed differences 
by changing the paintcompression with the radio buttons at the top of 
the sample stack.

2. You can get and set the imagedata only for a whole image via a 
variable. You cannot access and change individual or a range of pixels 
directly like
"put numtochar(100) into char 2500 of the imagedata of image "x"".

This means that although by moving the pencil graphic only a few pixels 
are changed, each time the graphic is moved the entire imagedata is 
being set anew (when using the red and yellow graphics).
This also means that the larger the image the slower the possible 
movement of the pencil graphic will be. I tested this on an image 
2048X1536 where the pencil graphic could be hardly moved even with the 
paintcompression set to RLE.

Hopefully we will get such an enhancement to directly set the color of 
individual pixels in images in the future.

Best regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>