On 29 January 2015 at 16:40, Sascha Zelzer <s.zel...@dkfz-heidelberg.de>
wrote:
> Hi,
>
> there is no recommended way for wrapping ITK reader, especially since
> MITK is doing that already. Why would you want to wrap the ITK Nifti
> reader again? (maybe there is another approach).
>
Because we have a custom Nifti reader, not the ITK one, and not the MITK
one.
> In general, you would create our own Nifti reader, associate it with the
> mime-type name mitk::IOMimeTypes::NIFTI_MIMETYPE_NAME() and register it
> with a higher ranking the MITK's one (which defaults to 0).
>
So, it means that I need to duplicate mitk::ItkImageIO.cpp in our codebase,
as it is internal in MITK?
I am evaluating this solution now, but it seems a bit ugly.
Miklos
>
> Best,
> Sascha
>
> On 01/29/2015 05:11 PM, Miklos Espak wrote:
> > Hi,
> >
> > we have a custom NIfTI reader, and MITK also has one. As I see, the
> > activator of the the MitkCore module goes through the ImageIOs
> > registered by ITK, skips the nifti one and registers MITK's own version.
> >
> > What shall I do to replace the MITK's nifti reader with ours?
> >
> > I tried to mock what's in the CoreActivator, but it uses
> > mitk::ItkImageIO that is an internal class.
> >
> > Is there a recommended way of wrapping ITK image io-s?
> >
> > Cheers,
> > Miklos
> >
>
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mitk-users
