This behavior is still present in Octave 4.2.0 with image 2.6.1
The script from comment #0 still returns first an Euler number of 1 and then 2.

Interesting. I see that Matlab returns a different result. I suppose further investigation will be required. Though, it may be a few weeks before I can look into it.

Are you sure this fix is correct? I generated new luts and replaced the ones in bwmorph but the new test for shrink still fails.

I was working from the 3rd edition of Digital Image Processing myself. After noticing that this connectivity break would be prevented by the 'thinonly' L Cluster pattern in Table 14.32, I examined the text in more detail. On page 416, it states 'The shrink and thin unconditional patterns are identical, as shown in Table 14.32.' which is a bit contradictory.
Sure enough, in the 4th edition of Digital Image Processing, the 'L Cluster (thinonly)' label in Table 14.32 was changed to just 'L Cluster'.
I'm afraid I haven't tested it in octaveimage, but I've attached my attempt at a fix.
Additionally, I noticed that the Skeletonize Unconditional Mark Patterns in Table 14.33 also appear different in the 4th edition (p.440, 4th edition. p.420, 3rd edition). That may be worth looking into.
(file #33224)

Thanks, I will check this

See page 411 of Digital Image Processing" by William K. Pratt. It has an explanation of the operation (which I never read, I did not implement this function) with a table for hit and miss SE to use.
I am unsure if this operation has been formalized but that is the one we would need to implement for Matlab compatibility (at least that seems to be the one that Matlab lists as reference).

What's the mathematical definition of shrink?

You are correct, the current implementation seems indeed to be wrong. I added a failing test to the function http://hg.code.sf.net/p/octave/image/rev/de3b5ff642f0
I would appreciate if you could submit a patch to fix this (it may be helpful to look into the devel/ http://hg.code.sf.net/p/octave/image/file/de3b5ff642f0/devel
My understanding is that some of those files helped on developing this functions but that was way before I got involved with Octave).

The documentation for bwmorph shrink states that it preserves the Euler number, but I've found a case where that doesn't seem to be true.
I discovered this while implementing shrink in C++ from the book "Digital Image Processing" by William K. Pratt. I was surprised by my result, so I checked it against Octave's result. I was then very surprised when Octave's result matched mine. I think we both might be making the same mistake.
