NOTICE! This is a static HTML version of a legacy ImageJ Trac ticket.

The ImageJ project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Ticket #613 (closed defect: fixed)

Opened 2011-06-16T15:09:09-05:00

Last modified 2011-06-21T10:51:32-05:00

IJ1 forgets active image

Reported by: bdezonia Owned by: bdezonia
Priority: major Milestone: biweekly-2011: Jun-06 to Jun-17
Component: Legacy Compatibility Version:
Severity: serious Keywords:
Cc: Blocked By:
Blocking:

Description

Open Cardio
Convert to 8 bit unsigned
Run Image :: Stacks :: Stack To Images

Success

Close the three hatched images
Select the Cardio Dataset window
Run Image :: Stacks :: Stack To Images

IJ1 complains that it doesn't have a stack

Change History

comment:1 Changed 2011-06-16T15:22:55-05:00 by bdezonia

somewhat different behavior if you open ome-tiff 4d series.

run Stack to Images : works
run again : complains no stack
run again : works
run again : complains
etc.

comment:2 Changed 2011-06-16T16:27:48-05:00 by bdezonia

DisplayManager::setActiveDisplay() is getting set to null when you close the images. Nothing is setting the active display to he window remaining.

Even when you select the remaining window setActiveDisplay() is not always called.

Need someone to listen to DisplayDeletedEvents and set the active display. Although there is a PluginPreprocessor that should always track (or set) the active display.

Think about this some more. Perhaps discuss with others.

comment:3 Changed 2011-06-16T16:36:15-05:00 by bdezonia

So create a new hyperstack sets active display
Stack to images sets active display to one of the hatched images
Close the hatched images. Active display is not set to anything
Stack to images thinks nothing is open because active display is null
It complains which grabs focus.
Upon closure of this dialog the focus goes to the only displayed image
Since active display is not null Stack to Images will run fine.
Then back in the loop.

comment:4 Changed 2011-06-16T16:54:46-05:00 by bdezonia

Note that even if we correctly track active Dataset I have seen (with debugger which changes event stream) IJ1 throw an exception. Maybe repeated failures throw it in an unknown state.

comment:5 Changed 2011-06-17T13:53:54-05:00 by bdezonia

Testing now with ef12a8558b9a528bc23402c84e4cf48cfd27a825. Can never run the plugin a second time successfully. IJ1 keeps throwing exceptions once you try to run the plugin with a null active dataset. Even if after that you have correctly activated the window IJ1 errors out.

Maybe the issue here is that the first successful run of the command removes the original ImagePlus from data structures internal to IJ1 (since the IJ1 command does delete the original window though not in IJ2). Thus when we try Stack To Images again we pass our parallel ImagePlus but IJ1 doesn't know what it is. And thus some exception gets thrown.

The real bug fix might be to delete the existing dataset and it's view at conclusion of plugin call. See what IJ1 is doing and capture via legacy layer and code hacking.

comment:6 Changed 2011-06-17T15:19:51-05:00 by bdezonia

My last note is correct. I am platying with LegacyManager and code hacking of ImageWindow::close(). Harmonization should not include ImagePluses that were closed. In fact the LegacyImageMap needs to forget about deleted ImagePluses. Ideally we'd propagate the delete back to IJ2 and close the DatasetView. I have some more notes to draw on after the weekend.

comment:7 Changed 2011-06-21T10:51:32-05:00 by bdezonia

  • Status changed from new to closed
  • Resolution set to fixed
  • Milestone changed from biweekly-2011: Jun-20 to Jul-01 to biweekly-2011: Jun-06 to Jun-17

The fix is to have LegacyManager track ImageWindow::close(). If it is called from an IJ1 plugin we should close the associated IJ2 Display. This will generate a DatasetDeleted (or soon a DisplayDeleted) event that will be caught by LegacyImageMap. The Datset will get unregistered and the associated ImagePlus removed and freed too.

I have built skeleton code in ImageWindowMethods::close() to do whats necessary. I have hatched ticket #624 associated with fixing that method when appropriate. Closing this ticket.