Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add 2D Shape features #442

Merged
merged 4 commits into from Jan 15, 2019
Merged

Add 2D Shape features #442

merged 4 commits into from Jan 15, 2019

Conversation

JoostJM
Copy link
Collaborator

@JoostJM JoostJM commented Oct 19, 2018

Add a new featureclass implementing shape features describing a 2D shape.
This class can only be extracted if force2D = True and the size of the bounding box is 1 in the dimension specified by force2Ddimension (i.e. it must be a truly 2D segmentation)

This featureclass is therefore not enabled by default.

cc @Radiomics/developers

Calculates the Surface, perimeter and maximum diameter of a 2D shape (requires input to be a 2D numpy array and spacing).
Do not enable by default. If user enables shape2D, it first check if the user enabled force2D extraction and if the bounding box of the mask has size 1 in the specified 2D dimension. If not a warning is logged and extraction continues.
Add testing of shape 2D, using all 5 radiomics testcases. As shape2D only works with single slice segmentations, add new largest slice segmentations for each test case, and update code to allow adding of a "_2D" suffix to the testcase, indicating this 2D label should be returned as mask.

Additionally update the getTestCase function to raise an error instead of returning None in case the test case could not be obtained.
Fix typos
Add basic representation of cube/square in the algorithm
@fedorov
Copy link
Collaborator

fedorov commented Oct 19, 2018

the size of the bounding box is 1 in the dimension specified by force2Ddimension (i.e. it must be a truly 2D segmentation)

I would say the input is "truly 2D" if the ITK image passed as input is a 2D image, or perhaps if the spacing in z dimension is 0. Otherwise the definition can be ambiguous.

@pieper
Copy link
Contributor

pieper commented Oct 19, 2018

I don't think a spacing of zero is a good idea. I would think we can come up with a reasonable definition of grid samples that gracefully handles any combination of dimensions and spacings in any dimension without becoming degenerate.

@fedorov
Copy link
Collaborator

fedorov commented Oct 19, 2018

Definitely - I think it is better if the tool allowed processing of true 2d images. I suggested 0 z spacing in case we want to maintain the current convention that the input is always a 3d ITK image.

@JoostJM
Copy link
Collaborator Author

JoostJM commented Oct 22, 2018

I would say the input is "truly 2D" if the ITK image passed as input is a 2D image, or perhaps if the spacing in z dimension is 0. Otherwise the definition can be ambiguous.

Very true, and would nicely help those users that use 2D input formats (e.g. PNG; though it does not address the multiple channels issue). On the other hand, it is likely that there are also users who have 3D input image data, but only single-slice segmentations. Those are also really 2D shapes (even though the real-world shape is 3D), but there it is more likely that dimensionality of the input data is 3D.

By the way, the latter also holds true for 2D DICOM (e.g. x-ray, mammography). ITK will read this in as 3D data, with size 1 in a certain dimension.

@JoostJM JoostJM merged commit e0fdbdc into AIM-Harvard:master Jan 15, 2019
@JoostJM JoostJM deleted the shape-2D branch March 15, 2019 09:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants