Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content
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

[RFE] - New Zeiss CZI DetectorType #164

Open
jdunhamvrtx opened this issue Jul 8, 2022 · 4 comments
Open

[RFE] - New Zeiss CZI DetectorType #164

jdunhamvrtx opened this issue Jul 8, 2022 · 4 comments
Labels
enhancement New feature or request

Comments

@jdunhamvrtx
Copy link

Hi @bioformats,

Just a small enhancement request. Could you add GaAsP-PMT' to the DetectorType list? The relevent error is below.

WARN l.enums.handlers.DetectorTypeEnumHandler - Unknown DetectorType value 'GaAsP-PMT' will be stored as "Other"

-J

@dgault dgault added the enhancement New feature or request label Jul 8, 2022
@dgault
Copy link
Member

dgault commented Jul 8, 2022

Hi @jdunhamvrtx, thank you for raising the issue, I have tagged this as an enhancement request. For now the warning message itself can be ignored, while the OME-XML will have the Detector listed as Other, the original value of GaAsP-PMT should remain present in the original metadata and can still be accessed if required.

@jdunhamvrtx
Copy link
Author

Hey @dgault

Yep - this is mainly for completeness. We are creating file manifests and we also import the data into OMERO so having downstream metadata be accurate is useful but not a priority for us by any means.

Is there a particular reason for the enum type and not just an implicit trust in the field value?

@melissalinkert
Copy link
Member

Using enums for most of the Type values (Detector, Microscope, etc.), Correction and Immersion on Objective, and other instrument/experiment metadata is a design decision that dates back to the original 2003 OME schema. The intention was to standardize around a limited and predictable vocabulary. While we've discussed relaxing certain enums in the past (https://trello.com/c/zKLdSC6n/114-enumeration-flexibility), we're unlikely to switch to using free-form text for these values in the foreseeable future. At this point, that's a major schema change with impact across the whole OME ecosystem.

Adding values to the existing enums is a relatively minor change that we could include with the next set of schema changes. We have other candidates for enum expansion from the past few years, in particular https://trello.com/c/FxSUHfGp/273-add-more-model-enum-values and https://trello.com/c/Ds0zwZcF/458-add-airyscan-detector-type.

Moving this issue to https://github.com/ome/ome-model, since that's where schema work happens. Bio-Formats just uses the enums defined by the schema, so this isn't a something that would be changed in Bio-Formats directly.

@melissalinkert melissalinkert transferred this issue from ome/bioformats Jul 14, 2022
@imagesc-bot
Copy link

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/follow-up-question-for-detector-type-metadata-of-czi-file/88905/2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants