Legacy ImageMagick Discussions Archive

Window 7, 6.6.0-8 Q16, Source file: http://www.snibgo.org/images/f604_blackwhite_both.png

convert f604_blackwhite_both.png -channel alpha +verbose -morphology Erode Euclidean:1,100 -verbose -auto-level erode.png
Morphology Erode:1 => Changed 37194
f604_blackwhite_both.png=>erode.png PNG 604x536 604x536+0+0 8-bit DirectClass 65.5KB 0.125u 0:00.118

convert f604_blackwhite_both.png -channel alpha +verbose -morphology Erode:2 Euclidean:1,100 -verbose -auto-level erode2.png
Morphology Erode:1 => Changed 37347
Morphology Erode:2 => Changed 4502
f604_blackwhite_both.png=>erode2.png PNG 604x536 604x536+0+0 8-bit Direct
Class 49.2KB 0.172u 0:00.114

convert f604_blackwhite_both.png -channel alpha +verbose -morphology Erode:3 Euclidean:1,100 -verbose -auto-level erode3.png
Morphology Erode:1 => Changed 37235
Morphology Erode:2 => Changed 4498
Morphology Erode:3 => Changed 331
f604_blackwhite_both.png=>erode3.png PNG 604x536 604x536+0+0 8-bit DirectClass 49.2KB 0.218u 0:00.175

convert f604_blackwhite_both.png -channel alpha +verbose -morphology Erode:4 Euclidean:1,100 -verbose -auto-level erode4.png
Morphology Erode:1 => Changed 37158
Morphology Erode:2 => Changed 4501
Morphology Erode:3 => Changed 331
Morphology Erode:4 => Changed 13
f604_blackwhite_both.png=>erode4.png PNG 604x536 604x536+0+0 8-bit DirectClass 65.5KB 0.484u 0:00.340

Same input, same command except for the number of iterations. I would expect the number of pixels changed by the first iteration to remain constant, but it doesn't.

On a related note, the number of transparent pixels increases until erode3.png, which has only 13 pixels with alpha > 0. But then erode4.png has all pixels set to alpha = 255, when I would expect them to be set to alpha = 0.

I will investigate. Though an Euclidien Distance Kernel is not really designed for use with Erode.

Erode will do grayscale erosion of grayscale images, but it will only treat the kernel as being a flat shape (anything less than 0.5 or transparent is ignored). This means to erode/dilate/open/close operators an euclidien kernel is basically a 3x3 pixel square with a hollow center!

True Greyscale erosion with 3D greyscale kernels (height maps) has not been implemented. I have the mathematics for it but not any practical usage as to why anyone would use it beyond the flat boolean shapes provided by the binary erodes implemented. The only usage I have found is a morphology variation implemented as the 'Distance' function.

Thanks, Anthony. The same bad behaviour occurs with diamond, plus, disk and square.

I can see an immediate bug! that should be reported! But it is with verbose, not erode.

The way the command is given... means turn OFF verbose before the morphology and turn it on afterward. But that does not appear to be what is happening. The verbose is getting turned on before morphology (as morphology outputs info), and that is a bug!

Swapping the two arguments does the right thing for verbosness. Only output the morphology reporting.

snibgo wrote:Thanks, Anthony. The same bad behaviour occurs with diamond, plus, disk and square.

Yes I have already noted that. It is very strange! The count is actually of the number of pixels that the core code saw change. That is a change in ANY of the output channels (as per -channel) as it is being written into the destination image would increment the count. Earily versions had counts on the number of values changes rather than pixels. But the result should still be the same.

I'll need to go into the code to see what is happening.

I should have spotted that "verbose" issue. Should I start a new thread?

For my current purposes (video effects), I'm more interested in smooth changes than binary transitions, so I think 3D greyscale kernels would be useful to me. Perhaps I can do that at a lower level with "convolve".

Incidentally, I have another thread on "morphology prune" which doesn't seem to be implemented yet. Sorry to keep you busy.

The bug in Erode looks like it may be related to the multi-treaded version of IM.

Can you compile a version without thread support?

That is configure it with a --disable-openmp flag so that it does not try to use parrellel processing using multiple CPUs.

Not readily. I'm on Windows without MSVC, so it will have to wait until I can get on Linux. Tomorrow, perhaps.

That could easily explain a bad count. How about the final erode setting all pixels to 255?

Cheers.

snibgo wrote:For my current purposes (video effects), I'm more interested in smooth changes than binary transitions, so I think 3D greyscale kernels would be useful to me. Perhaps I can do that at a lower level with "convolve".

The morphlogy operators do handle the grey scale varient, in that it replaces each pixel (output channel values) with either the highest (whitest) or lowest (darkest) value in the 'shape' area. But the kernel is only looked at as a flat 'shape'.

That is gray-scale-image 'morphed' using a boolean kernel shape.

True greyscale morphology with a '3d shaped' kernel. Uses 'Nan' values to mark out the shape, and either adds or subtracts the other kernel values (0 being used for a flat shape) from the image values before deciding which value is the smallest or largest value to use. Every Greyscale example I have seen only uses a 'flat kernel shape' which is what the current operators do.

Now do you really need to be able to use non-flat 3D kernels?

For future expansion I have already arranged things so that shape kernels can generate shapes of 'zero' values surrounded by 'NaN' values, by setting a 'second' argument. Circle:{Radius},0
Without the second argument the kernel shape defaults to boolean 1 values surrounded by 'NaN' values (also classed as equivalent to boolean zero).

snibgo wrote:Incidentally, I have another thread on "morphology prune" which doesn't seem to be implemented yet. Sorry to keep you busy.

Prune is waiting for Hit and Miss Primitives to be programmed in. Unfortunately I ran out of time during my last programming period to add it. The major need is to expand the 'kernel' definition to
allow the definting of mutliple (including rotated) kernels. Also their are a lot of different 'pruning' definitions, though only one 'classical' definition.

It is not only prune that is waiting of hit-n-miss, but also Thinning and Thickening.

It is comming! In the mean time Fred Wienhaushas a script that 'classical' forms of these operations, though I do not think he has 'alpha channel' versions.

snibgo wrote:

Code: Select all

Can you compile a version without thread support?

Not readily. I'm on Windows without MSVC, so it will have to wait until I can get on Linux. Tomorrow, perhaps.

That could easily explain a bad count. How about the final erode setting all pixels to 255?

Cheers.

As you are only eroding the images alpha channel, color values should not be effected.
Of course eroding the provided image 4 times causes all the pixels to become transparent

For example using a Square (soild fill 3x3) with infinite erode...

Morphology Erode:1 => Changed 37075
Morphology Erode:2 => Changed 4131
Morphology Erode:3 => Changed 331
Morphology Erode:4 => Changed 13
Morphology Erode:5 => Changed 0

which shows the fourth erode removed (made transparent) the last 4 pixels as the fifth erode did not find any more pixels to erode!

WARNING: their is a known bug in which auto-level on an image containing only one constant value (that is minimum and maxmum value are the same) produces an undefined result (depends on the compiler).

This is probably what you are seeing.

I have submitted a patch for this bug (don't auto-level if only one value present) for IM v6.6.1-1

Actually as your image only contains on/off values and morphology does not create or mix new values, you do not need the -auto-level in your command. Remove it.

I agree, auto-level should do nothing, so I have removed it from my series of commands, and tried your command. Still, the alpha channel for all pixels becomes 255.

In my series, the problem is shown in erode4.png. I expect the final 13 pixels to be changed to alpha=0, and "verbose" reports that is happening, but in fact alpha for all pixels become 255.


convert f604_blackwhite_both.png -channel alpha -verbose -morphology Erode Square +verbose erode.png
Morphology Erode:1 => Changed 36684

convert f604_blackwhite_both.png -channel alpha -verbose -morphology Erode:2 Square +verbose erode2.png
Morphology Erode:1 => Changed 36508
Morphology Erode:2 => Changed 4123

convert f604_blackwhite_both.png -channel alpha -verbose -morphology Erode:3 Square +verbose erode3.png
Morphology Erode:1 => Changed 36602
Morphology Erode:2 => Changed 4123
Morphology Erode:3 => Changed 330

convert f604_blackwhite_both.png -channel alpha -verbose -morphology Erode:4 Square +verbose erode4.png
Morphology Erode:1 => Changed 36562
Morphology Erode:2 => Changed 4118
Morphology Erode:3 => Changed 331
Morphology Erode:4 => Changed 13

convert f604_blackwhite_both.png -channel alpha -verbose -morphology Erode:5 Square +verbose erode5.png
Morphology Erode:1 => Changed 36566
Morphology Erode:2 => Changed 4124
Morphology Erode:3 => Changed 331
Morphology Erode:4 => Changed 13
Morphology Erode:5 => Changed 0

convert f604_blackwhite_both.png -channel alpha -verbose -morphology Erode:-1 Square +verbose erodeAll.png
Morphology Erode:1 => Changed 36430
Morphology Erode:2 => Changed 4129
Morphology Erode:3 => Changed 331
Morphology Erode:4 => Changed 13
Morphology Erode:5 => Changed 0

erode4.png and erodeAll.png have all pixels=255. (So does erode5.png, which is reasonable as erode4.png has no "edges" to erode.)

snibgo wrote:I agree, auto-level should do nothing, so I have removed it from my series of commands, and tried your command. Still, the alpha channel for all pixels becomes 255.

In my series, the problem is shown in erode4.png. I expect the final 13 pixels to be changed to alpha=0, and "verbose" reports that is happening, but in fact alpha for all pixels become 255.

The resulting images for erode4.png, erode5.png and erodeAll.png (the last two to having no more pixels to erode, so are the same results as erode4.png) is fully transparent images for me.

That is as they should be. Total transparency, with the color channels untouched underneath.


The Identify of these image shows them all to have a 'Opacity Channel' of 255. Remember due to historical reasons, IM internally stores transparency as 'Opacity' NOT 'Alpha'. Even though almost all operators (-threshold being an exception) inverts the channel to treat it as alpha.

Identify statistics seems to be currently a little confused.

• Channel statistics: Alpha: seems to be showing 'opacity' values, not alpha
• Histogram: is displaing alpha values
• Colormap: is displaying opacity values and incorrect rgba() values.
  That however may be a function of the grayscale PNG, and not the actual image colors.