Hi Aurélien, sorry for the delay, we were somewhat occupied with our phabricator migration. Assuming this is still relevant to you:
It kind of depends on what your desired result is. If you only want your reader to be the default choice (and thus being selected if no dialog is opened, such as when running from the command line or loading scene files) you can register yours with a higher service ranking (see [1] for an example). If you want to get rid of the other reader altogether and thus have no dialog show at all, it seems that is currently not possible, I have opened a feature request for it where we can discuss a couple of different ways to go about this [2]. It would be great if you could weigh in. Best, Caspar [1] https://phabricator.mitk.org/diffusion/MITK/browse/master/Modules/DiffusionImaging/DiffusionIO/mitkDiffusionModuleActivator.cpp;9ef2563eac399aa063bc1965e71f8e83442344eb$48 [2] https://phabricator.mitk.org/T19853 -----Ursprüngliche Nachricht----- Von: Aurélien Labrosse [mailto:aurel...@pollen-metrology.com] Gesendet: Freitag, 22. Juli 2016 11:09 An: mitk-users@lists.sourceforge.net Betreff: [mitk-users] Unregistration of Mitk ITK image reader wrapper 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.desc context->ription=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
