Any suggestions on how to "onion skinning"?

Mark Smith mark at maseurope.net
Thu Nov 29 09:25:11 EST 2007


Well, one alternative that also seems to work is to map the 24bit  
value of each pixel to an 8bit value :

function makeGS @inData
    repeat with n = 1 to length(inData) - 3 step 4
       get binarydecode("M", char n to n+3 of inData, tPix)
       put numtochar(tPix div 65536) into tv
       put null & tv & tv & tv after outData
    end repeat
    return outData
end makeGS

It's maybe 25% quicker than dealing with each color component  
individually.

Best,

Mark

On 29 Nov 2007, at 09:48, Wilhelm Sanke wrote:

> Mark Smith mark at maseurope.net wrote:
>
>> This is sort of interesting:
>>
>> if you simply take one of the color bytes of each pixel, and copy  
>> it  to the other two color bytes, you get a gray-scale result.  
>> The  brightness/contrast varies with which color you choose. For  
>> the few  images I've tried, it seems to be red =brighter/less  
>> contrast  to  blue= darker/more contrast. This may be no surprise  
>> to the pro image  wranglers among us, but seemed intriguing to me.
>
>
> And Chipp Walters chipp at chipp.com wrote:
>
>> Mark,
>>
>> Unless you average the 3, your gray-scale result may not work
>> properly. Try it on an image with 3 circles: 100%R, 100%G, 100%B and
>> you'll see what I mean.
>
>
>
> My experience is that with most photos you get a very nice  
> grayscale image using the red pixel and copying the value to the  
> other two pixels like Mark suggested.
>
> The last public version of my "Imagedata Toolkit Preview 3" (update  
> of April 17)
>
> <http://www.sanke.org/Software/ImageDataToolkitPreview3.zip>
>
> contains both grayscale routines using "average" and those with  
> copying one color pixel to the other two - implemented for all  
> three colors.
>
> Speed for "average gray" and a 640X480 image (on a 2 GHz machine)  
> is about 1.1 seconds and for "gray from red" about 600 milliseconds.-
>
> The next update of the Imagedata Toolkit, which will be the last  
> with a restriction to an enforced image size of  640X480, will  
> probably be released before Xmas and contain a number of major  
> enhancements (among them: scripted Rev emulation of cubic  
> enlargement, integration and expanding of some new Gluas filters  
> from Gimp - translated into Revolution - "stretch contrast",  
> "compress contrast", enhancement of "jitter" filters with various  
> multi-pixel jitters, another despeckle filter based on minimum  
> differences between surrounding pixel pairs [this is another Gimp/ 
> Gluas development that is identical in effectiveness to the  
> "median" approach, but somewhat slower], exchanging color values  
> within a defined range by clicking on image and/or color scale,  
> copying - and enlarging or shrinking - and pasting oval or  
> rectangular portions of an image into the same or another image  
> with variable fringe and/or overall blending into the basic image).
>
> Best regards,
>
> Wilhelm Sanke
> <http://www.sanke.org/MetaMedia>
>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution




More information about the use-livecode mailing list