Ticket #531 (closed enhancement: moved)

Opened 6 years ago

Last modified 5 years ago

Legacy layer has limitations in regard to plugins that change data types

Reported by: bdezonia Owned by: bdezonia
Priority: major Milestone: imagej-2.0.0
Component: Legacy Compatibility Version:
Severity: serious Keywords:
Cc: Blocked By:
Blocking: #1011

Description

Open Bridge sample. Change type to 12-bit. Find Edges. File Revert. Data is restored but type is still 12-bit.

Change History

comment:1 Changed 6 years ago by bdezonia

  • Status changed from new to accepted

partially fixed. reversion works but old 12-bit dataset left on screen also.

comment:2 Changed 6 years ago by bdezonia

undid partial fix. this problem will need to be addressed when we handle full support of data translation for IJ2 types that are not directly compatible with IJ1. See related ticket #528.

comment:3 Changed 6 years ago by bdezonia

from 528:

Right now what happens when you do the command sequence given is that the reverted file is still a 12-bit Dataset although pixel values are correct. This is because the harmonizer sets the pixel data by value upon return from plugin run and it does not know to change the type back. Will have to think what the best behavior is.

Code changes have to take place in LegacyPlugin (pre and post plugin harmonization) and the DatasetHarmonizer.

comment:4 Changed 6 years ago by bdezonia

Fixed. I suspect its possible to have a similar problem with 12-bit going the other direction. I.e. take a 16-bit image, convert to 12, run legacy plugin, revert. Will test further for that issue/

comment:5 Changed 6 years ago by bdezonia

Indeed 16 (M51 galaxy) to 12 (Image::Type) and back (File::Revert) shows the same problem. The Dataset thinks its 12-bit when it should be back to 16 bit.

comment:6 Changed 6 years ago by bdezonia

In the legacy layer the 12-bit Dataset is shadowed by a 16-bit ImagePlus. Revert loads the 16-bit ImagePlus with original data. The legacy layer has no idea that any type change is expected. The data is just copied back and clamped.

This issue would be present for 1-bit as well I think.

This bug shows that we need a pure IJ2 Revert plugin. But it shows a weakness in the support of IJ2 types that do not map directly to IJ1.

comment:7 Changed 6 years ago by bdezonia

This weakness seems only to be that IJ2 can't always detect a type change from a LegacyPlugin for those types in IJ2 that are not directly representable. So also think of a signed 8 bit Dataset that gets represented as a 32 bit float ImagePlus. Then if you run a Legacy plugin that expects to return a float32 ImagePlus the legacy layer will not see that the type has changed and it will copy back to signed 8-bit values clamping.

So any type that is not directly representable (signed integral types, non byte boundary types, 64 bit types, 32 bit unsigned) cannot detect changes an IJ1 plugin could make that would try to change the type of the output data to something that matches the currently mapped IJ1 type.

comment:8 Changed 6 years ago by bdezonia

  • Summary changed from File Revert does not undo everything to Legacy layer has limitations in regard to plugins that change data types
  • Type changed from defect to enhancement
  • Milestone changed from biweekly-2011: May-23 to Jun-03 to imagej-2.0-final

comment:9 Changed 6 years ago by curtis

  • Blocking 1011 added

comment:10 Changed 5 years ago by bdezonia

Note: 1-bit is now unaffected by this problem. During harmonization isBinary() is checked and handled.

comment:10 Changed 3 years ago by curtis

  • Status changed from accepted to closed
  • Resolution set to moved
Note: See TracTickets for help on using tickets.