I see, thanks. The approach proposed by Caspar is probably the most
straight forward.
And we could export the mitk::ItkImageIO class to better support such
use cases.
Best,
Sascha
On 01/30/2015 11:37 AM, Miklos Espak wrote:
Yes.
So, we have DRCAnalyzeImageIO3160 that derives from AnalyzeImageIO3160
that derives from ImageIOBase.
And we have NiftiImageIO3201 that derives from NiftiImageIO3201 that
derives from ImageIOBase.
And we have a NiftkItkImageFileReader that derives from
mitk::ItkImageFileReader (now deprecated) and selects the right io
base to use if there is any applicable. The NiftkItkImageFileReader is
registered from the NifTKItkImageFileIOFactory constructor by this call:
this->RegisterOverride("mitkIOAdapter",
"mitkNifTKItkImageFileReader",
"NifTK specific ITK based image IO",
1,
itk::CreateObjectFunction<IOAdapter<NifTKItkImageFileReader> >::New());
The code is executed but NiftkItkImageFileReader is never instantiated.
As my limited understanding, instead of registering your reader to the
ITK object factories, now you should register them to
mitk::FileReaderRegistry. So, I tried to wrap our io base classes so
that I can add them to the registry.
The MitkCore activator does the same. It goes through the image io-s
that are already registered. The problem is that our readers are not
available by the time it does that. So, I wanted to repeat the same
process when our core module is loaded.
I check what Caspar suggested as well.
Cheers,
Miklos
On 29 January 2015 at 21:17, Sascha Zelzer
<s.zel...@dkfz-heidelberg.de <mailto:s.zel...@dkfz-heidelberg.de>> wrote:
Sure. Why do you want to replicate mitk::ItkImageIO then? Does
your reader derive from itk::ImageIOBase?
On 01/29/2015 09:26 PM, Miklos Espak wrote:
I want our reader. Not the ITK one and not the MITK one.
Just like you guys replaced the ITK reader to have your own, I
want the same, just with ours.
On 29 Jan 2015 17:17, "Sascha Zelzer"
<s.zel...@dkfz-heidelberg.de
<mailto:s.zel...@dkfz-heidelberg.de>> wrote:
I don't understand. You are saying you do have a custom Nifti
reader. But then you would still like to wrap the ITK one?
On 01/29/2015 06:02 PM, Miklos Espak wrote:
On 29 January 2015 at 16:40, Sascha Zelzer
<s.zel...@dkfz-heidelberg.de
<mailto: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
