Setting Pixels - More answers to suggestions

Chipp Walters chipp at chipp.com
Thu Jan 30 00:27:01 EST 2003


Bob,

Monte beat me to the punch. If you're new to RR, you must check out repeat
for each and repeat for structures...MUCH faster than repeat with.

Perhaps you can describe *exactly* the effect you are after and we may be
able to point you in a direction. For instance, you can of course select the
eraser tool and edit an image in real time. If you were to place a 'second'
image on top of the image you're trying to edit, you could paint in real
time, then use the alphadata of the 2nd image as a mask and apply it to the
first image (with your HSL conversion) when finished.

-Chipp

> -----Original Message-----
> From: use-revolution-admin at lists.runrev.com
> [mailto:use-revolution-admin at lists.runrev.com]On Behalf Of Robert J
> Warren (Howsoft.com)
> Sent: Wednesday, January 29, 2003 10:10 PM
> To: use-revolution at lists.runrev.com
> Subject: Setting Pixels - More answers to suggestions
>
>
> <I've thought some about this problem. If you can't use the direct editing
> <mode (choose pencil, eraser, etc..), then it will probably be too slow.
>
> <Perhaps a DLL or XCMD would do the trick...
>
> <-Chipp
>
> Thanks, and sorry Chipp, I am not only new to Transcript but I also know
> nothing at all about Macs. I presume that an XCMD is the Mac version of a
> Windows DLL (?) I am sure that it would help, but I am not sure to what
> degree. I have only ever written one DLL in my life which is for the said
> eraser program in VB (due to be launched soon). It converts RGB to HSL and
> v.v. By doing the calculations in a DLL rather than in the program the
> saving was about 15%. Although this 15% was crucial in the eraser
> routine I
> wrote, it was generally a disappointment: I expected a much bigger saving.
>
> But perhaps more important is the fact that I would have a
> program which was
> not truly cross-platform. Apart from the simple elegance of the Transcript
> language, the cross-platform aspect is my main attraction. Rather than
> regard it as a fixed entity, I would frankly prefer to see the Transcript
> language corrected, improved and adequately extended. But I don't suppose
> the RunRev team would be listening at the moment as it seems they are
> occupied by some other minor task.....
>
> From Dar Scott:
>
> <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.
>
> 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?
>
>
>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution




More information about the use-livecode mailing list