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

Reply via email to