CZI: Invalid Detector Settings
This issue was discover via a QA report in QA-30888 and a sample file is availble in the same QA demonstrating the issue with Bio-Formats 6.9.0
The initial stack trace is from OMERO Server:
Parameters: {stacktrace=java.lang.RuntimeException: omero.ApiUsageException
serverStackTrace = "ome.conditions.ApiUsageException: Missing reference handler for Detector:LSM900(null) --> omero.model.DetectorSettings:0:3(ome.model.acquisition.DetectorSettings:Hash_6488207) reference.
at ome.formats.OMEROMetadataStore.updateReferences(OMEROMetadataStore.java:694)
at ome.services.blitz.impl.MetadataStoreI$5.doWork(MetadataStoreI.java:257)
Looking at the generated OME-XML for the sample file we have the following Instrument metadata and Detectors:
<Instrument ID="Instrument:0">
<Microscope Type="Inverted"/>
<Detector ID="Detector:Airyscan" Model="" Offset="0.0" Type="Other" Zoom="1.0"/>
<Detector ID="Detector:T-PMT" Model="" Offset="0.0" Type="Other" Zoom="1.0"/>
<Objective ID="Objective:1" Immersion="Water" LensNA="1.2" Model="C-Apochromat 40x/1.20 W Korr" NominalMagnification="40.0" WorkingDistance="280.0" WorkingDistanceUnit="µm"/>
Yet on Channel we are using a DetectorID which does not exist:
<Channel AcquisitionMode="Other" Color="-15924993" EmissionWavelength="751.0" EmissionWavelengthUnit="nm" ExcitationWavelength="506.0" ExcitationWavelengthUnit="nm" Fluor="FM 4-64#" ID="Channel:0:1" IlluminationType="Epifluorescence" Name="Fm464#-T1" SamplesPerPixel="1">
<DetectorSettings ID="Detector:LSM900"/>
<LightPath/>
Validating the OME-XML results in:
Validating OME-XML
cvc-identity-constraint.4.3: Key 'ImagePixelsChannelDetectorSettingsDetectorIDKeyRef' with value 'Detector:LSM900' not found for identity constraint of element 'OME'.
Error validating document: 1 errors found
#4318 also reports this issue, so QA 91491 should be tested as part of any fix.
See also QA 91521, although the QA says:
Name: error-on-init
Parameters: {stacktrace=Unable to instantiate object. for class omero.model.Microscope
at ome.formats.model.BlitzInstanceProvider.getInstance(BlitzInstanceProvider.java:72)
When I try to import it, I get:
Name: import-request-failure
Parameters: {stacktrace=java.lang.RuntimeException: omero.ApiUsageException
serverStackTrace = "ome.conditions.ApiUsageException: Missing reference handler for Detector:LSM980(null) -->
Also reported in #4330, so QA 91530 should be tested when this is fixed. As discussed separately with @sbesson, this likely needs a similar approach to ID/reference handling as in #4306 (just for Detector instead of LightSource).
I am unable to reproduce https://github.com/ome/bioformats/issues/3789#issuecomment-2969740352 for QA 91521. The sample file imports without issue into OMERO.server 5.6.15 using OMERO.insight 5.8.6. This is consistent with the fact that the latest releases of Bio-Formats also read the original file without validation errors. All other sample files mentioned in this issue have invalid OME-XML as described above.
Was there a particular combination of versions allowing to reproduce the stack trace?
Strange, tried it again with 5.8.6 against demo server, and indeed, works fine, can't replicate https://github.com/ome/bioformats/issues/3789#issuecomment-2969740352 either.
Another one: QA 91589
Confirmed that reading the file referenced in https://github.com/ome/bioformats/issues/3789#issuecomment-3013030058 generates an invalid OME-XML without #4331 and a valid OME-XML with the changes included.
I am unable to reproduce #3789 (comment) for QA 91521. The sample file imports without issue into OMERO.server 5.6.15 using OMERO.insight 5.8.6. This is consistent with the fact that the latest releases of Bio-Formats also read the original file without validation errors. All other sample files mentioned in this issue have invalid OME-XML as described above.
Was there a particular combination of versions allowing to reproduce the stack trace?
I just tried again with 60ef5ccac6d62 (latest develop) and also could not produce XML validation errors with QA 91521. It's possible that either I forgot to test QA 91521 without the fix (since there are multiple reports of this issue), or mixed up the QA numbers when writing up the description for #4331 - QA 91521 and 91491 are somewhat similar numbers and file names, so that might have been what I meant.