Possible bug with -unsharpen introduced with 6.8.4-0

[thomasp]

For the code below I get different results with different ImageMagick versions:

Code: Select all

convert example.png -quality 0 -density 72 -resize 'x30>' -unsharp 0x0.5 out.png

with ImageMagick 6.8.0-10 2013-06-05 it looks fine
with ImageMagick 6.8.4-10 2013-04-19 (also tested with ImageMagick 6.8.6-3 2013-07-12 Q16) it gets blurred.

Here is the example.png http://magick-problems.s3.amazonaws.com/example.png

Could this be related to changes made for version 2013-03-20 6.8.4-0:

…The -blur, -guassian-blur, and -sharpen are now convenience methods for -morphology convolve…

http://www.imagemagick.org/script/changelog.php

[snibgo]

I can't confirm that result.

Considering unsharp only, ie with command...

Code: Select all

convert in.png -unsharp 0x0.5 out.png

... I find that 6.7.9-6, 6.8.0-9, 6.8.1-10, 6.8.2-0, 6.8.3-0 give the same results, which are slightly sharper then the original.

6.8.4-0, 6.8.5-0, 6.8.6-0 are the same, and noticably sharper than 6.7.9-6 etc.

Changing the unsharp to 0x2, the difference between the IM versions is reduced (as shown by compare), and they all visually seem identical.

In no case do I find that unsharp has actually blurred an image.

I've done this testing with my own images. I've confirmed it with thomasp's image, but that image is rather small with little detail, and is complicated by the transparent background.

thomasp: can you confirm the result for unsharp only, ie with no other commands, especially with no resize?

[magick]

Stand by. The change was indeed our adoption of the morphology convolution method. Anthony wrote this code and we're waiting for a response from him. It could very well require a change in the sigma parameter, however, we'll let Anthony advise us since he knows the algorithm best.

[snibgo]

FWIW, I reckon v6.7.9 "-unsharp 0x0.5" and v6.8.6 "-unsharp 0x0.43" are virtually and visually the same (using trial-and-error with "compare" to find the minimum difference).

[GreenKoopa]

I recently had a post about translating GIMP's Unsharp Mask to IM's -unsharp. I determined:
im_gain = gimp_amount
im_sigma = ( gimp_radius + 1 )
im_radius = 2 * ( gimp_radius + 1 )
except it was closer to + 0.9 than + 1. Maybe this is related? I think those tests were using 6.8.6-3.

That post also noted an inconsistency in the documentation and noted which place was correct.

[thomasp]

To give a more precise example I left out resizing and other options and render the result against a black background, here you can clearly see the different results using different ImageMagick versions:

Code: Select all

convert example.png -unsharp 0x0.5 -background black -flatten out.png

ImageMagic 6.8.4 (edges get white blur):


in ImageMagick 6.8.0:


To make the problem more visible here a comparison with increased sigma from 0.5 to 2

Code: Select all

convert example.png -unsharp 0x2 -background black -flatten out.png

ImageMagic 6.8.4:


ImageMagick 6.8.0:


Here is the example.png http://magick-problems.s3.amazonaws.com/example.png

[thomasp]

Using the parameters suggested here viewtopic.php?f=1&t=23747#p100643 I get the following results, so I don't think this issue can be resolved by tweaking the unsharpen parameters.

Code: Select all

convert example.png -unsharp 12x6+0.5+0 -background black -flatten out.png

ImageMagic 6.8.4:


ImageMagick 6.8.0:


The problem seems to be an issue with transparency:

If I render the input file against a black background first and then unsharpen the image the result looks the same. However this is not a solution if you need an output file with transparency.

Code: Select all

 convert example.png -background black -flatten -unsharp 12x6+0.5+0 out.png

ImageMagic 6.8.4:


ImageMagick 6.8.0:

[snibgo]

I don't know why "-unsharp" seems to blur the alpha channel. But you can prevent this from happening:

Code: Select all

