Dear Prof. Sanke,
thank you very much for your great contributions to image processing
with LiveCode and for sharing your work with us. Your e-mail, reviewing
some of the history of image processing with LiveCode is fascinating and
your stacks are extremely interesting. I can only recommend anyone
exploring image processing to have a look at the stacks and test their
capabilities.
Mit Freundlichen Gruessen,
Hanson Schmidt-Cornelius
LiveCode Team
On 26/04/2011 21:37, Wilhelm Sanke wrote:
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
_______________________________________________
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