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

_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to