First there is a minor confusion about numbers: The subject of the post
I received reads "[109] Summer Academy; Flying to San Jose", when I open
it I see "revUp issue 108". Be that as it may, what I want to comment on
is the article "Vision: Blur" by Hanson Schmidt-Cornelius in that
newsletter.
Hanson presents a series of scripts that are related to each other to
achieve a "blur filter" effect using sort of a 3x3-convolve matrix. I
want to add some information and discuss the issue in a somewhat broader
context. As Hanson did not himself supply a sample stack, I produced one
that contains his scripts along with a number of alternative "blur"
scripts and apart from that added some other filters which might be
interesting for Livecode users that intend to look at image processing.
You can get the stack here:
<http://www.sanke.org/Software/BlurredVision.zip>.
I also recommend - for those who like to experiment with image
processing - my older stacks
-<http://www.sanke.org/Software/ImagedataToolkitPreview3.zip>
and
- <http://www.sanke.org/Software/SeamlessTiles2.zip>
Last, but not least, you should download Chipp Walters' stack of 2002
"altConvolve2.rev" from here
<http://www.altuit.com/webs/altuit2/RunRev/Downloads.htm>
to get the historical perspective.
Chipp Walters has indeed been the first Metacard/Revolution user to
develop a scripted version of a 3x3 matrix filter in his sample stack
"altConvolve2.rev" of 2002
His aim was to demonstrate that imagedata could be managed
effectively even without the help of an external. Chipp had bundled his
stack with an external by Scott Raney to let you compare whether the
3x3-convolve matrices, with and without an external, produce the same
results. Unfortunately, from Metacard version 2.4.2 on the sequence of
the 4 imagedata chars of an image pixel had been altered, and Scott's
older external now produced images with a strong yellow tint. Apart from
that disadvantage, using the external was about 500 times faster than
Chipp's no-external script.
I have later used Derek Bump's "convolve.dll" external that is tuned to
the newer color sequence, but - like Scott's external - is available
only for Windows. Derek's external is included in my distribution of my
"Imagedata Toolkit (see URL above). Lately I had the opportunity to test
prototypes of Lua-externals (Mac and Windows) for Revolution/Livecode.
Performance - speed - of all these externals are at least 60 times
faster than any even speed-optimized scripted-only filter versions, on
the average these externals are about 100 times faster.
For Chipp, "Speed" of execution was not a consideration for him at
that time - and not necessary, as he used very small
images in his sample stack. He mainly wanted to show that matrix
filters could be natively scripted in Metacard/Revolution
To be able to use the convolve matrix with larger images, I made a
number of changes to Chipp's original script,
abandoning among other things the use of arrays in this context or the
"round" function which speeded up
the performance of the filter by a factor of 10.8, only 3328
milliseconds instead of formerly 36008 ms for an image
sized 640x480 (WindowsXP, 2.8 GHz machine, using the Metacard IDE.
Performance with the Rev/Livecode IDE
is about another 5 seconds slower)
Another improvement was introduced by Mark Waddingham, who recommended
taking the assignment of matrix
values away from inside the repeat loop ("put 0 + item 1 of convArray
into tA1" etc.) - an overlooked, but really obvious
way to do this - which speeded up performance by another 30% and
brought down the total execution speed to
2308 milliseconds - measured with the same image and filter values
(performance here will differ slightly with the specific
structure of an image and with different filter matrix values).
In my "Imagedata Toolkit" stack you find such optimized
natively-scripted matrix filters, as also in "Seamless Tiles", along
with about matrix 100 filter examples of very different kinds, i.e. not
only blur filters.
In my new sample stack "Blurred Vision" I have now put together 7
different "blur" filters for comparison.
You find Hanson's blur script (presented in the newsletter of April 21)
in button "Rev-blur" and the stack script. Speed of his blur filter is
32 seconds in the Rev IDE and 28 in the MC IDE; when compiled as a Rev
standalone performance is like in the Metacard IDE (configurations as
described above).
The optimized Walters/Sanke/Waddingham version of the scripted
3x3-matrix filter in contained in button "matrix blur 3x3". Execution
speed is presently 2281 milliseconds, based on a test I just made.
This raises the question why Hanson's scripts are so much slower - 12
times - than "matrix blur 3x3"? I did not yet find time for a detailed
analysis, but I believe that - even given the special structue of the
related scripts - the performance could certainly be improved. One
recommendation would be *not* to use arrays , which against popular
belief really "slows down" performance in this context of image processing.
The next blur button "matrix blur 5x5" is based on a matrix of 25
pixels, and the speed is still a tolerable 5900 milliseconds for 640x480
images.
The basix structure of "Lua-blur" is also a that of a matrix filter. The
original Lua script is contained in the script for the sake of
comparison. A radius of 1 corresponds to a 3x3 matrix, 2 to a 5x5
matrix, 3 to a 7x7 matrix etc. Speed of this button with a radius of 1
as equivalent to a 3x3 matrix is about 5 seconds, for greater radii
performance slows down considerably. This is of course not the case if
you would run the original Lua script in a Lua environment or with an
external.
Buttons "Simple blur" and "simple blur compact" - 2568 and 1889
milliseconds - do not use a 9-pixel matrix, but compute the respective
blur values on the basis of only two adjacent pixels.
"Progressive blur" uses a different aproach by comparing not 2 adjacent
pixels, but 2 pixels that are more distant, up to 50 pixels, which
results still in "blurred" images, but with a different "shadowy" character.
Speed of this algorithm is 2500 milliseconds independent of the distance
of the processed pixels.
The last blur example - "fast blur" - employs an algorithm I originally
used to add hues of any color to images, and then slightly modified.
Execution time is a rather stable 2 seconds for any of the blur values
(from 1 to 45) you can choose, and the result of the blur is one of the
best.--
You may notice that the images when modified by matrix filters may show
"borders". In my "Imagedata Toolkit" I have applied special "remove
borders" scripts that take account of this feature, but not in the
"Blurred vision" stack.
I have added 30 more filters to the "blurred vision" stack demonstrating
the use of filters other than for blur purposes.
If you want to apply "lithography" and "emboss/contours" filters, make
sure you first apply one or more of the "despeckle/median" filters for
better results.
I am sure you will like the "random gradients" and "seamless mirrors"
filters, which introduce new dimensions for image processing.
I attach the text of this mail as an introductory text the sample stack
"Blurred Vision".ision
Kind regards,
Wilhelm Sanke
Prof. emeritus
Educational Technology
University of Kassel, Germany
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
