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