LabelGeometryImageFilter not using physical space


(Dženan Zukić) #1

Looking at the code of LabelGeometryImageFilter, it seems to be doing all its calculation in index space, including volume and centroid. To add insult to injury, centroid is representated using PointType which is usually used for physical points.

Should this class be fixed to use ContinuousIndex instead of PointType to represent and return these parameters? Or should it start using physical space, perhaps with a backwards compatibility switch?


(Matt McCormick) #2

Good catch @dzenanz.

Before the ITK 5 release is a good time to make the change to physical space with a backwards compatibility switch.


(Bradley Lowekamp) #3

It has been a few years but when I look into this filter there were quite a number of issues including several places where there were issues with physical spacing, orientation, and efficiency in the computation. As I recall the way this filter computes some geometry is to convert all pixels of a label into continuous index space, then do matrix computation on the full list. This was very memory inefficient for me causing up to 16X memory usage compared to the number of pixels.

I have spent effort adding all the features and computations that the LabelGeometryImageFilter into the LabelMap statistics filters. This includes quite comprehensive testing of many complex and corner cases. This OBB are computed very efficiently from just the started and ending pixels in the line.

IMHO, this filter is redundant and should be removed to a remote module. If there is something missing from the LabelMaps statistics filter we can add that there.

EDIT:
The other option is to make the LabelGeometry filter an adapter class to the calculations done in the LabelShapeStatistiscsImageFilter…


(Dženan Zukić) #4

I changed my code to use LabelImageToShapeLabelMapFilter, thanks for pointing it out. Part of the reason I asked about it is because I remember @blowekamp adding tests and fixing something about a shape filter.

Or it could be moved into ITKDeprecated module. Refactoring LabelGeometryImageFilter will take time, and it is indeed redundant. What are other opinions about this?


(Bradley Lowekamp) #5

I am in favor of moving into the deprecated module.

I was just looking at interfaces, it looks like the LabelGeometryFilter also can optionally produce images for each label. In my only work on this topic, I created a LabelObject which can store the image, and separate filters to computer either axis aligned or oriented images for each label. Recently I have just manually resampled for label object/image out side of a filter like what was done here: