Setting Pixels - Answers to Suggestions

Dar Scott dsc at swcp.com
Wed Jan 29 15:30:22 EST 2003


On Wednesday, January 29, 2003, at 11:39 AM, Robert J Warren 
((Howsoft.com)) wrote:

> According to the method outlined by Ken Ray in his article, I tried a 
> test
> replacement of a mere 400 pixels, and this took various seconds! Part 
> of the
> trouble is that Transcript does not appear to have instructions for 
> simply
> reading or replacing individual pixels, which might alleviate the 
> problem to
> some degree. However, ironically, as I have found out in VB, this is 
> not the
> best solution. For maximum speed you have to process the image's pixel 
> data
> directly. Putting even part of the pixel data into a variable or array 
> for
> processing slows the whole thing down too much, and don't forget that 
> quite
> complex mathematical calculations have to be performed on each pixel, 
> which
> if done correctly can also take up considerable time.

I need to read Ken Ray's article.  I suspect his examples are designed 
for clarity rather than efficiency.

Char chunking for getting data is fast.  Char chunking for replacing 
data can be slow.  Specifically, ...

Assume operations are on a copy of the image.  Char chunking for 
getting pixel data is fast.  However, char chunking for replacing pixel 
data goes up with the size of the image.  (It might be nice if 
replacement noticed the size was the same and did the replacement in 
place, but alas, that doesn't seem to be the case.)  It is thus better 
to replace the entire pixel rather than each individual pixel component 
in an image of nontrivial size.  And, as mentioned in #3 below, it is 
better to replace sub-rows than pixels.

Here are a couple things to try.

1
There may be places in which it is better to refer to the image data 
(or sub-image) by reference and refer to parts of it by that and char 
positions.

2
There may be ways you can avoid repeating row-column calculations.  Use 
a function to create a char pointer from row and column and use that as 
you need.  For example, you don't need to calculate the position for 
both the read and the write.

3
After you are happy with your method, change the atomic operation from 
pixel orientation to sub-row orientation.  This handler should work on 
a sequence of pixels (as specified by char positions) and need not know 
anything about the size of the image.  That is, you don't have to do a 
row-column calculation for each pixel and replacement is directly by 
char pointer.  If you need a few pixel oriented operators but don't use 
them often, build them out of the sub-row operators.  Remember, build 
up your new sub-row, then replace it in one operation.  If you prefer a 
functional style, you can use a string function to operate on a an 
sequence of pixels and return a string of pixels and then put things 
together at the higher level.  With that optimization, the char 
chunking replacement will be less of a hit; you will be doing only one 
replacement per row under your wand.  It the image can be lots taller 
than the wand, you may want to select out the applicable rows, make the 
transformation, then then put it all back together.

Dar Scott




More information about the use-livecode mailing list