PDA

View Full Version : luminance to colors?


LEVLHED
29th May 2002, 04:31 PM
I was just wondering if there was a plugin for (any) video editing software that will take a grey-scale image and convert the different "luminances" to colors?

many2
29th May 2002, 05:19 PM
That would be quite easy in visualJockey, if you want to use it I would be glad to explain you how or send you some example FXCs. You could even export the result as an AVI for use in another software.

I see two basic algorythms to achieve your goal :
a. You could apply a new palette to the image
b. You could apply a distortion based on your grayscale image and referring to a color gradient in another image.

Both of these solutions are really easy to implement in vJo R3 but they should be applicable in a lot of software.

Many-2

LEVLHED
29th May 2002, 05:34 PM
OK, thats a start.
I don't have vJo3, but could you explain how thats done in vJoR3 here for the benefit of anyone else who might have it?

I could do a search, but I'm too lazy right now. Anyone know of a premiere/AE/vegasvideo/etc plug?

many2
29th May 2002, 06:32 PM
In after effect you could use the " image control - colorama " basic filter. Try it and you should easily understand how it's working.

In vJo R3 :

a. Using palettes
to apply a palette to a grayscale source :
create a ressource node for your basic grayscale source (Avi loader, live video, picture manager, whatever)
Put a Color effect node under it
Set the color filter mode to palette and choose default or load your own (if you load 2 palettes you'll be able to mix between them)
Right-click on the color node and select "variables...". This will open a panel to adjust the palette rotation speed and the mixing, among other things. Set the pallette rotation speed to 0 to make it stable. You could also connect it to the beat, or a MIDI sldier, or the mouse ;)

b. Using distortion
create a ressource node for your basic grayscale source
create a distortion (2d effect - distortion) node under the ressource node.
Switch your grayscale ressource node to the second (right) input slot, the one titled "distortion"
Add a texture generator in the first slot. Set it to "linear" in the first "generic" tab panel. Go to the colors tab and choose a default set of colors or create your own and apply it. The idea is to create an index color gradient.
As a last touch go into the distortion static parameter window and uncheck the "wrap around texture" option to clamp the values from the borders of the color gradients.

Both of these solutions opens a whole world of real-time color interactions, be it with grayscale or full color ressources.

Many-2

infopocalypse
4th June 2002, 01:06 AM
All right:

Take your base filter of a black and white draw... this takes the image an computes the average of each pixel's red, green, and blue... in other words, the luminance.

Make a function or subloop to be called for each pixel. This function would be a lookup table, containing, for each possible level of luminance (in a 24 bit image there are 256 possible levels of red, green, and blue, and thus 256 possible luminances), the color to return. Making such lookup tables becomes a little trickier, as to do this right you would need to do this in assembly and thus basing it on an external source is far more difficult, but, going on...

Lum = R+G+B/3

lookuptable[lum]

R = lookuptable[lum].r
B = lookuptable[lum].b
G = lookuptable[lum].g

There a A LOT of ways you can optimize this.

Bada bing.. luminance becomes a color.

Note: the theoretical algorithm above is copyright 2002 by James Brundage. (that means no going putting theoretical filter in that method in another program... you do we talk lawyers).

infopocalypse
4th June 2002, 01:07 AM
There's something for Avid that does what you're talking about, somewhat (it also uses motion). It's called IllusionFX's FluidColorMap. Don't know if they make a Premiere/Vegas plugin for the same.

robotfunk
4th June 2002, 07:50 AM
Lum = R+G+B/3

lookuptable[lum]

R = lookuptable[lum].r
B = lookuptable[lum].b
G = lookuptable[lum].g


Note: the theoretical algorithm above is copyright 2002 by James Brundage. (that means no going putting theoretical filter in that method in another program... you do we talk lawyers).

:rolleyes:
you must be kidding, really... not only is 'your' algo mathemetically lazy ( taking no account of difference in sensitivity of the human eye for red, green and blue )
you claim to have some kind of patent on a simple averaging of 3 numbers. I'm sorry to say I have been using this (fast,but slightly incorrect) algorithm for years so bring on your lawyers so I can feed the felines LOL

also your notation lacks parentheses around "r+g+b"

infopocalypse
4th June 2002, 08:25 AM
Well I could post our solution to such a filter as written in MMX assembly complete with a lot of legal mumbo jumbo, including our color structue, but it really wasn't pertinant, nor would I want such an implementation out there... the reason that I excluded the paranthesis is that, as far as the solution goes, such are not neccessary (think through possible optimizations and then get back to me).

If you wish to converse more on programming as a general topic, email me personally.

robotfunk
4th June 2002, 08:55 AM
well i was just commenting that even pseudo code should be written mathemetically correct ..

if i take Lum = R+G+B/3 literally you only divide the blue by 3 instead of averaging the 3 colors

a rgb of (200,200,100) would work out to 433.3333
instead of 166.6667
yes im being a bit of a nerd here.

also regarding the legalese yes I know a lot of ridiculous patents have been granted (projecting an image on sphere by ipix , playing 5 mp3's at once by dolby ) but claiming copyright on an average between 3 numbers is just silly, even if you combine it with a lookup table, in flowmotion 4 effects (dots, dots color, line pattern and ascii) work on this principle and I would be very surprised if this would infringe any copyright or patent.

infopocalypse
4th June 2002, 10:17 AM
For that much I am sorry... my head is in MMX land as that's how all of our draws are written, and thus it's both easier and harder to do the above. And don't worry 'bout the nerd thing... I'm one too.

I'll have to give your soft a gander before mine goes into v2 (we may be able to work something out). My opinion of most VJ soft extant @ this point though is that it is inefficent tripe written in silly methods using bad wrapper classes in many case and taking too many shortcuts to be efficient... and, as you're dealing in realtime, you cannot afford to waste a single clock cycle.

email me privately and we'll talk more.

jbrundage@runbox.com

MoRpH
5th June 2002, 03:53 AM
Ahhhh allswell that ends well....... nice boys :)