I would like to take an area (50x50px) of a video and calculate its average color (in order to send it to Philips Hue bulbs later on). What’s the most straight forward way to do this?

At the moment I’m trying to catch a frame of the video to an ofPixels object, cut it down, send it to a while-loop to resize the image to 1x1px and then use that color info. Something works, but not as expected (the averaged color doesn’t match the supposed sampled area). I’m also thinking of averaging the color over 5-10 frames to smoothen it out (especially as the video will have color noise in it). Is there an averaging function that could take care of all this?

hey @twobeers83 - incrementally resizing an image down to a single pixel isn’t the same as calculating the average color of a region of an image. What you want to do is get the pixels from the video and loop over them to calculate the average. Below is an ofSketch example that calculates the average color of a 50 x 50 rectangle at the top left of the webcam feed. The averaging region is hardcoded in the example, so of course you would want to make a nicer version that allows you to move/resize that averaging region.

wonderful! I’m still easily confused of the capabilities of ofPixels (and the getPixels or getPixelsRef), ofImage and ofColor and how/when to use/access them, but this makes sense. thanks so much, Mike!

I haven’t been following the 0.9 release stuff very closely, but here’s my understanding. In 0.8.4, getPixels() returns a raw pointer to an array of unsigned chars and getPixelsRef() returns a nice ofPixels object.

When dealing with the raw pointer, you have to do a little math to get/set a particular pixel’s color. That’s because the image is being represented as a 1-dimensional array of color channel values:

The ofPixels object from getPixelsRef() is a nicer way to interact with the pixel color information. The ofPixels object knows about it’s color mode (RGB vs RGBA vs grayscale vs …), so it can abstract away the math that you’d need to do to get a particular pixel. It also nicely wraps up the various color channels into an ofColor object, so you don’t have to access the individual channels like you would with the unsigned char array. (ofPixels has a bunch of helpful methods, but I would say abstracting away that math is one of the key things that it does.)

In 0.9, getPixelsRef() is being deprecated. In the future, getPixels() will return an ofPixels object (and getPixelsRef() will disappear). But for 0.8.4 and your code, getPixelsRef() would be the way to go since it gives you the niceties of ofPixels. (And since ofVideoGrabber gives you access to the current frame’s pixels via getPixelsRef(), you don’t have to create an ofImage, like you started out doing.)

that was super helpful! I’m starting to see through the maze. It’s honestly only a few weeks ago since I realized how there can be arrays of objects (i.e. getPixelsRef contains lots of ofPixels which contain a number of values each). I’m working my way through the “Programming Interactivity” book we started Christopher’s class with two years ago (a bit outdated by now, but it helps). Grad school had to be over before I had time for this. Thanks!

Averaging the color worked out really well. But now I got stuck with averaging the samples over multiple frames. So I need a buffer-array of 9 different samples (9 positions of the screen get sampled), with 5 frames each that themselves have 3 color values. What’s the best way to do that? I tried to sum up the color values in an array of ofVec3f's, but my program crashes when I try to add or extract the values from it.

Is your buffer vector empty when you are trying to do: buffer[i] += color? That would explain why it is crashing at runtime in both of those places - it’s reaching for a memory location that is out of the bounds of the std::vector.

Approach-wise I would probably do something slight different. Right now you are:

Accumulating a buffer of color information from 5 frames.

Calculating the average of that buffer.

Clearing that buffer and restarting back at step 1.

So on frame 5, you would have a full buffer and a valid average color. But then you clear your buffer and have to wait until frame 10 to have a full buffer again, and hence, have to wait 5 frames for an updated average color.

I would suggest doing a continuously moving average, where you always hold on to the color samples of the past 5 frames. Each time you get a new sample, you jettison the oldest sample in your vector and add the newest sample. So on frame 6, you would have the samples from frames 2 - 6. On frame 7, you’d have frames 3 - 7. Etc. This way you can recalculate your average on every frame.

Also - the math you have at the moment might be slightly off of what you are expecting. Right now you are adding 9 samples to your buffer (buffer[i] += color), but when you calculate the average you are dividing by 5 (averageColor[i].r = buffer[i].x / sampleRate). Actually, you don’t have to store all 9 samples in an array. You can collapse your nine samples down into a single average before storing anything into your buffer.

To help explain all that, here’s something vaguely pseudocode-like:

vector buffer
int numSamples
If the frame is new,
Sample the colors at the 9 positions in the frame.
Find the average color of those 9 samples and store it in a variable, frameColor.
If the buffer's size is equal to numSamples.
We've got a full set of samples, so delete the oldest value (the first element) from the buffer to make room for the new sample.
Add frameColor to the buffer (i.e. add it as the last value in the vector).
If the buffer's size is greater than 0,
Calculate the average of the samples in buffer, the moving average

Hope that all makes sense. As an aside, if you end up needing something less computationally expensive, you could instead do an exponential smoothing operation. It’s not the same kind of smoothing, but you wouldn’t need to hold on to an array of values. For that, you would do this general pattern:

currentAverage = s * currentAverage + (1 - s) * newValue

s is your smoothing factor, a decimal between 0 and 1. When s = 0, your average is always your most recent value. When s > 0, your average becomes smoothed.

Thanks! Yes the buffer was indeed empty on start up and it crashed because of an empty pointer.

The reason why I wanted to take it every 5 frames was because I will send the data to the Philips Hue bulbs via HTTP requests, and the bulbs have themselves a built-in transition-fade from one color to the next. So I thought I don’t want to send data every frame. But I decided to build in the smoothing which is a great way to do it, and then pick out every 5th frame to send later on. With the smoothing function it got actually quite simple and there was no need for ofVec3f:

Ohhhh, I see what you are trying to do now. That makes sense about the HTTP requests - no need to spam the device. And yeah, exponential smoothing definitely makes the code simpler. Glad that part worked.

I probably should have asked before - are you using the samples to drive a single bulb or to drive nine separate bulbs? I assumed from your original post that there was just one and that you were trying to smooth both temporally (across frames) and spatially (within frames). That’s why I suggested collapsing your nine frame samples down into a single average before storing anything into your buffer. But now I’m thinking that you’ve got nine bulbs and that advice is null and void.