Using the -edge command with a radius of 1 does not seem to work correctly. The output image is the same as the input. Radius 2 works OK, but the edge is 2 pixels wide, not 1 pixel.
The following illustrates the problem. You may recognize this from a recent post about another -edge bug (at http://www.wizards-toolkit.org/discours ... 81e#p88461), with the radius changed from 2 to 1:
convert -size 64x64 xc:white xc:black +append ( +clone -flop ) -append -edge 1 1test_img6.gif
Note: I couldn't figure out how to insert images. The (correct, IMO) result under ImageMagick 6.7.0-6 2011-06-07 Q16 is almost the same as the first image in the above post (the difference is that my result has a single pixel edge, not double).
ImageMagick 6.8.0-7 generates the second (incorrect) image in the above-referenced post.
I built under Windows using Visual Studio 2010 from sources contained in ImageMagick-windows.zip, downloaded on 11/27/2012 with SHA = 62481a8c5c90900559fbb66cfd917a1d26ded3ac525ea8fc0a2599edea02103e.
Possible Bug ImageMagick 6.8.0-7 2012-11-23 Q8
-
- Posts: 2
- Joined: 2013-01-22T11:45:48-07:00
- Authentication code: 6789
- fmw42
- Posts: 25562
- Joined: 2007-07-02T17:14:51-07:00
- Authentication code: 1152
- Location: Sunnyvale, California, USA
Re: Possible Bug ImageMagick 6.8.0-7 2012-11-23 Q8
It works fine for me under IM 6.7.1.10 Q16 Mac OSX Snow Leopard for both -edge 1 and -edge 2
using
convert -size 64x64 xc:white xc:black +append \( +clone -flop \) -append -edge 1 show:
convert -size 64x64 xc:white xc:black +append \( +clone -flop \) -append -edge 2 show:
Perhaps you need to upgrade. Perhaps the fix was after your version.
using
convert -size 64x64 xc:white xc:black +append \( +clone -flop \) -append -edge 1 show:
convert -size 64x64 xc:white xc:black +append \( +clone -flop \) -append -edge 2 show:
Perhaps you need to upgrade. Perhaps the fix was after your version.
-
- Posts: 2
- Joined: 2013-01-22T11:45:48-07:00
- Authentication code: 6789
Re: Possible Bug ImageMagick 6.8.0-7 2012-11-23 Q8
I think I solved this, but I'm not sure if it's the right solution.
I grabbed and built the latest ImageMagick-windows.zip which "convert -version" shows is 6.8.1-10 2013-01-17 Q8, and the problem was still there (building with both 8-bit and 16-bit quantum).
After much digging today, I determined that the output image is not always exactly the same as the input image (as was the case with the one test image). The results vary (but are still incorrect) when you try more complicated images (or with grayscale instead of just black and white).
The problem was caused by MagickRealType being set by default to float (which is 4-byte, single-precision in the Microsoft compiler). When performing a convolution (which is done by ConvolveImageChannel, in effect.c), the lack of precision causes a cumulative error. For example, if the pixel being calculated is not near an edge, convolving with the edge kernel should generate a value of 0.0000000. Instead, the precision error caused this value to be slightly positive (though more than the maximum quantum) and therefore a white pixel was output instead of a black one.
I realize that using double instead of float increases memory requirements. Maybe there is a way to make it work with single-precision float (I thought it might have something to do with the threshold used by PerceptibleReciprocal)? I don't have enough understanding to answer.
I grabbed and built the latest ImageMagick-windows.zip which "convert -version" shows is 6.8.1-10 2013-01-17 Q8, and the problem was still there (building with both 8-bit and 16-bit quantum).
After much digging today, I determined that the output image is not always exactly the same as the input image (as was the case with the one test image). The results vary (but are still incorrect) when you try more complicated images (or with grayscale instead of just black and white).
The problem was caused by MagickRealType being set by default to float (which is 4-byte, single-precision in the Microsoft compiler). When performing a convolution (which is done by ConvolveImageChannel, in effect.c), the lack of precision causes a cumulative error. For example, if the pixel being calculated is not near an edge, convolving with the edge kernel should generate a value of 0.0000000. Instead, the precision error caused this value to be slightly positive (though more than the maximum quantum) and therefore a white pixel was output instead of a black one.
I realize that using double instead of float increases memory requirements. Maybe there is a way to make it work with single-precision float (I thought it might have something to do with the threshold used by PerceptibleReciprocal)? I don't have enough understanding to answer.
Re: Possible Bug ImageMagick 6.8.0-7 2012-11-23 Q8
We can reproduce the problem you posted and have a patch in ImageMagick 6.8.2-0 Beta available by sometime tomorrow. Thanks.