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

Make DrawEM distribution package friendly #33

Open
schuhschuh opened this issue Jan 4, 2021 · 5 comments
Open

Make DrawEM distribution package friendly #33

schuhschuh opened this issue Jan 4, 2021 · 5 comments

Comments

@schuhschuh
Copy link
Member

Rolf suggested in the MIRTK chat to enable use of an already existing N4 installation instead of building ITK from scratch. This should be easy to facilitate with a change of the CMakeLists.txt and would shorten build time.

@schuhschuh
Copy link
Member Author

schuhschuh commented Jan 4, 2021

Just looked at the CMakeLists.txt. For what it's worth @soundray, you can at least use an existing ITK installation to build the N4 binary included in Draw-EM to save some build time.

But of course I see the issue of having a duplicate N4 binary in the MIRTK installation PATH. I think the N4 binary build and installed as part of Draw-EM should probably have a different name, such as DrawEM-N4 to not shadow an existing ANTs installation. [besides the option to skip build/installation as part of Draw-EM altogether as suggested]

@soundray
Copy link

soundray commented Jan 4, 2021

Thanks Andreas. The background to this is that I have suggested inclusion of DrawEM in the NixOS package of MIRTK. Heads up to @lheckemann who maintains it.

@schuhschuh
Copy link
Member Author

schuhschuh commented Jan 4, 2021

I see, thanks for this additional info. Sounds good to me.

Regarding N4, I think ANTs only contains a program called N4BiasFieldCorrection as part of the Examples folder. Is this one installed as part of the Nix package ants? Otherwise, I think N4 (as most of ANTs) is probably included in ITK 4 now. I wonder if it would be best for Draw-EM to use a custom Python script to execute the N4BiasFieldCorrectionFilter via SimpleITK instead. How would you handle such Python package dependency in Nix?

More generally, I wonder about a few challenges for creating a distribution package for Draw-EM at the moment:

  • How to handle data dependencies such as brain atlases (usually expected to be located in source tree).
  • Shell scripts may need changes as these refer to configuration files in the source tree. Also, neither these scripts nor the configuration files are being copied to installation at the moment. If these should be included in the distribution package, it would probably be necessary for the names of these Draw-EM commands would be encapsulated in some namespace, e.g., invocation via drawem <script> or mirtk drawem <script> (luckily the latter wouldn't clash with already existing mirtk draw-em binary whose source is in the tools/ folder).

@schuhschuh schuhschuh changed the title Option to use system ANTs / N4 installation Make DrawEM distribution package friendly Jan 4, 2021
@schuhschuh
Copy link
Member Author

schuhschuh commented Jan 4, 2021

On an additional note, MIRTK extension packages such as Draw-EM can be build out of MIRTK source tree. Meaning, one can first build and install MIRTK with MODULE_DrawEM=OFF (default), and then separately clone and build this DrawEM repository. The FindMIRTK.cmake module included should find the previously installed MIRTK. This would allow for distributions to create separate distribution packages for these, which I would recommend (e.g., mirtk, mirtk-drawem).

@lheckemann
Copy link

Regarding N4: how is DrawEM's N4 materially different from ANTs's? Does it even need to exist?

Data dependencies: yes, the data dependencies issue is the next one I ran into — I think the ideal solution here in principle would be for cmake to allow "substituting" ExternalProject sources. That way, no additional work would be necessary on the DrawEM side (and this problem would be solved for all uses of ExternalProject).

Out-of-source-tree build: I didn't realise this! That sounds like a much better solution than bundling everything in with mirtk itself.

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

No branches or pull requests

3 participants