bugGNU Octave - Bugs: bug #44396, [octave forge] (image) bwmorph...

 
 

bug #44396: [octave forge] (image) bwmorph shrink does not preserve Euler number

Submitted by:  Cory Bloor <cbloor>
Submitted on:  Sun 01 Mar 2015 11:03:33 AM UTC  
 
Category:  Octave Forge Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Confirmed Assigned to:  None
Originator Name:  Cory Bloor Open/Closed:  Open
Release:  other Operating System:  Any

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

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.

Hartmut <hardy>
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.

Cory Bloor <cbloor>
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.

Carnë Draug <carandraug>
Project Member
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)

Cory Bloor <cbloor>
Sun 01 Mar 2015 08:05:31 PM UTC, comment #4:

Thanks, I will check this

Avinoam Kalma <avinoam>
Project Member
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).

Carnë Draug <carandraug>
Project Member
Sun 01 Mar 2015 06:57:31 PM UTC, comment #2:

What's the mathematical definition of shrink?

Avinoam Kalma <avinoam>
Project Member
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).

Carnë Draug <carandraug>
Project Member
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.

Cory Bloor <cbloor>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #33224:  shrink-fix.diff added by cbloor (2KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Updated the item)
  • -email is unavailable- added by hardy (Posted a comment)
  • -email is unavailable- added by avinoam (Posted a comment)
  • -email is unavailable- added by cbloor (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-08-13 jwe Summaryimage package: bwmorph shrink does not preserve Euler number => [octave forge] (image) bwmorph shrink does not preserve Euler number
    2015-03-02 cbloor Attached File- => Added shrink-fix.diff, #33224
    2015-03-01 carandraug StatusNone => Confirmed
        Release3.8.1 => other
        Operating SystemGNU/Linux => Any
        Summarybwmorph shrink does not preserve Euler number => image package: bwmorph shrink does not preserve Euler number

    Back to the top


    Powered by Savane 3.4