"Blurred vision" of Rev newsletter, Apr 21

Tue Apr 26 16:37:54 EDT 2011

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