Fri 23 Dec 2016 07:17:48 PM UTC, comment #8:
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.
|
Tue 03 Mar 2015 12:16:51 AM UTC, comment #7:
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.
|
Mon 02 Mar 2015 08:49:07 PM UTC, comment #6:
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.
|
Mon 02 Mar 2015 01:37:14 AM UTC, comment #5:
I was working from the 3rd edition of Digital Image Processing myself. After noticing that this connectivity break would be prevented by the 'thin-only' L Cluster pattern in Table 14.3-2, 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.3-2.' which is a bit contradictory.
Sure enough, in the 4th edition of Digital Image Processing, the 'L Cluster (thin-only)' label in Table 14.3-2 was changed to just 'L Cluster'.
I'm afraid I haven't tested it in octave-image, but I've attached my attempt at a fix.
Additionally, I noticed that the Skeletonize Unconditional Mark Patterns in Table 14.3-3 also appear different in the 4th edition (p.440, 4th edition. p.420, 3rd edition). That may be worth looking into.
(file #33224)
|
Sun 01 Mar 2015 08:05:31 PM UTC, comment #4:
Thanks, I will check this
|
Sun 01 Mar 2015 07:20:15 PM UTC, comment #3:
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).
|
Sun 01 Mar 2015 06:57:31 PM UTC, comment #2:
What's the mathematical definition of shrink?
|
Sun 01 Mar 2015 02:22:00 PM UTC, comment #1:
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).
|
Sun 01 Mar 2015 11:03:33 AM UTC, original submission:
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.
|