Tue Aug 27 04:49:46 EDT 2019
<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.
<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
<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.
<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.
Thanks a lot Dar. There's a lot of useful stuff there. But I haven't got to
the bitmap's rows and columns yet. I've just tried to replace the first 400
pixels (first row) of a 657 pixels wide photo, with no calculations on the
pixels at all.
The following little routine is designed simply to replace the first 400
pixels of a photo.
Since I have almost no experience in Transcript, please excuse anything
stupid I may have done.
"bmw.bmp" is a Windows bitmap of 657x319 pixels.
It occupies 614K
put empty into iData
put binaryEncode("CCCC",0,0,255,0) into redPixel
put the imageData of image "bmw.bmp" into iData
delete char 1 to 1600 of iData
repeat with i = 1 to 400
put redPixel before iData
set the imageData of image "bmw.bmp" to iData
On my (admittedly humble Pentium II 450hz 128M memory) PC, the above little
routine takes almost 8 seconds to execute!
So what stupid things have I done to make such a modest little routine take
8 whole seconds to execute? I am sure that improvements can be made in the
coding to make it faster (e.g. the repeat bit), but 8 seconds is almost like
a century in computer time!
Any comments on the above routine?
More information about the use-livecode