Ticket #552 (closed task: wontfix)
Opened 2011-05-31T15:31:57-05:00
Last modified 2014-08-20T11:53:09-05:00
Make it possible to pass a ImgFactory to ImageTranslator::createDataset()
| Reported by: | bdezonia | Owned by: | bdezonia |
|---|---|---|---|
| Priority: | major | Milestone: | imagej2-b8-analysis |
| Component: | Legacy Compatibility | Version: | |
| Severity: | serious | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | #1011 |
Description
RIght now ImageTranslator::createDataset() always makes a PlanarAccess backed Dataset. Allow user to specify a different kind of factory. Only makeExactDataset() when have PlanarAccess.
Change History
comment:1 Changed 2011-06-21T14:34:33-05:00 by bdezonia
comment:2 Changed 2011-10-05T11:37:01-05:00 by bdezonia
Above text is somewhat stale due to changes in architecture. This comment has the relevant info.
In 9d915a1b9d8e5863d9b4d89ea8098c1949c2ac6f made a DatasetFactory::create() signature that can take any kind of ImgFactory. Allows us to create non-planar images.
Still need to incorporate this into the legacy layer such that the translators can createDisplay()'s which are not planar backed structures.
comment:3 Changed 2011-11-09T13:07:22-06:00 by bdezonia
- Milestone changed from imagej-2.0-beta1 to imagej-2.0-beta2
Started looking into this further. There is a fair amount of entanglement caused by the assumption that all datasets are PlanarImg backed. Allowing the type of factory to be passed around requires LegacyService and LegacyInjector to care about this which they shouldn't.
I think the most straightforward fix is to have LegacyImageMap's registerLegacyImage() accept an ImageTranslator as a parameter. Thus is can be switched by API consumer (except for LegacyService which is a minor problem).
The ImageTranslator would own an ImgFactory and know how to make the correct kind of display/dataset. The Dataset creation signatures have to change to take a factory too (current one is insufficent). So this requires some API change in the data model.
Still its not a compatibility issue and poses no showstopper bugs. So I am pushing out of beta 1.
comment:4 Changed 2011-11-09T13:17:46-06:00 by bdezonia
I forgot to add that we should make it so that LegacyPlugin takes a factory or ImageTranslator as a constructor parameter (or via a setter). The default behavior would be to make PlanarImgs while other constructor/translaotr can make other types. Then for the single run of a LegacyPlugin all displays created would be backed by the given factory/translator.
comment:6 Changed 2012-05-14T09:55:16-05:00 by bdezonia
- Milestone changed from imagej-2.0.0-beta3 to imagej-2.0.0-beta4
comment:7 Changed 2012-09-10T09:10:49-05:00 by bdezonia
- Milestone changed from imagej-2.0.0-beta4 to imagej-2.0.0-beta5
comment:8 Changed 2013-06-07T16:00:51-05:00 by bdezonia
- Milestone changed from imagej2-b7-ndim-data to imagej2-b8-analysis
comment:9 Changed 2014-08-20T11:53:09-05:00 by curtis
- Status changed from new to closed
- Resolution set to wontfix
I don't understand the need for this work. If the original image object is an ImageJ 1.x ImagePlus, we will wrap it as an ImageJ2 PlanarImg. If the original image object is an ImageJ2 object which is not planar, we still want to wrap it a virtual ImagePlus. Either way, we now have successfully adapted and linked the data structures. It is not clear why we would need an automated factory-based mechanism to generalize creation of ImageJ2 data objects from ImageJ 1.x structures beyond that.
Will also need to change Dataset::create() to take a factory. Could maintain current signature by having it always pass a PlanarImg factory to the general case signature.