Language comparisons: "Lua" - simpler and faster than RevTalk?

François Chaplais francois.chaplais at mines-paristech.fr
Wed Mar 10 16:41:43 EST 2010


Le 10 mars 2010 à 11:04, viktoras d. a écrit :

> the sad fact is that many languages out there have a simpler mechanism (implemented via libraries) to access and manipulate image pixels. RevTalk does not have such a library and manipulation of image pixels is therefore unfortunately very slow and awkward :-(
> 
> A year ago I put a suggestion for an enhancement in the QC for "more efficient pixel access in images" #7636.
> However its status is still unconfirmed. Maybe I have to change severity from enhancement to critical to make this report more noticeable :-)
> 
> Viktoras
> 
I have looked at your report, and honestly, it should be backed up by a request for typed data.
In the case of images, this means arrays of 8 bit unsigned integers (assuming you have access to each RGB/alpha channel), with appropriate operators (as far as I am concerned, convolution would be fine).
A related report at qacenter has number 2783.

cheers,

François

P.S.: i have several conversations with a student at my "grande école" who  wished to do some online video correction to ease the effort on the human view system, and she was screaming for integer computations, because double float computations were way too slow. And transcript's untyped variables are probably even worse.
So, IMHO, if you're in for image processing, integer typed arrays are a definitive bonus.




More information about the use-livecode mailing list