No subject

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

on mouseUp
  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
  end repeat
  set the imageData of image "bmw.bmp" to iData
  play beep
end mouseUp

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 mailing list