-
-
Notifications
You must be signed in to change notification settings - Fork 686
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
ENH: Add a 3D regression test for FillholeImageFilter #4330
ENH: Add a 3D regression test for FillholeImageFilter #4330
Conversation
38b3ee5
to
831ed15
Compare
Unfortunately, these tests do not reproduce the problem from #4326. |
831ed15
to
66e9631
Compare
This force push is a plain rebase. |
66e9631
to
73d8dd7
Compare
The tests pass locally now. |
return EXIT_FAILURE; | ||
} | ||
|
||
using ImageType = itk::Image<short, 2>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure why the dimensionality is hard-coded here if the purpose is to test this with 3D data. Maybe it should be provided as an input argument to the test?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This image type is only used to instantiate the reader which will determine the on-disk dimension. The DoIt
has the correct dimension.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it is too long since I have not actually read our docs or actively developed, but not sure if I understand: then why is the reader templated? Why don't we put the dimension to e.g. 1 always, regardless of the dimensionality of the image?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1 is just as arbitrary as 2. Removing the explicit dimension specification might be better? It would be 2 by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing the explicit dimension specification might be better?
If it does not have a function, then to me it does not help to have the dimension specification in any ways.
I will need to revise my knowledge about the toolkit if it does not have a function; I cannot review the PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This approach is inspired by: https://github.com/Slicer/Slicer/blob/5e45824d5cc654a8277205921fb4a1ed129167bb/Base/CLI/itkPluginUtilities.h#L17-L30
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The way I sometimes get the dimension of a file is just with the ImageIOBase:
https://github.com/SimpleITK/SimpleITK/blob/46bf97cf954646e284a8ebbc6863ac8b2c5465fe/Code/IO/src/sitkImageReaderBase.cxx#L225
73d8dd7
to
4ea40c0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for adding more testing.
Closes #4326.
PR Checklist