|
|
Image colour average Hi, This is my first post here and i need some help. What I am trying to do is get an image from the video input get a colour average from it and put that colour into the Sprite. Sounds really simple, but i can not figure out how to do that. If i use Area Average it gives me an image output which i can not plug into a colour input. Please help me with this one. Thanks
|
This one is easily done, that's why I'm answering it •~
See attached, usual FDL coverage, educational use and learn from it, etc. :-)
Download and run, uses HSLA not RGBA , even though the values are extracted using the Image Pixels stock patch that gives RGBA and please note the note within, Alpha value taken from ImagePixels patch to the HSLA patch.
Put maths in betwixt component values for more than default average result.
Put image filters betwixt video input for more colourful weirdness, etc.
You can also tweak the Color Space to one you really like.
Just noticed the video input is working - yippee.
Enjoy.
I'm off to make something nourishing to consume.
i think 'image pixel' plugins might help... can't test it right now though..
Proof of the pudding's in the 'eating' [running of the file] :-)
I'm looking at the math, and you're taking the rgba, dividing by four, then feeding the same result to the hue, the luminosity, and the saturation. I may be wrong, but I don't think that yields the average value. Also, Image pixels gives the pixel value one pixel at a time, as determined by the pixel x/y inputs. This qtz is reading the very edge of the raster, if I'm not mistaken.
So, the path is going to looks something like this:
Image->area average OR image resize OR lanczos scale, set to give a 1x1 image->ImagePixel, each output of ImagePixel to RGB Color -> Sprite Color Port.
thank you so much for this. one of the examples works perfect for me.
No you are right, GT.
Should have just stuck with the Area Average to begin with.
I was wondering about that, the math, to obtain the colour value, do I calculate on the basis of RGBA [thus divide by 4] or do I only take the RGB [and thus divide by three]?
In fact looking at the quick and dirty fix I did, the Image Pixel patch's area inputs were being set as one would the extent on the Area Average, which is quite wrong.
Looking at your solution, it does indeed work correctly.
The thing to learn from that earlier post of mine is don't do it that way :-)
Here's how I'm looking at it:
Color is a 3 or 4 lane data, depending on if it's represented as RGB or RGBA. It's not a single value / float. When you reduce it to that, you wind up with a kind of brightness value. If you want to represent the average color as HSL accurately, I think you need something that would actually detect the hue, saturation, and luminosity values of that one averaged pixel, and deliver them, or get the RGB values and convert them to HSL. In this setup, I think it would just result in an extra conversion that doesn't need to happen, because Image Pixel delivers RGBA values already.
My only other thought on that, is that, I think, if you want to figure out the average brightness of RGBA (not the original question, but kind of touched on in your post/what your composition was doing), that you add the R, G, and B lanes, divide by 3, and then multiply by the alpha value. If you want to figure out the luminosity of RGB, I believe you just add them and divide by 3.
I don't think the conversion to what is considered "luminosity" is quite so straightforward though; I believe this is the common function for converting to luminosity (which I think luma is the same as?):
float lum = dot(px, vec4(0.299,0.587,0.114,0.0));
Where px is the value of the current pixel.
For more info than you ever want to know about luma (Y is luma in these explanations):
http://softpixel.com/~cwright/programming/colorspace/yuv/
http://www.fourcc.org/fccyvrgb.php
So, little side tangent to the main question there.
Oh, one other thought; doing a standard CL Image Kernel that reads the pixel after it's reduced/averaged to 1x1 will also yield the necessary float4 output data, and be GPU accelerated, at least in theory/if supported by the driver.
It also seems like there are some CL histogram examples out there that might be worth looking at (or not!). Someone could also always take the stock histogram op, or do a cl histogram op, and do maths on all of the output pixels and come up with their own average. I guess that's another approach that hasn't been mentioned.