"Blurred vision" of Rev newsletter, Apr 21
Hanson
hanson at runrev.com
Wed May 11 06:33:36 EDT 2011
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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
More information about the use-livecode
mailing list