+1

Yes.

@kislinsk/@kalali Is this bug also solved due to your fix of T27386?

Ok. @kalali Thank you very much for the clarification.

Do I really need to reinit to the segmentation image or am I able to use the segmentation tools if I reinit to the reference image?

Now I understand, thanks. The actual issue is not really related to segmentations in the first place but to the image navigator / world geometry. I guess the logic to limit the time slider (world geometry?) just counts the time steps of the selected data without taking other data into account that may have multiple time steps in the same time range. I do not know if this is easy to fix as both scenarios are valid. In terms of modifying segmentations it is pretty bad, but in case you want to focus on or inspect a certain data and reinit to it it would be very confusing to have a different number of timesteps in the slider than the data actually has.

Well, to be precise: It is not possible to have a static segmentation on a 4D image, reinit it and show another timestep than 0. Is this intended?
What is the workflow for inspecting a 4D image at timestep t != 0 in order to segment something? From what I experience, the user has to initialize the view to the 4D image (not the segmentation) and then change the timestep to the desired one.

Hm, is there a misunderstanding that @kalali thought a static segmentation of a dynamic image covers only a single timestep instead of the whole time range of the dynamic image with a single timestep? So my first guess is that this task is somewhat invalid. Disussing in general if a reinit should also reset the scene timestep to 0 is something we could address separately I guess.

@kalali Could elaborate on the question? I am somewhat drawing a blank what the question or change proposal now is.

In T27509#204970, @floca wrote:

I would propose the following policy:

1. All tools per default work only on the respective time step of the reference data and the segmentation, that are indicated by the currently selected time point (SliceNavigator). So this is general and independent from the fact if it is a 3D or a 4D segmentation. This is the same behavior like the interactive tools and does not break user expectations.
2. It is up to the specific tool (must be discussed there) if for 4D reference images others then the current time step of the reference data step should be used. Per se, I would say no.
3. It is up to the specific (3D) tool to allow the altering of more then the current segmentation time step (if the segmentation is 4D). If one wants such a feature I would add e.g. a check box to the tool like "confirm for all time steps".

Just as a remark: I am getting the exact same error, if I want to load a dcm image from a folder that contains more than one image. Those images originate from a cadaver study which means that before acquisiton most of the patient input data is left blank (study,series etc). If I put the files into separate folders, they are loaded correctly.

Thanks for the remarks and solution options.

Update: the root of many cases of this problem are the same as discussed in T27568: US 2D image cannot be read: invalid tilt information. In the mean while some cases (as OT-MONO2-8-colon) work now (due to fixes of T27321 and T27322) others (like CR-MONO1-10-chest-*) still do not work. The reasons and solutions are the same as described in T27568.

Should discuss in the MITK meeting about the solutions.

I guessed so to. For me it is not clear where to query the correct current temp path?

Solution is probably QWebEngineProfile::SetCachePath() and SetPersistentStoragePath(): https://stackoverflow.com/questions/37774910/how-to-prevent-creating-strange-folders-while-using-qwebengineview

The problem of different class types / image types is also the source for the bug mentioned in T27386: [MultiLabel] Workbench crashes if autocrop is used with opened plugin view without patient image.
@floca mentioned to completely remove the autocrop-action from the context menu (at least for the multilabel segmentation) because it is not clear what to expect. Multilabel segmentations offer different possibilities for cropping and this could be handled inside the multilabel segmentation view.
That's also an option I see for the issue mentioned in 2.

@kahl I can confirm your workflow for the ITK NrrdImageIO reader.
@kislinsk I can also confirm that autocrop does not alter the name if used on a binary segmentation.

@nolden: Do you have a clue? Was it missed when cleaning up or is it there on purpose and should be corrected?

I would propose the following policy:

1. All tools per default work only on the respective time step of the reference data and the segmentation, that are indicated by the currently selected time point (SliceNavigator). So this is general and independent from the fact if it is a 3D or a 4D segmentation. This is the same behavior like the interactive tools and does not break user expectations.
2. It is up to the specific tool (must be discussed there) if for 4D reference images others then the current time step of the reference data step should be used. Per se, I would say no.
3. It is up to the specific (3D) tool to allow the altering of more then the current segmentation time step (if the segmentation is 4D). If one wants such a feature I would add e.g. a check box to the tool like "confirm for all time steps".

Looked into the topics. Following comments: