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

Improve handling of OME-TIFF multi-file filesets with partial metadata blocks (rebased onto dev_5_1) #2320

Merged
merged 2 commits into from
Apr 7, 2016

Conversation

bramalingam
Copy link
Member

This is the same as gh-2314 but rebased onto dev_5_1.


See https://trello.com/c/mVFYhwcJ/87-ome-tiff-missing-metadata-file

This commit partly reverts a previous bug fix for OME-TIFF with BinaryOnly blocks where the MetatadaFile check in isThisType(RandomAccessInputStream) was solely based on the file extension. Instead, an extra check is performed at the isThisType(String, boolean) level if metadataFile has been set by isThisType(RandomAccessInputStream) to parse the metadata.

To test this PR:

  • check the automated tests pass on the OME-TIFF files of the data repository especially the filesets with companion OME-XML
  • test the new sample fileset using a binary-only OME-TIFF with the metadata file being stored into an OME-TIFF file - see also [bug] Micromanager: reader crashes with stack format and large datasets #2308
  • test QA 16990 as described in OME-TIFF: make sure BinaryOnly files reference a valid MetadataFile #2215
  • optionally, download the multi-file OME-TIFF samples (with and without companion OME-XML) and test one or a couple of the following scenarios: 1- deletion of the metadata file, 2- renaming of the metadata file, 3- corruption of the metadata file e.g. invalidating the OME-XML block by removing a >. In all cases, running showinf at one of the BinaryOnly OME-TIFF should display the image without error but fall back to being detected as TIFF

…a blocks

This commit partly reverts a previous bug fix for OME-TIFF with BinaryOnly
blocks where the MetatadaFile check in isThisType(RandomAccessInputStream) was
solely based on the file extension. Instead, an extra check is performed at the
isThisType(String, boolean) level if metadataFile has been set by
isThisType(RandomAccessInputStream) to parse the metadata.
@bramalingam
Copy link
Member Author

--rebased-from #2314

@bramalingam
Copy link
Member Author

https://ci.openmicroscopy.org/view/Bio-Formats-5.1/job/BIOFORMATS-5.1-merge-repository-subset/234/ is green. Tested all the QA posts tested by David in #2314 (comment). Everything works as expected. Looks good to merge

@sbesson sbesson merged commit 1cc1455 into ome:dev_5_1 Apr 7, 2016
@jburel jburel added this to the 5.1.9 milestone Apr 18, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants