Is PERIMETER, BOUNDING PIXELS in PREMIER equivalent "PERIMETER2" in PLUS?

mbatchelor

All --

I am updating a PLUS MACRO to a PREMIER APPLICATION and the PLUS MACRO uses the PERIMETER and PERIMETER2 MEASUREMENTS together to arrive at the HOLE PERIMETER.

I think PERIMETER, BOUNDING PIXELS in PREMIER is equivalent "PERIMETER2" in PLUS.

I've run a test (see 2015-05-14-181129.jpg) and they seem to report the approximately the same numbers but the TOOL TIP for PERIMETER, BOUNDING PIXELS says "HOLES IGNORED".

So . . .

Is PERIMETER, BOUNDING PIXELS in PREMIER equivalent "PERIMETER2" in PLUS?

-- Matt

CraigW

Matt, yes, the "Holes Ignored" category is a bug (I've entered a report on it).  The pixel-based mRgnPerimeter2 does include hole bounding pixels in its calculations, while the polygon-based mRgnPerimeter does not.  So yes, mRgnPerimeter2 is what used to be called just PERIMETER in IPPlus.

However, you are sort of comparing apples and oranges here since as you can easily test by getting both mRgnPerimeter and mRgnPerimeter2 on an object with no holes.  The polygon based mRgnPerimeter will almost always be smaller than the pixel-counting, largely because, by default, the vertices of Count/Size detected boundaries follows the pixel centers of the boundary pixels, not their outsides.  As a result, mRgnPerimeter2-mRgnPerimeter will show a positive value for blobs without any holes.

So if you want to measure the perimeter of holes, the one way to do it is to just extract the holes and make measurements directly.   The McRegions.Holes property returns a McRegions with just the holes as the features (note that these "hole features" might have holes within them if there are nested foreground areas with the original holes).  You can then measure mRgnPerimeter or mRgnPerimeter2 on these holes, as you wish; e.g., myRegions.Holes.mRgnPerimeter will give the polygon based perimeter(s) of the hole(s) in myRegions.

Alternately, you could compare mRgnPerimeter2 before and after calling McRegions.FillHoles.  This would have the advantage (or disadvantage) of giving you one number for all holes within each region feature rather than the perimeters of individual holes as would be the case with the other approach.

mbatchelor

mbatchelor

All --

Can someone address this question please?

Thanks.

-- Matt

mbatchelor

Craig --

Thank you very much for your response.

If I understand what you are saying about APPLES and ORANGES then:

** PERIMETER, BOUNDING POLYGON
**** Reports the OBJECT PERIMETER (based on the PIXEL CENTERS) for the OUTER PERIMETER plus the INNER PERIMETER(S) if there are any

** PERIMETER, BOUNDING PIXELS
**** Reports the OBJECT PERIMETER (based on the PIXEL EDGES) for the OUTER PERIMETER and ignores any INNER PERIMETERS

So (from the example in the JPG IMAGE) . . .

If I use

    OUTER PERIMETER
        = PERIMETER, BOUNDING POLYGON (CENTERS ignoring HOLES)
        = 706.16

    INNER (HOLE) PERIMETER
         = PERIMETER, BOUNDING PIXELS (EDGES including HOLES)
            - PERIMETER, BOUNDING POLYGON (CENTERS ignoring HOLES)
         = 1044.31 - 706.16
         = 338.15

Then INNER PERIMETER will actually DEVIATE from the HOLE PERIMETER POLYGON (if it was available) by

    INNER (HOLE) PERIMETER DEVIATION
         = (OUTER BOUNDING PIXELS (A) - OUTER BOUNDING POLYGON (B)) +
            (INNER BOUNDING POLYGON (C) - INNER BOUNDING PIXELS (D))
         = (743.02 - 706.16) + (??? - ???)

Where

    A > B
    C > D

So in this case

    DEVIATION >= 36.86

That means about a 10% error for the ID if this example is close to the scale of the objects being measured.

Because of this, I'll try to use

    IDs = myRegions.Holes.mRgnPerimeter

I think that the OBJECT FINDING ALGORITHM will eliminate any OBJECTS with MULTIPLE HOLES, I think that aspect of your summary is important in general but it does not apply to this case.

Thanks again.

-- Matt

CraigW

Actually, the first part of your reply is backwards.

"** PERIMETER, BOUNDING POLYGON
**** Reports the OBJECT PERIMETER (based on the PIXEL CENTERS) for the OUTER PERIMETER plus the INNER PERIMETER(S) if there are any"

is NOT correct. The Polygon-based perimeter (mRgnPerimeter) only reports the boundary of the outer boundary; any holes are ignored.

"** PERIMETER, BOUNDING PIXELS
**** Reports the OBJECT PERIMETER (based on the PIXEL EDGES) for the OUTER PERIMETER and ignores any INNER PERIMETERS"

is also incorrect.  The perimeter based on bounding pixels, mRgnPerimeter2, is computed by counting the bounding pixels of both the outer boundary and any hole boundaries, with a correction for diagonally placed pixels (such pairs are given an extra weight of 1.14).

However, the rest of your answer is essentially correct: you should never expect mRgnPerimeter and mRgnPerimeter2 to yield the same value, even on a blob with no holes.

Finally, I'm somewhat confused at your "I think that the OBJECT FINDING ALGORITHM will eliminate any OBJECTS with MULTIPLE HOLES", since in general our segmentation algorithms do not discriminate against multiple holes.  Of course, if you have set up a filter to only allow objects with a hole count of 0 or 1, then of course objects with multiple holes will be ignored.  This might be dangerous, though, because even a very small hole would lead to the parent object being rejected.

CraigW

Whoops, that should be 1.41 (square root of 2), not 1.14.

mbatchelor

Craig --

Thanks for the clarification.

I think we are on the same page.

I was hitting my pre-lunch dip in concentration / IQ.

Thanks again.

-- Matt