# Arithmetic operation with color image,one channel, and different size results in bad output

It seems that if I have a colored image, and a larger image with one channel, and then use mul command, the result is rather odd.

Sample case: `sp cat +to_gray r2dx. 110%,1 *.. .`

Real world example is on my thread, and if it works as expected, I trim off more than 1/2 second on the rewrite of rep_form_pixel. Hence why this thread.

Multiplying two images with different size is actually something not well defined, mathematically.
So, what Gâ€™MIC does is multiplying the images value by value in the order they appear, from left to right and top to bottom, while keeping the size of the first operand of the multiplication.

Maybe you were expecting something different, like â€śsecond operand is resized to the dimension of the first operand before multiplicationâ€ť, but that would raise even more questions for the user :

• How resizing is performed ? is there any interpolation used ? If not, how the resized image is centered ? What if the first image has 3 channels, and the other 4 ? etc.

Thatâ€™s the kind of question we donâ€™t want to bother users with, so the Gâ€™MIC rules for all mathematical operations (`add`, `sub`, `mul`, `pow`, â€¦) that takes two images as operands are the same : value by value in the order they appear, while keeping the dimension of the first operand. And if the second operand has less values than the first, then values are repeated from the start after theyâ€™ve been all read.

For instance, the following example will darken every odd-numbered column, if your input image has an even number of column:

``````image.jpg (1,0.5) mul
``````
1 Like