Legacy ImageMagick Discussions Archive

I use ImageMagick to process and analyze several types of scientific data including solar images from NASA. One of my scripts does a difference comparison between two images taken a various time intervals. I run the IM commands from batch files on Windows 7 Pro 64. The line from the script that does the work on IM 6.x looks like this...
This simply takes "sample1.png", adds #808080, then subtracts "sample2.png", and the output image is "converted.png". Changes between sources images show as brighter or darker in the result. Anything that hasn't changed between source images becomes neutral, or 128,128,128 gray (give or take a bit from normalizing). The input files and the output can be seen here...

sample1.png

(https://www.dropbox.com/s/i0z2guyugv3pb ... 1.png?dl=0)

sample2.png

(https://www.dropbox.com/s/srm4lx1512fco ... 2.png?dl=0)

converted.png

(https://www.dropbox.com/s/nqrbemposixl6 ... d.png?dl=0)

This works using "ImageMagick 6.9.2-8 Q16 x64 2015-12-05", and has always worked with various 6.x versions for at least the past 3 years. Now I'm running into a problem making the scripts work with the current "ImageMagick 7.0.0-0 Q16 x64 2015-12-12" and the past several recent versions of IM7. The exact same command using IM7...
... results in an error, and the process bails out before completion. Windows 7 Pro 64 produces this error window...

Windows error message...

(https://www.dropbox.com/s/yd57zht7aga06 ... 1.jpg?dl=0)

I've tried the HDRI and non-HDRI versions, larger and smaller source files, JPGs, PNGs, and JP2s, color and grayscale. I've tried using several variations on #808080, rgb(128, 128, 128), and gray50 for the color value. The command always succeeds with the IM 6.x "convert" command and always fails with the IM7 "magick" command.

I have no idea what's wrong here. Do you?

Try the following on all your systems. It should do the same thing, but be faster.

Your command returns expected results for ImageMagick 7.0.0-0 under Linux. We will investigate why it fails for you under Windows.

fmw42 wrote:Try the following on all your systems. It should do the same thing, but be faster.

Code: Select all

convert sample1.png ^
( -clone 0 -fill "#808080" -colorize 100 ) ^
-compose plus -composite ^
sample2.png ^
+swap -compose minus -composite ^
converted.png

Thanks. To approximate my previous results it requires "-compose add" and "-compose subtract" instead of "plus" and "minus". Oddly enough, that leaves some little artifacts in some but not all of my tests, small areas that look clipped or blown out. Building on your example, however, this seems to do exactly what the scripts require...
I realize the -fx operator isn't as fast, but I'm trying to stay consistent with data I've assembled over a few years.

magick wrote:Your command returns expected results for ImageMagick 7.0.0-0 under Linux. We will investigate why it fails for you under Windows.

Thanks for your time and attention. I've tried working the -fx operator with color names or designations, "blue" or "#0000FF" or "rgb(0,0,255)" for example, and it seems to crash IM7 every time. Even something like this works with IM6 "convert" but fails with IM7 "magick"...
Taking fmw42's example from a comment above, the command seems to work by building an image and using that in the -fx expression instead of designating a color, like this...
I can make that work for all my needs, but it is a notable change in behavior from IM6 to IM7 on my Windows 7 64 machine.

does this work
or
or
try both on and off in the above two composite approaches

see
http://www.imagemagick.org/Usage/compose/#mathematics

Thank you, fmw42, for taking the time to help work out some options.

fmw42 wrote:does this work

Code: Select all

magick sample1.png sample2.png -fx "u + 0.5 - v" converted.png

Yes, that seems to duplicate the results I was getting with IM6, pretty fast, and it doesn't crash IM7.

or

Code: Select all

magick sample1.png sample2.png +swap -define compose:clamp=on|off -compose mathematics "0,1,-1,0.5" -composite converted.png

Almost, but more like this exactly...
This works just the way I need and seems to be the fastest code even with 4096x4096 sources. And by trading the second and third compose arguments it eliminates the need for the +swap.

I've tried the "clamp=on" and "clamp=off" in every combination and it never seemed to affect any of my tests. That looks like a good thing to know for other purposes, however, and I thank you for bringing it to my attention.

This works just the way I need and seems to be the fastest code even with 4096x4096 sources. And by trading the second and third compose arguments it eliminates the need for the +swap.

Yes, that is true. I use +swap because I like to have the sign correspond to the concept and signs of of (+sample1 -sample2 = sample1 minus sample2). I know that for minus, subtract and divide, that I need the +swap to keep the mathematical sign order of the functionality. Just a way for me to make it more readable and understandable (to me).

Glad to hear it helped.

The -define compose:clamp is needed at times for mathematical -compose operations in HDRI. Those operations clamp by default and the off option avoids the clamp when it is not wanted.

The -compose mathematics does not need it because the additions are in the function and not between functions as with separate -compose plus and -compose minus. Thus -compose mathematics does not clamp in HDRI since all computations are processed at the same time within one function.

I just pushed a patch to our GIT repository to fix this issue. This should be available in the next beta this weekend.

dlemstra wrote:I just pushed a patch to our GIT repository to fix this issue. This should be available in the next beta this weekend.

This issue appears to be resolved in version "ImageMagick-7.0.0-0~beta20151219-Q16-HDRI-x64-static". Thanks!