Ticket #531 (closed enhancement: moved)
Opened 2011-05-20T14:06:21-05:00
Last modified 2012-05-03T10:05:13-05:00
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 2011-05-20T17:43:20-05:00 by bdezonia
- Status changed from new to accepted
comment:2 Changed 2011-05-24T13:16:14-05:00 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 2011-05-24T13:21:09-05:00 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 2011-05-26T14:26:14-05:00 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 2011-05-26T14:32:05-05:00 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 2011-05-26T14:43:02-05:00 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 2011-05-26T15:00:48-05:00 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 2011-05-26T15:24:52-05:00 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:10 Changed 2012-05-03T10:05:13-05:00 by bdezonia
Note: 1-bit is now unaffected by this problem. During harmonization isBinary() is checked and handled.
comment:10 Changed 2014-08-20T11:49:51-05:00 by curtis
- Status changed from accepted to closed
- Resolution set to moved
partially fixed. reversion works but old 12-bit dataset left on screen also.