New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
ctrueden opened this Issue Aug 20, 2014 · 0 comments

Comments

Projects
None yet
2 participants
@ctrueden
Member

ctrueden commented Aug 20, 2014

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

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.

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

Migrated-From: http://trac.imagej.net/ticket/531

@hinerm hinerm added this to the m1 milestone Mar 23, 2015

@hinerm hinerm self-assigned this Mar 23, 2015

@hinerm hinerm added the bug label Mar 23, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment