Page MenuHomePhabricator
Create Task
Maniphest T24286

Image/PeakImage conflict when loading MITK sessions due to Diffusion Core
Closed, ResolvedPublic
Actions

Description

The problem occures on the current master when loading MITK sessions that contain images and these images fullfill the following conditions:

  • Loaded via itk file reader (so e.g. nrrd, nifti)
  • Image is detected as suitable by the PeakImage reader. (so o.a. are 3D+t, where t = 3*i; i=1,...,inf).

These images are always loaded as peak images now, because when loading the MITK session the reader is automatically selected that has the highest priorities. Due to recent changes the PeakImage reader has the highest priority.

Loading the images as peak images breaks a lot of plugins (e.g CEST, perfusion or registration plugins). Reason: The plugins use predicates the check with mitkNodePredicateDataType if the node containes mitk::Image. The class name now is mitk::PeakImage, therefore the checks fail and the reloaded session cannot be used any more.
Due to the fact that the module DiffusionCore and its autoload module is always build, you cannot prevent the peak read to be there (even if you don't want Diffusion).

Related Objects

Event Timeline

floca created this task.Feb 19 2018, 1:51 PM
floca added a comment.Feb 19 2018, 2:04 PM

If brainstormed of possible ways to treat the problem (not a comprehensive/closed list)

  1. Possibility to really deactivate diffusion, if not needed. Comment: Dont like this approach for this problem. Nothing more than a quick workarround hack. We should have a code base that realy works together, so that we could and deploy everythin together
  2. Deprioritize the peak read again
  3. We introduce a CEST reader for "itk formats" that checks for the CEST properties and is even higher prioritize. Comment: Only helps for CEST images but not for all other domains. e.g. perfusion.
  4. Get the peak image reader more specific. (So less false positives)
  5. Combination of 2 and 4. The normal peak image reader has low priority. The peak image writer decorates the nrrd/nifti images with a custom tag that identifies the images as peak images. We have a high priority peak image read that is very specific (only triggers if the custom tag is there). This way peak images could be reloaded without the need of a reader selection, but there would be no interference with other images/domains.

If possible, it think I like 4 best and 5 second, so far.

floca added a comment.Feb 19 2018, 4:13 PM

I assume diffusion SHImages can cause a simelar problem because their mime type detection is also not very specific (a bit more specific then peak, but not much).

floca mentioned this in rMITK6973c5e8e5c9: Workarround for T24286.Feb 27 2018, 9:25 AM
floca edited projects, added MITK (2018-04); removed MITK.Mar 2 2018, 11:25 AM

If we cannot solve this whole issue for good till the release, I would propose to at least minimize the priorities of diffiusion again, to get the regression away.

Like in rMITK6973c5e8e5c9: Workarround for T24286.

neher added a comment.Mar 2 2018, 1:54 PM

I will solve it. In ten days.

• groehl added a subscriber: • groehl.Mar 8 2018, 11:44 AM

We also have creashes with nrrd images containing optical properties (these are basically stored as 4D/3D+t images without any specific typing and the rule described above also comes into action). In our case, if using a commandline structure, images are imported as PeakImages per default causing crashes.

Thanks @floca for pointing out workarounds for this.

neher added a comment.Mar 13 2018, 4:47 PM

Pushed new branch T24286-ReaderPriorities.

neher mentioned this in rMITK2a7ec3cc4b9c: Merge branch 'T24286-ReaderPriorities'.Mar 13 2018, 4:48 PM
neher closed this task as Resolved.Mar 13 2018, 4:48 PM
neher claimed this task.

Reduced priorities

neher reopened this task as Open.Mar 13 2018, 6:24 PM

Strangely, now AppliesTo of the PeakImage and ShImage mimetypes seems to be not evaluated anymore. While the first option when loading non-peak images now always is the default itk image reader, the Peak and ShImage reader is always offered even when AppliesTo would return false.

floca added a subscriber: hentsch.Mar 13 2018, 7:36 PM
In T24286#125107, @neher wrote:

Strangely, now AppliesTo of the PeakImage and ShImage mimetypes seems to be not evaluated anymore. While the first option when loading non-peak images now always is the default itk image reader, the Peak and ShImage reader is always offered even when AppliesTo would return false.

Hm, this somehow rings a bell. @hentsch hadn't you got a similar effect with RT data readers? I have something unspecific in mind with "AppliesTo" being irgnored etc. But maybe I am confusing things.

floca added a comment.Mar 13 2018, 7:50 PM

@neher : Maybe it has something to do with the priority "-1"?!? I have checked it in my build with a quickfix (no explicit priority setting at all). In my build I only get the Peak images when I have data with "modulo 3" time steps (which should be the expected behavior). For other 3D+t images I get no additional options.

hentsch added a comment.Mar 14 2018, 9:19 AM

It was at least similar behavior (but in my case DICOM):

  • I implemented specific DICOMRT readers and didn't want the usual dicom readers to apply.

I had to change the AppliesTo method of dicom as you can see here: https://phabricator.mitk.org/rMITK21ab4ee366bdbbd548c1f5c53d85706802dac556#change-984W74Vdseba

kislinsk triaged this task as Normal priority.Mar 19 2018, 10:38 AM
kislinsk moved this task from Backlog to MITK Diffusion on the MITK (2018-04) board.
neher mentioned this in rMITK70af7c570994: Merge branch 'T24286-ReaderPriorities'.Mar 19 2018, 11:01 AM
neher added a comment.Mar 19 2018, 11:02 AM

@floca Removing the -1 and simply setting no priorities for the two datatypes seems to work.

neher closed this task as Resolved.Mar 19 2018, 11:39 AM
MITK · MIC · IMSY · DKFZ