Starting at square one with image processing
jhurley0305 at sbcglobal.net
Tue Jul 10 13:38:23 CDT 2007
(Damn, I forgot to include the subject in my post, so here it is
Wilhelm Sanke wrote:
> 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"
> 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
> 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
> 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
> 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
> 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
> 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
Sorry to take so long in acknowledging your post. I subscribe only to
the digest edition of this list and, more importantly, it takes me
time to absorb all you have to say. I particularly appreciate the
user friendly format of your presentation stacks.
I was totally unaware of the compression options. Maybe
paintCompression could be included in the "See also" collection that
goes with the imageData entry in the dictionary.
It is certainly clear from your very helpful "HurleyPencil" stack
that it pays to paint with a broad brush. This also showed up in my
The virtue of the brush, as opposed to the pencil, is that, as it
stutters along, it will fill in those areas that might be skipped
due to the slow processing speed in refreshing the imageData. The
pencil also stutters along, but having writ, moves on, with no
opportunity to back fill with the next stutter step.
I certainly agree with you that it would be a big help if Run Rev
would allow us to change individual pixels rather than the whole
image all at once.
More information about the use-livecode