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

CZI: Use CreationDate as alternate AcquisitionDate #3430

wants to merge 1 commit into
base: develop


Copy link

commented Sep 5, 2019

This is a follow up to the thread:
A sample file is available in QA-27807

When the usual Information > Image > AcquisitionDateAndTime metadata is not set then also check Information > Document > CreationDate and use it to populate Image Acquisition Date.

@dgault dgault added this to the 6.3.0 milestone Sep 5, 2019


This comment has been minimized.

Copy link

commented Sep 6, 2019

A very quick auditing of a few CZI files in the curated QA repository seems to reveal that Information > Document > CreationDate is always present whenInformation > Image > AcquisitionDateAndTime exists but the reverse statement is not true.

For most examples, the values of both dates are very close if not identical:

$ find /data/public/ -iname *.czi -exec sh -c "echo {} && /bio-formats-build/bioformats/tools/showinf -nopix {} | grep Date" \;
Information|Document|CreationDate #1: 2013-12-10T17:46:40.7586388+00:00
Information|Image|AcquisitionDateAndTime #1: 2013-12-10T17:46:40.7596389Z
Scaling|AutoScaling|CreationDateTime #1: 01/01/0001 00:00:00

Unless there is a reason to consider Information > Document > CreationDate as the ground truth for all filesets, falling back to Information|Document|CreationDate if Information|Image|AcquisitionDateAndTime if present looks like a safe addition.

Configuration files should probably be reviewed across the curated QA repository accordingly.

@dgault dgault added the exclude label Sep 9, 2019


This comment has been minimized.

Copy link
Member Author

commented Sep 9, 2019

Excluding for now due to a number of failures:

The deltaT failures are likely to be mostly valid, but they will each need to be reviewed a decision taken to either update all the configs or ignore CreationDate for the deltaT purposes. There are also a number of CreationDates found with values such as: 1899-12-30T00:00:00 which fail the sanity test. These could be special cased to ignore these instances.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.