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 #575 (closed task: invalid)

Opened 2011-06-07T16:22:48-05:00

Last modified 2011-06-22T09:56:35-05:00

IJ1 can kill stack

Reported by: bdezonia Owned by: bdezonia
Priority: major Milestone: biweekly-2011: Jun-20 to Jul-01
Component: Legacy Compatibility Version:
Severity: serious Keywords:
Cc: Blocked By:


There is code in IJ1::ImagePlus::setProcessor2() which can delete an ImageStack if it contains a single plane. Not sure whether it arises in practice.

To be safe make sure various places (such as the legacy layer) check for this condition and act appropriately.

Note I tried doing this quickly in the legacy layer and did not get good results. Must come up with test case where the stack does go away and show we can support it.

Change History

comment:1 Changed 2011-06-21T15:55:19-05:00 by bdezonia

  • Status changed from new to closed
  • Resolution set to invalid

Further debugging shows this to not be something to worry about. In ImagePlus::setProcessor() the stack is killed if the current stack size <= 1. But then calling ImagePlus::getStack() hatches a new stack of one slice.

It is possible that before a call to getStack() the internal stack is null as the result of a setProcessor(ip) call. This could only affect the legacy layer if one creates an ImagePlus with a one slice stack. Then call setProcessor() on the ImagePlus passing an ImageProcessor with a different data array backing it. Then manipulate the original stack and expect our changes have been propagated to the ImagePlus. The legacy layer avoids this by calling getStack() frequently and never calling setProcessor().

Hatched a case in LegacyUtilsTest class that shows IJ1's behavior.

comment:2 Changed 2011-06-22T09:56:35-05:00 by bdezonia

  • Milestone changed from imagej-2.0-final to biweekly-2011: Jun-20 to Jul-01