Hi,
if I understood correctly, you seem to think that "UngetService" would
unregister the referenced service, but that is not what it does. It
tells the registry that you are done "using" the service, after you "got
it" via a "GetService" call. This helps the internal registry to keep
track of the client currently using a particular service.
Unregistering a service that you didn't register yourself is not in the
spirit of the system and hence not directly supported.
Cheers,
Sascha
On 07/22/2016 11:09 AM, Aurélien Labrosse wrote:
Hello,
We need to implement a flexible TIFF reader with a delegation system
which will allow us to gather image metadata from themselves or from
companion files. We started to implement it in a module, and we
register it with a custom tiff mimetype.
Now when we open a TIFF image in Mitk, a dialog appears where we have
to choose between the Mitk/ITK tiff or our reader (which is the
expected behaviour if two readers are able to read the same mimetype).
How can we unregister() the Itk wrapped loader? We just want to use
our reader.
We tried to lookup and unregister the service :
[...]
std::vector<us::ServiceReference<mitk::IFileReader> > refs;
refs =
context->GetServiceReferences<mitk::IFileReader>("(org.mitk.IFileIO.description=ITK
TIFFImageIO)");
if (!refs.empty())
{
us::ServiceReference<mitk::IFileReader> tiffReaderServiceRef =
refs.front();
mitk::AbstractFileIOReader* tiffReader =
dynamic_cast<mitk::AbstractFileIOReader*>(context->GetService(tiffReaderServiceRef));
tiffReader->UnregisterService();
context->UngetService(tiffReaderServiceRef);
}
[...]
Unfortunatly, the UngetService() call does nothing since the
registration information is lost in the reader. After some digging, we
found that information loss occurs in
Modules\Core\src\IO\mitkItkImageIO.cpp, around line 42 :
[...]
ItkImageIO::ItkImageIO(const ItkImageIO& other)
: AbstractFileIO(other)
,
m_ImageIO(dynamic_cast<itk::ImageIOBase*>(other.m_ImageIO->Clone().GetPointer()))
{
[...]
So the solution we found is to cancel the wrapping of the ITK TIFF
reader as its already done for Nifti and GDCM images. Could the failed
unregistration considered as a bug or are we doing things bad? Anyway
a more elegant solution than just adding an exception would be great.
We can event work on a solution to fix the unregistration if its a bug.
Thanks for any clues!
Regards,
Aurélien Labrosse
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mitk-users
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mitk-users
