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.)

Daniel, sorry, I don't understand what "go from cubes to quarts" means. I suppose it's something about that the images are different. They are different only because I had not the original apple to show, but unfortunately it has nothing to do if the image is realistic or a draw.

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!