Task #12898 (new)
Opened 9 years ago
Last modified 8 years ago
Extend Bio-Formats Macro Extensions to extract Channel name,etc.
Reported by: | bramalingam | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | Unscheduled |
Component: | Bio-Formats | Version: | 5.1.1 |
Keywords: | imagej, external | Cc: | D.N.Mason@… |
Resources: | n.a. | Referenced By: | n.a. |
References: | n.a. | Remaining Time: | n.a. |
Sprint: | n.a. |
Description
Change History (6)
comment:1 Changed 9 years ago by mlinkert
- Milestone changed from Unscheduled to 5.2.0-m1
comment:2 Changed 9 years ago by mlinkert
- Keywords imagej external added
comment:3 Changed 9 years ago by mlinkert
comment:4 Changed 9 years ago by jamoore
- Milestone changed from 5.2.0 to B-F-5.2.0
Splitting due to milestone decoupling.
comment:5 Changed 8 years ago by mlinkert
- Owner mlinkert deleted
As noted above, my initial long-term thinking for this was to have https://github.com/openmicroscopy/bioformats/blob/develop/components/bio-formats-plugins/src/loci/plugins/macro/LociFunctions.java generated by template, just like we do for MetadataStore/MetadataRetrieve?/etc. It may be easier to make a new class that is just the MetadataRetrieve?-wrapping methods generated from a template, and update LociFunctions? to extend that and keep all of the non-MetadataRetrieve?-wrapping methods (so LociFunctions? remains the class to update when something needs to be deprecated or otherwise maintained for backwards compatibility). If anyone has a better idea, feel free to explore that instead, but it seems best to avoid adding a few new methods here and there whenever we get a request.
Possibly ties in with https://trello.com/c/c3H2HYzm/51-add-more-well-commented-examples for documenting new macro functions.
comment:6 Changed 8 years ago by sbesson
- Milestone changed from B-F-5.2.0 to Unscheduled
Might be worth seeing if it makes sense to autogenerate new macro extension methods, so that the macro API more closely matches MetadataRetrieve?. Adding just getChannelName(...) on its own is easy enough, but I'm starting to worry that we're going to wind up with two divergent metadata APIs.