Difference between revisions of "ITKv4 Migration plan"
From Slicer Wiki
| Line 12: | Line 12: | ||
** Associated command line module will be built as executable only. Indeed having both ITKv3 and ITKv4 in the same process will most likely result in some weird symbol clash. | ** Associated command line module will be built as executable only. Indeed having both ITKv3 and ITKv4 in the same process will most likely result in some weird symbol clash. | ||
| − | == Questions === | + | === Questions === |
| − | * Should each extension depending on ITKv4 download and build its own copy of ITKv4 or should Slicer build and expose both ITKv3 and ITKv4 ? | + | * Should each extension depending on ITKv4 download and build its own copy of ITKv4 or should Slicer build and expose both ITKv3 and ITKv4 ? |
== Custom MetaIO in SlicerITK == | == Custom MetaIO in SlicerITK == | ||
Revision as of 21:26, 28 July 2011
Home < ITKv4 Migration planOverview
This document, created following the NAMIC Engineering TCon of July 28th [1], discuss the element that should be considered before transitioning Slicer to ITKv4.
Current consensus
- Slicer RSNA will be built against ITKv3
- External module requiring ITKv4 will be linker statically against ITKv4
- Associated command line module will be built as executable only. Indeed having both ITKv3 and ITKv4 in the same process will most likely result in some weird symbol clash.
Questions
- Should each extension depending on ITKv4 download and build its own copy of ITKv4 or should Slicer build and expose both ITKv3 and ITKv4 ?
Custom MetaIO in SlicerITK
- To minimize memory usage and increase efficiency of Command line module execution, itkImageFileReader.txx in SlicerITK has been patched. See https://github.com/Slicer/ITK/commit/8c73dc57e4ae67328ff8e44934b72fd4cc5d4dd3
- Bill mentioned it should be possible to avoid patching SlicerITK by creating a custom Factory / plugins.
- From Bradley Lowekamp - ITK mailing list - Sun, Jul 17, 2011 at 11:33 AM subject Re: [Insight-developers] ITK 3 tag to use with slicer? Fwd: Slicer release schedule
Stephen, If I understand this change correctly, this patch allows the usage of a buffer allocated by the ImageIO to be passed all the way to the Image class if all the types match up. The is accomplished by adding the following methods: ImageIO::CanUseOwnBuffer, ImageIO::ReadUsingOwnBuffer() and ImageIO::GetOwnBuffer. I assume that this change is for the MemoryImageFileReader that is used with Slicer. ( can see how this could be quite advantageous ( and also the potential for scary alias when combined with InPlace filters ). But as not one single ITK ImageIO has support for these methods. I'd like to question if they should be brought into the ITK main repo, as they don't appear to currently provide any benefit to ITK and only complicate as already complicated interface to the ImageIO. If these changes are desired in ITK, then I would strongly encourage better documentation for the new methods in ImageIO, to enable new developers with add this feature to ImageIO classes. Brad
==
