building images differences to get back to the original?

[Didi]

Hello to the Experts,

I have 1 image and a 2nd image and I´d like to build the difference between them as a 3rd image. After that I want to merge the 2nd and the 3rd image, and the result should give back EXACTLY the first image. This sounds easy but by using GIMP (2 layers and the modes subtraction/addition) the result does NOT match, because there´s simply a cut off (non-carrying) if the difference gets negative.

What I´d need is some kind of composite/compose magick that would roll-over negative values (e.g. dec. 5 - 10 = 250). I could also separate all images into three images (R,G,B) for the sake of having only values between 0 and 255, to make the calculating process easier. For getting back to the 1st image, there would also be the need for hopping over 255 and not cutting off there (e.g. dec. 240 + 25 = 10).

Does anyone know a solution to that problem, or does Image Magick behave different to GIMPs calculation?
Many thanks in advance & best regards!!
Didi

[Didi]

Well, just stumbled upon the commands "ModulusAdd" and "ModulusSubtract" of the "compose" command. This should wrap around 0/255.
I´ll test these commands tomorrow. If they won´t work like the way I need them, I´ll be back here again.

Kind regards,
Didi

[snibgo]

"ModulusSubtract" might be useful: http://www.imagemagick.org/Usage/compos ... s_subtract . Or "difference".

[Didi]

The "ModulusAdd" and "ModulusSubtract" commands work well, so this problem is SOLVED!
If anyone has the same task, here is the workflow including the commandlines to set:

composite -compose ModulusSubtract "OriginalImage1.bmp" "ToSubtractImage2.jpg" "ResultingImage3.png"

(image formats are converted automatically that way, png will be created with default values i didn´t find, but you´ll get a good (of course lossless) compression)

Getting back to the OriginalImage works this way:

composite -compose ModulusAdd "ResultingImage3.png" "ToSubtractImage2.jpg" "RecoveredOriginal1.bmp"

After that you can prove, if the transformation was pixel-exact. You just have to build a difference again:

composite -compose ModulusSubtract "OriginalImage1.bmp" "RecoveredOriginal1.bmp" "ProvingImage4.png"

The ProvingImage4 should be absolutely black, but you won´t easily be able to judge if it´s not containing some greysteps that would mean some differences. To easily prove this, just use the fill feature of your favourite paint program and click somewhere into the image to fill it up with white. If the image fills up white completely (with no remaining more or less grey pixels), then you can be sure of the successful operations ImageMagick processed for you.

Thanks a lot to all ImageMagick-wizards!!
Best regards,
Didi

Edit: thanks to snibgo!

[glennrp]

The ProvingImage4 should be absolutely black, but you won´t easily be able to judge if it´s not containing some greysteps that would mean some differences. To easily prove this, just use the fill feature of your favourite paint program and click somewhere into the image to fill it up with white. If the image fills up white completely (with no remaining more or less grey pixels), then you can be sure of the successful operations ImageMagick processed for you.

A simpler, quicker method is to use "identify -verbose Provingimage4.png" and look at the max and min values for the channels -- they should all be zero.

[fmw42]

Another method to see if it is a zero difference is to look at the mean value from the verbose information or

convert diffimage -format "%[fx:mean]" info:

see string formats, which also will provide the min and max and standard deviation, at http://www.imagemagick.org/script/escape.php

[Didi]

Thanks a lot to glennrp & fmw42 for a more quicker "image-is-zero"-check, especially for large images! (I´m more or less the type of "seeing is believing" which led me to my "fill-with-white" solution.)

glennrp´s command works well and usually I´d trust at first the results of ImageMagick blindly, but when I checked a COMPLETELY white image I got these results (a little shortened and line compressed here; Image Magick V6.8.0.4Q16):

Colorspace: sRGB
Depth: 8/1-bit Channel depth: red: 1-bit green: 1-bit blue: 1-bit alpha: 1-bit
Channel statistics:
Red: min: 255 (1) max: 255 (1) mean: 255 (1)
Green: min: 255 (1) max: 255 (1) mean: 255 (1)
Blue: min: 255 (1) max: 255 (1) mean: 255 (1)
Alpha: min: 255 (1) max: 255 (1) mean: 255 (1)
Image statistics:
Overall:
min: 0 (0) <------------------------------ ? ?
max: 255 (1)
mean: 191.25 (0.75)
Colors: 1

Additionally I would not prefer to use the average-function ("mean") because I wouldn´t trust the accuracy if for example only one pixel would be different inside a very large image. "min" & "max" for each channel do best because of absolute values.

fmw42´s command wasn´t working (likely I did something wrong), so I build my own ultra-long command for a short
output of the identify solution:

identify -format "\n Statistics for ""%[f]"": \n Colorspace channels: %[channels], Color depth: %[z] bits (but maybe less than that!) \n Unique colors: %[k], Max. value: %[fx:maxima], Min. value: %[fx:minima]" "CompletelyWhiteImage.png"

The output for the white image gives:

Statistics for "CompletelyWhiteImage.PNG":
Colorspace channels: srgba, Color depth: 8 bits (but maybe less than that!)
Unique colors: 1, Max. value: 1, Min. value: 1
We can see, that the output of the "Min" value is somehow correct this time!

The output for the black image gives:

Statistics for "ProvingImage4.PNG":
Colorspace channels: srgb, Color depth: 8 bits (but maybe less than that!)
Unique colors: 1, Max. value: 0, Min. value: 0
And I´m happy with that. Having only a look at the amount of unique colors could also be a proving solution, but on one hand you won´t know if the found single color is really zero-black, and on the other hand there might be a calculating error, not by ImageMagick, but by your favourite paint program, like FastStoneImageViewer V4.6, where the result can differ a bit.

A last option for precise proving would be to generate a black image the same size and type and do a binary comparison (fc /b command, if you are working with Windows).

Thanks again & Happy New Year to all Wizards in advance!
Didi

[anthony]

See...
http://www.imagemagick.org/Usage/masking/#known_bgnd

NOTE if the two images are identical in some region, you will not be able to automatically determine which image that area belongs to. There is just not enough information as the results is the same. This gets worse when semi-transparency is involved (such as along edges).