Open hinerm opened 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.
When creating and showing an ImageJ2 dataset in Fiji we create and maintain a synchronized
ImagePlus
. After showing the image we trigger aDisplayUpdatedEvent
which is intercepted by the LegacyImageMap. This triggers a rebuild of the ImagePlus.If for some reason the
ImagePlus
and its displayingStackWindow
do not agree in dimensionality, the StackWindow is rebuilt. This closes the currentStackWindow
and thus the corresponding ImageJ2 display is closed. However, although aStackWindow
is created, the corresponding ImageJ2 display is not similarly rebuilt. So when the dimensionality of the display is later queried, thecombinedInterval
is empty and we get an appropriate exception:Certainly this issue seems to arise due to bugs elsewhere, e.g. in the translation of the dataset to mismatched
ImagePlus
andStackWindow
. 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.