convert example.png -channel RGB -unsharp 12x6+0.5+0 +channel -background black -flatten out.png

[anthony]

Note I have not looked at or modified the Morphology code in a long time. It was (and should be) correct.
Wish I had more time but I don't any more


Before the change to morphology.. Blur and Gaussian blur did not handle transparency (alpha blending), unless you specifically included it in a non-default -channel setting of RGBA

That was nonsensical, as it meant that normally invisible transparent colors would take part of the blur.

After the change (if the code is working right) Alpha blending (correct handling of transparent colors) would be enabled BY default. that is Image has an alpha channel enabled, and the default 'Sync' channel flag was present.

To prevent alpha blending (just blur channels as if they were completely separate grayscale images) you can do any of the following..
1/ turn of alpha using -alpha off
2/ Make alpha opauqe using -alpha opaque - both of which results in transparency color blending
3/ replace transparency with a fixed color using -alpha remove
See IM examples, Removing Transparency from Images
http://www.imagemagick.org/Usage/masking/#alpha_remove
4/ Set channels so as to remove the 'sync' flag (IE enable channel selection)
using -channel RGBA (alpha and cloor channels blurred with out blending making more hidden color visible)
using -channel RGB (does not modify alpha, though hidden colors is still blurred in result)
This is equivelent to using a 'Write Mask'
5/ Use a "Read Mask"

That last IS DIFFERENT. It means simply do not involve any 'masked' color in the bluring process.
That is do not read those pixels when blurring the image! this is NOT easy to do in IMv6.
and is NOT the same as a write mask.
See IM Examples, Read Masks
http://www.imagemagick.org/Usage/masking/#read_mask

[anthony]

Additional...


Unsharpen is supposed to ignore 'special convolve specific' user settings such as -channel, -bias and convolve defines.

That is because it is a special 'higher-level' operation that is above (and internally controls) those lower level settings for its own specific use, so as to avoid effects that could be detrimental to its performance. I designed Morphology with such 'higher level' operators in mind.

This should not change!!!!

Before morphology unsharp (and other operators) were detrimentally effected by things like 'bias', which unsharp has no need for.

[snibgo]

Unsharpen is supposed to ignore 'special convolve specific' user settings such as -channel, -bias and convolve defines.

Perhaps it's supposed to ignore -channel, but it doesn't, as I showed above.

A more specific example:

Code: Select all

convert -size 100x50 xc:gray(25%) xc:gray(75%) -append -channel R -unsharp 0x5 +channel br.png

convert -size 100x50 xc:gray(25%) xc:gray(75%) -append -channel B -unsharp 0x5 +channel bb.png

The results are different.

[anthony]

That just means the 'unsharp' operator specifically passed the 'user defined' setting to the Morphology 'Apply' function.
That means the operator considered that a 'channel' user define was 'appropriate'. On the other hand, kernel scaling and output bias, should not be user controlled via 'morphology' defines.


The nitty-gritty...

Basically morphology has two types of calls. a user controlled general 'Morphology' function, and a operator controlled 'Apply' function, which allows them to sepecifically pass exactly what they need without user settings interfering, (unless it wants them).

The ONLY user setting not overridable is 'verbose', so you can still use it to see if it is doing 1 pass or 2, and what type of morphology operator.

Apply settings (operator controled unless it specifically passes the user setting) include
morphology_kernel_list (pre-scaled), morphology_method,
multi-kernel composition method (typically set to 'undefined', to use the default for the 'method'),
channel, bias, number_of_iterations,
and of course what image the operator is applying the morphology to.

Note that the operator level Apply function does not do any 'show kernel' debug output.


The user level Morphology Call on the other hand sets all the above from current user defined settings (or appropriate defaults),
And for Convolve/Correlate will scales the input kernel according to user settings, then shows a debug output for the kernel if the 'showkernel' define is given.


The separate calls is important, as previous to the change setting a 'bias' could have disastrous results in operators that would otherwise be thought as 'unrelated'... Like unsharpen, blur, variable_blur, etc...