I'm working on a program with my son that does simple card-based
animation, but one of the things he asked how to do in Rev stumped me,
and that is doing an "onion skin" - showing a "grayed out" version of
the previous card's objects on the current card.
I know how to do *some* of it (I can ta
Recently, Ken Ray wrote:
> I'm working on a program with my son that does simple card-based
> animation, but one of the things he asked how to do in Rev stumped me,
> and that is doing an "onion skin"
I would try overlaying a translucent screen capture of the prev or next
card.
Regards,
Scott R
On 28 Nov 2007, at 19:44, Scott Rossi wrote:
Recently, Ken Ray wrote:
I'm working on a program with my son that does simple card-based
animation, but one of the things he asked how to do in Rev stumped
me,
and that is doing an "onion skin"
I would try overlaying a translucent screen capt
On Wed, 28 Nov 2007 20:19:27 +, Ian Wood wrote:
>>> I'm working on a program with my son that does simple card-based
>>> animation, but one of the things he asked how to do in Rev stumped me,
>>> and that is doing an "onion skin"
>>
>> I would try overlaying a translucent screen capture of th
Hi Ken,
You could use Wilhelm Sanke's image tools to remove the color from the
screencaptured image. I think that would actually be pretty fast.
Or, you could probably do it really fast with an optimized imagedata
script where you average the values of each pixel and reapply. I would
think that w
change the blending of the snapshot to see if that gets you the contrast or
color reversal or transparency...
Jim Ault
Las Vegas
On 11/28/07 12:41 PM, "Ken Ray" <[EMAIL PROTECTED]> wrote:
> On Wed, 28 Nov 2007 20:19:27 +, Ian Wood wrote:
>
I'm working on a program with my son that doe
Ken,
Have you tried snapshoting the card, then somewhere off screen you put
a gray image on top of the snapshot with some blend and take another
shot. Depending on ink combinations you might have a nice result.
Another way, which I don't know how fast it is, is to read each pixel
in the snapshot
On 28 Nov 2007, at 21:24, Chipp Walters wrote:
Or, you could probably do it really fast with an optimized imagedata
script where you average the values of each pixel and reapply. I would
think that would zip right along.
I managed to find a function from March last year from a discussion
ab
On Wed, 28 Nov 2007 20:50:11 -0200, Andre Garzia wrote:
> Ken,
>
> Have you tried snapshoting the card, then somewhere off screen you put
> a gray image on top of the snapshot with some blend and take another
> shot. Depending on ink combinations you might have a nice result.
Good idea - I'll co
> to turn the specified image into greyscale. Takes about a second for
> a 640x480px image on a MBP 2GHz Core Duo, so not too speedy.
Thanks, Ian! I'll give that a try...
Ken Ray
Sons of Thunder Software, Inc.
Email: [EMAIL PROTECTED]
Web Site: http://www.sonsothunder.com/
_
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
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.
On Nov 28, 2007 9:32 PM, Mark Smith <[EMAIL PROTECTED]> wrote:
> This is sort of interesting:
>
> if you simply take one of the color by
That makes sense. Duh! I only tried it on some photos...ah well, no
free lunch again :)
Best,
Mark
On 29 Nov 2007, at 03:59, Chipp Walters 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
You're extracting one of the three RGB channels.
Ian
On 29 Nov 2007, at 03:32, Mark Smith 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
Hiya,
Some time ago we used to add the RGB values together and then divide
by 3. This was wy back, and the results were ok then.
I spotted this on the net:
R*.3+G*.59+B*.11 to get the grey value, haven't tried it.
Cheers,
Luis.
On 29 Nov 2007, at 00:39, Ken Ray wrote:
On Wed, 28 No
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, i
From Wikipedia: http://en.wikipedia.org/wiki/Greyscale
'Converting color to grayscale
To convert any color to its most approximate level of gray, first one
must obtain the values of its red, green and blue (RGB) primaries.
Then, add 30% of the red value, 59% of the green value, and 11% of
Oh dear. Wikipedia strikes again. :-(
Those percentages are for very specific purposes and are NOT what is
generally used in conversion to greyscale. The article isn't really
*wrong*, but it doesn't bear much resemblance to most real-life usage.
Ian
On 29 Nov 2007, at 10:56, Luis wrote:
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 nul
Ken,
if you are on MacOSX system > = 10.4 and you just want the image to be
grayscale then you can try an applescript for colorsyncscripting.
it is a lot faster than Revolution. It takes Revolution from "set the
imagedata of image x to y" for a 640x480 on a MacBook Pro 2.3 about 280
Milliseconds
On Mon Dec 3, 2007 BNig niggemann at uni-wh.de wrote:
Ken,
if you are on MacOSX system > = 10.4 and you just want the image to be
grayscale then you can try an applescript for colorsyncscripting.
it is a lot faster than Revolution. It takes Revolution from "set the
imagedata of image x to y" f
the timing on a MacBook Pro 2.33 GHz for the scripts is
on average 190 Milliseconds for the whole thing, i.e. passing the original
file to Colorsyncscripting, creating the grayscale file on disk and reading
the file into Revolution and display the image.
if you change the applescript so that yo
I must rather shamefacedly admit that my seemingly clever
'binaryDecode' method is actually just extracting the red channel --
so not very clever :(
Best,
Mark
On 3 Dec 2007, at 21:41, BNig wrote:
the timing on a MacBook Pro 2.33 GHz for the scripts is
on average 190 Milliseconds for th
23 matches
Mail list logo
