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 #2314

Merged
merged 2 commits into from Apr 4, 2016

Conversation

sbesson
Copy link
Member

@sbesson sbesson commented Mar 29, 2016

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.
@ghost
Copy link

ghost commented Mar 30, 2016

I've looked over the code and tested QA16990 and the multi-file companion cases, and it all appears to work correctly for these examples, falling back to TIFFReader. The code looks logical, and good to merge to me. David has done a lot more testing of other samples, which I'm sure he will follow up about separately.

@dgault
Copy link
Member

dgault commented Mar 30, 2016

Code changes make sense based on the feedback on the bugs and trello card.

Automated tests for both existing ome-tiff filesets in curated and fileset from https://github.com/openmicroscopy/data_repo_config/pull/100 in inbox are green - https://ci.openmicroscopy.org/job/BIOFORMATS-DEV-merge-repository-subset/182/
https://ci.openmicroscopy.org/job/BIOFORMATS-DEV-merge-repository-subset/183/

Ive also tested against QA's 16917, 16988, 16988, 16990, files all open and behave as expected with these code changes.

Everything looks good to merge.

@bramalingam
Copy link
Member

--rebased-to #2320

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

4 participants