imagej / imagej-legacy

ImageJ+ImageJ2 compatibility layer
https://imagej.net/libs/imagej-legacy
BSD 2-Clause "Simplified" License
16 stars 25 forks source link

Synchronization link broken by invalid StackWindow dimensions #282

Open hinerm opened 2 years ago

hinerm commented 2 years ago

When creating and showing an ImageJ2 dataset in Fiji we create and maintain a synchronized ImagePlus. After showing the image we trigger a DisplayUpdatedEvent which is intercepted by the LegacyImageMap. This triggers a rebuild of the ImagePlus.

If for some reason the ImagePlus and its displaying StackWindow do not agree in dimensionality, the StackWindow is rebuilt. This closes the current StackWindow and thus the corresponding ImageJ2 display is closed. However, although a StackWindow is created, the corresponding ImageJ2 display is not similarly rebuilt. So when the dimensionality of the display is later queried, the combinedInterval is empty and we get an appropriate exception:

image

Certainly this issue seems to arise due to bugs elsewhere, e.g. in the translation of the dataset to mismatched ImagePlus and StackWindow. However it also illustrates a chain of events for which ImageJ is designed to handle but breaks ImageJ2 synchronization.

I think the imagej-legacy fix is to insert a line after the StackWindow is rebuilt to refresh the corresponding ImageJ2 display with the new window.

hinerm commented 2 years ago

This issue is proving to be more complex than I realized.

First of all, legacyService.isSyncEnabled() is typically false it seems... making registerImage a no-op, but a synchronized display is still being created e.g. by the DisplayPostprocessor and a mapping still maintained such that unregisterImage works as expected.

Secondly, this problem only arises when a Dataset is synchronized with a CompositeImage. The ImagePlusCreator#optionalMakeComposite feels slightly aggressive as it just checks for the presence of Axes.CHANNEL, without caring if the size is 1. This may be perfectly reasonable, I'm not sure, but in any case the issue can be worked around by ensuring our openers do not create unnecessary length 1 channel axes.

It would be useful to test with a genuine multi-channel, multi-timepoint image to see if it opens without errors.