Probably this is because of the new Image processing functionality in Mathematica 9 and 10.

However I found that you can regain the sort of thing you want to do by first Rasterizing the image that you are starting with and then using that rasterized version.

Give it a try and let me know if it works for you.

You are right, rasterizing the image first works fine. Too bad I have to do it prior the integration (I liked just dropping images), but, it works, good enough.

Thanks!

So, the Image head (from the drag or copy/past) is not treated by the Integrate in the same way as the graphics head (from the Rasterize). I imagine this is just something that was overlooked on the language unification, and that it could be improved on future versions. Right?

It is not exactly a bug. V7 used an early version of the Image object which just piggy backed on top of Graphics. Starting in V9, the image became a fully native type, like Integer, String, and Graph, and as a consequence it became AtomQ. Integrate generally considers AtomQ expressions other than symbols as not valid variables. You can't integrate with respect to 2 or "hello world". Theoretically, Integrate could be made to recognize Image as a variable, but the wisom and consequences of such a change are are unclear. So we cannot promise that this will be changed in a future version, but it will of course be considered along with other feedback regarding integrate.

(The rasterize version works for a rather different and not particularly relevant reason: because people have many different conventions for naming their variables, including x1, x[2], and Subscript[x,3], Integrate generally considers anything expression of the f[args___] family to be a vaid variable as f does not have attribute NumericFunction. This allows things like Subscript[x,3] while disallowing nonsensical expressions like x+y or Sin[x]. Because Rasterize produces a Graphics object, it just happens to work by accident--like the old image object--as Graphics is not NumericFunction.)