[ome-devel] BD Reader Datetimes of Images / Bio-formats

[Garbett, Shawn P]

Melissa,

It appears I was wrong. The BD Pathway files do contain the datetime in the TIFF (I think it's the EXIF). Is there some way to use this information instead and change this patch.


On 2/25/11 7:02 PM, "Melissa Linkert" <melissa at glencoesoftware.com> wrote:

Hi Shawn,

> Well, we have to rely on the timestamps on the files (specifically the creation date). It's the only source of this information from the BD Pathway at present. It's not the best source, but it's the only source. You configure it to acquire say every 5 minutes, then it gets as close as it can. Sometimes even experiments are stopped and restarted, this throws off the statistics.
>
> setPlaneDeltaT sounds like a fine solution to me-as long as the information is stored and it's recoverable.

OK, this commit (and thus the latest trunk build) should make it so that
a timestamp is populated for each plane:

http://git.openmicroscopy.org/?p=bioformats.git;a=blobdiff;f=components/bio-formats/src/loci/formats/in/BDReader.java;h=d2c2a23d18aa9171c1dd648ea2f695700c4674d0;hp=5c9dd968de4ca59e05b2f945246ec4b6c47202cc;hb=bb2f741a1e6c0a77d847fa0016fe147df5b33dfe;hpb=5c572c453c96c0a6731a04bc84686145805e65f2

The absolute timestamp for any plane is then Image.AcquiredDate plus the
value of DeltaT for the corresponding Plane.  For example:

    <Image ID="Image:0" Name="C013 Field #1">
      <AcquiredDate>2011-01-25T15:00:29</AcquiredDate>
      <Pixels DimensionOrder="XYZTC" ID="Pixels:0" SizeC="3" SizeT="1" SizeX="1344" SizeY="1024" SizeZ="1" Type="uint16">
         <Channel EmissionWavelength="520" ExcitationWavelength="334" ID="Channel:0:0" Name="Alexa 488 - Confocal" SamplesPerPixel="1">
         </Channel>
         <Channel EmissionWavelength="520" ExcitationWavelength="334" ID="Channel:0:1" Name="Alexa 647 - Confocal" SamplesPerPixel="1">
         </Channel>
         <Channel EmissionWavelength="520" ExcitationWavelength="334" ID="Channel:0:2" Name="Hoechst - Confocal" SamplesPerPixel="1">
         </Channel>
         <BinData BigEndian="false" Length="0" xmlns="http://www.openmicroscopy.org/Schemas/BinaryFile/2010-06"/>
         <Plane DeltaT="0.0" ExposureTime="5.0" TheC="0" TheT="0" TheZ="0"/>
         <Plane DeltaT="-21.0" ExposureTime="5.0" TheC="1" TheT="0" TheZ="0"/>
         <Plane DeltaT="-40.0" ExposureTime="5.0" TheC="2" TheT="0" TheZ="0"/>
      </Pixels>
   </Image>

The absolute timestamp of plane 0 is then '2011-01-25 15:00:29', the absolute
 timestamp of plane 1 is '2011-01-25 15:00:08', and the absolute timestamp of
 plane 2 is '2011-01-25 14:59:49'.

Regards,
-Melissa

On Fri, Feb 25, 2011 at 10:37:45AM -0600, Garbett, Shawn P wrote:
> On 2/25/11 10:11 AM, "Melissa Linkert" <melissa at glencoesoftware.com> wrote:
>
> Hi Shawn,
>
> > > MetadataTools.setDefaultCreationDate(store, tiffs[well][0], i);
> >
> > Isn't this only storing the first date? The goal is to have the timestamp for each image in the tiff stack, not just the first one. The problem is that sometimes an experiment is stopped and restarted, and the actual datetime stamp of each image is needed.
>
> That will set the acquisition date for each well to be the last modified date
> of the first file in the well.
>
> Using the setPlaneDeltaT method in loci.formats.meta.MetadataStore, we
> could set the timestamp for each plane in milliseconds since the first
> plane was acquired.  Keep in mind though that this may not always be
> accurate, especially if the timestamps on the files were changed.  I
> wasn't able to find the timestamps anywhere in the metadata files, but maybe
> you know of somewhere to find that information.
>
> Well, we have to rely on the timestamps on the files (specifically the creation date). It's the only source of this information from the BD Pathway at present. It's not the best source, but it's the only source. You configure it to acquire say every 5 minutes, then it gets as close as it can. Sometimes even experiments are stopped and restarted, this throws off the statistics.
>
> setPlaneDeltaT sounds like a fine solution to me-as long as the information is stored and it's recoverable.
>
> Shawn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20110303/54af68ff/attachment.html>