Legacy ImageMagick Discussions Archive

I was just notified by a user of my binomial script that it is not working in IM 6.5.9 or 6.0.0 (and probably changed between 6.5.9.0 and 6.5.9.5). So I tested it under IM 6.0.0.-1 Q16 Mac OSX and find the results are completely different from what they used to be. (see my examples at http://www.fmwconcepts.com/imagemagick/ ... /index.php)

My binomial script makes use of -convolve. I suspect that Anthony has folded in his changes from -morphology with perhaps some strange automatic normalization, in this case when I have both positive and negative weight that do not add to 0. The filter is symmetric so a change from correlation (which it used to do) to true convolution, which is a 180 deg rotate of the kernel, should not matter.

Here are the old results for 50% mix of the image with a binomial high pass filtered image along with the convolution kernels.

The forumula I used in my script to compute the kernel is:
f = s*i - m*b for the high pass filter kernel, where s is the sum of the weights for the un-normalized binomial kernel b and m is a mixing fraction between 0 and 1 (or in percent 0 to 100 percent as used in the script)

So in the case below:

Here is one example of running binomial and the IM convolve kernels the way it used to work.


original image:




binomial -t high -m 50 -w 3 lena3.jpg lena3_high_m50_w3.jpg

2D (Un-Normalized) Binomial Kernel
1 2 1
2 4 2
1 2 1

2D Final Kernel
-.500 -1.000 -.500
-1.000 14.000 -1.000
-.500 -1.000 -.500

IM Final Kernel
-.500,-1.000,-.500,-1.000,14.000,-1.000,-.500,-1.000,-.500




Here is the same thing with bad results now in IM 6.0.0.-1

original image:



Here is one example of running binomial and the IM convolve kernels the way it used to work.


binomial -t high -m 50 -w 3 lena2.jpg lena2_thi_m50_w3.jpg

2D (Un-Normalized) Binomial Kernel
1 2 1
2 4 2
1 2 1

2D Final Kernel
-.750 -1.500 -.750
-1.500 13.000 -1.500
-.750 -1.500 -.750

IM Final Kernel
-.750,-1.500,-.750,-1.500,13.000,-1.500,-.750,-1.500,-.750



Which is the same result now as running:

convert lena2.jpg -convolve "-.500,-1.000,-.500,-1.000,14.000,-1.000,-.500,-1.000,-.500" lena2_binomial_m50.jpg


Anthony, please help. Let me know what changes have been made or if this is just a bug. I have numerous scripts that use -convolve and I really did not want to change them all. Many, if not all, are broken now.


Fred

We'll take a look at the problem tomorrow but in the mean-time can you normalize the kernel before you pass it to -convolve. Its possible the automatic normalization was turned off.

The kernel values are consistent now with the way -convolve used to work. I suspect that some extra normalization has been added or changed for the case when there are positive and negative weights that do not add to zero. If I do not know how it is being normalize or the way it used to be normalized, I cannot figure out what to change. But I was hoping there would be some flag to set for the normalization so that it could be used as before, if not just put back the way it used to be. Let others uses -morphology to use the new normalizations, if they want. But it would be preferable on my part that -convolve did not change or at least there would be a simple way to use the old normalizations (and the correlation mode it used to be in). In otherwords, leave -convolve the way it used to be for backward compatibility and if users want the more correct convolution, then use -morphology.

This is getting somewhat messy by insisting that -convolve be changed to be consistent with -morphology convolve, if that is what has happened as Anthony has some changes to the way things get normalized. If there is a simple means of running -convolve with some extra -set option to put it back into its old format or normalization, then I can live with that and changing my scripts to conform.

Thanks. Tomorrow will be fine to see what is happening and go from there to discuss the ramifications and fix it as soon as convenient.

The problem you reported is fixed in ImageMagick 6.6.0-2 available in about an hour.

magick wrote:The problem you reported is fixed in ImageMagick 6.6.0-2 available in about an hour.

Thanks for the extremely fast response on this. I appreciate it greatly.

I will download and test and report back.

Fred

magick wrote:The problem you reported is fixed in ImageMagick 6.6.0-2 available in about an hour.

I get errors on make:

ld: Undefined symbols:
_ConvoleImageChannel
/usr/bin/libtool: internal link edit command failed
make[1]: *** [wand/libMagickWand.la] Error 1
make: *** [all] Error 2

We'll have a fix for this problem in about an hour.

Download ImageMagick-6.6.0-3 and see if the -convolve option is working properly.

magick wrote:Download ImageMagick-6.6.0-3 and see if the -convolve option is working properly.

Sorry, unfortunately, it is still not yet correct. A bit better, but still not working. The examples above are closer, but now appear to be more like the input image than the correct output image, i.e. practically no change from the input.

Here are some examples that demonstrate this at the extreme for getting edges with kernels that sum to zero. These are results by taking the kernels from the scripts and applying them directly with -convolve. (The scripts produce the same bad results as directly with -convolve).

The edges are suppressed too much and so this is why the examples above appear more like the input image than the correct output image.

Apparently they are now over-normalized so the edges are too weak relative to what we had some releases ago when things were working correctly.

original:



This is what it used to give for a laplacian edge detection:

convert zelda3.jpg -convolve "-1.000,-1.000,-1.000,-1.000,8.000,-1.000,-1.000,-1.000,-1.000" zelda3_f3.jpg




This is what I get with 6.0.0.-3 beta

convert zelda3.jpg -convolve "-1.000,-1.000,-1.000,-1.000,8.000,-1.000,-1.000,-1.000,-1.000" zelda3_lap3_convolve.jpg





Similarly,

Old:

convert lena2g.jpg -convolve "-1.000,-2.000,-1.000,-2.000,12.000,-2.000,-1.000,-2.000,-1.000" lena2g_high_m100_w3.jpg.jpg



New:

convert lena2g.jpg -convolve "-1.000,-2.000,-1.000,-2.000,12.000,-2.000,-1.000,-2.000,-1.000" lena2g_bin_convolve.jpg




Thanks for your attention to this.

Fred

We can reproduce the problem you posted and have a patch. A new release will be available in about an hour.

magick wrote:We can reproduce the problem you posted and have a patch. A new release will be available in about an hour.

Just downloaded the latest beta 6.0.0.3 and get the same erroneous results. I hope I am just premature testing and that you have not updated the beta yet. Let me know.

Grab the latest from ftp://magick.imagemagick.org/pub/ImageMagick or ftp://magick.imagemagick.org/pub/ImageMagick/beta.

magick wrote:Grab the latest from ftp://magick.imagemagick.org/pub/ImageMagick or ftp://magick.imagemagick.org/pub/ImageMagick/beta.

Thanks. I must have just missed the update as the timestamp has just changed. I was getting it from the latter above. I am downloading the new one and will report back shortly.

Fred

magick wrote:Grab the latest from ftp://magick.imagemagick.org/pub/ImageMagick or ftp://magick.imagemagick.org/pub/ImageMagick/beta.

Closer, but still not the same as before.

Original:




Old Good Result:

convert zelda3.jpg -convolve "-1.000,-1.000,-1.000,-1.000,8.000,-1.000,-1.000,-1.000,-1.000" zelda3_f3.jpg




New Result from latest 6.0.0.3 beta

convert zelda3b.jpg -convolve "-1.000,-1.000,-1.000,-1.000,8.000,-1.000,-1.000,-1.000,-1.000" zelda3_lap3_convolve3.jpg




Animation of two images:




Just had an Idea that perhaps you have the kernel values negated. So I tried:

convert zelda3b.jpg -convolve "1,1,1,1,-8,1,1,1,1" zelda3_lap3_convolve4b.jpg



compare -metric rmse zelda3_lap3_convolve4b.jpg zelda3_f3.jpg null:
0 (0)


So that appears to be the cause of the difference for zero sum kernels (or possibly kernels with any negative values. I will have to test further.

Fred

magick wrote:We're getting identical results with the old -convolve option and the new one where we adapted Anthony's new kernel methods. Post the output of identify -version. Do you have the OpenCL feature enabled? Perhaps the OpenCL convolve methods are returning different values that the CPU version. When we tested, they were identical.

convert -version
Version: ImageMagick 6.6.0-3 2010-03-05 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2010 ImageMagick Studio LLC
Features:


Just tried other test and they seem to work fine for non-zero summed kernels. However, the odd thing is that using a grayscale image gives the same results as the old version.

original:




Old:

convert lenagc.jpg -convolve "-1.000,-2.000,-1.000,-2.000,12.000,-2.000,-1.000,-2.000,-1.000" lenag_high_m100_w3.jpg



New:

convert lenagc.jpg -convolve "-1.000,-2.000,-1.000,-2.000,12.000,-2.000,-1.000,-2.000,-1.000" lenagc_thi_m100_w3_c.jpg



compare -metric rmse lenag_high_m100_w3.jpg lenagc_thi_m100_w3_c.jpg null:
0 (0)


So it appears to be somehow connected with non-grayscale images? Very strange!