Convolution of a color image to itself.

'Untitled.png' is a color image of 48x48 size.

>> i = imread('Untitled.png');
>> v = i(:);
>> c = conv2(v, v);
Warning: CONV2 on values of class UINT8 is obsolete.
         Use CONV2(DOUBLE(A),DOUBLE(B)) or CONV2(SINGLE(A),SINGLE(B)) instead. 
> In uint8/conv2 (line 10) 
>> c = conv2(double(v), double(v));

The aforementioned program becomes hanged for ever.

What is wrong with this program? How to fix that?

[Walter Roberson]

Why are you using conv2() on vectors?

I just tested on R2012a with random uint8 data; the conv2 took only a fraction of second.

Answer 1

[Image Analyst]

This won't do nearly what you think it will. Basically you're taking a color image and turning it into a column vector where you have all the red pixels, column after column, then all the green pixels, column after column, and then all the blue pixels, column after column. So if you have, say, a 10 megapixel snapshot from a digital camera, now you have a 30 million element long vector. Now of course multiplying 30 million, or even a million, numbers, by another 30 million numbers will take a long time, but you have to do that 30 million times because the one 30 million long vector needs to slide along the other 30 million long vector one element at a time. So there's trillions of computations that need to be made. That will hang the computer, probably for days or weeks. OK, your image is only 48 by 48 by 3 elements long so for each 1-pixel shift you'd be doing 6912*6912 = 47 million computations. But that's for a 1 pixel shift. For all shifts you're looking at 47 million * 6912 = a third of a trillion multiplications, not to mention the sums, so this will take an extremely long time. (I'm not taking into account the extensive "tricks" they use to optimize the computation which will cut this down by quite a bit.)

But as if that weren't bad enough (assuming it could be done in a short time), what you're doing does not even make sense. Think about it. At some point you be convolving the end of one line with the beginning of the other and vice versa. That is nonsense/gibberish. Not only that (it gets worse) sometimes you'll be convolving part of one color channel with a non-corresponding part of a different color channel. Like you're multiplying the bottom 500 lines of the red channel by the top 1000 lines of the green channel. Again, this is nonsense and has no meaning so you should not do it.

I think you should try to understand theoretically what you're doing and not just blindly do an autocorrelation of a color image. A more sensible thing to do would be normalized cross correlation using the built-in function normxcorr2(), and I attach a demo for that. But it's mostly used to slide a small template across an image looking for patterns in the larger image. You would not do it for a full sized image. If you did, you kind of know what to expect even without doing it (it will have a mountain-like shape).