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 <[email protected]>
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" <[email protected]> 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 <[email protected]>
>> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
