Hi, in fact, there are two different ways of achieving this:
1. Register a CustomMimeType service [1] (use some custom name like "application/x-pollen-tiff") and associate the set of TIFF extensions with it that you want to use. The important part is to use a non-default service ranking when registering your mime type (e.g. > 0). Now when the system tries to match a reader to a TIFF file, it uses your custom mime type name, which is not associated with any MITK/ITK related reader. Register your own TIFF reader using your custom mime type name in its service properties and you should be all set. 2. You can "filter" service registrations by using service hooks [2]. This is a more generic solution but requires careful implementation and more knowledge about how CppMicroServices works. It allows you to pro-actively filter the list of services other clients can see, e.g. suppress a specific reader service by filtering it out. [1] http://docs.mitk.org/2016.03/classmitk_1_1CustomMimeType.html [2] http://docs.mitk.org/2016.03/MicroServices_ServiceHooks.html On 08/10/2016 02:55 PM, Goch, Caspar Jonas wrote: > 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 ------------------------------------------------------------------------------ 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