Difference between revisions of "ITKv4 Migration plan"

From Slicer Wiki
Jump to: navigation, search
Line 40: Line 40:
 
Brad
 
Brad
 
</pre>
 
</pre>
 +
 +
* In the na-mic tcon it was discussed that nrrd and nifti readers also perform the memcpy since the native libraries perform the Information and Read steps in a single API call.  Therefor if the feature existed at the ITK level, then several readers could take advantage of it.

Revision as of 21:49, 28 July 2011

Home < ITKv4 Migration plan

Back to Slicer

Overview

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

  • 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
  • In the na-mic tcon it was discussed that nrrd and nifti readers also perform the memcpy since the native libraries perform the Information and Read steps in a single API call. Therefor if the feature existed at the ITK level, then several readers could take advantage of it.