Reading Series information on LIF files

[Oli]

Dear all,

While playing around with the Loci ImageReader to read in a large lif file containing several "Series" of Z stacks. My goal is to read in each stack, perform a MIP and save them.
However, the order of the stacks as it is read by the setSeries(int i) function of ImageReader is incorrect, so I cannot use my iterator(i) to name the newly created MIP.

I have tried to find out how the BioFormats Importer Preview window manages to get the Series names right and I have browsed the metadata but with no luck. Could anyone direct me in the rigut direction?

The goal is to find something like "Series 1", "Series 2" etc... again because the series are not in order when using ImageReader.setSeries(i), this I would like to access the Serie's name, or at least find out how come the Previewer manages to format the file contents so well.

Thank you for your time!

Oli

[mlinkert]

Hi Oli,

The 'computeSeriesLabels(IFormatReader)' method in loci.plugins.in.ImportProcess is what creates the series labels that you see in the "Bio-Formats Series Options" window (the one with all of the thumbnails).

More concisely, this is how you would retrieve the image names and labels for every series:

Code: Select all

IMetadata omexmlMetadata = MetadataTools.createOMEXMLMetadata();
ImageReader reader = new ImageReader();
reader.setMetadataStore(omexmlMetadata);
reader.setId("/path/to/lif/file");

int seriesCount = reader.getSeriesCount();
for (int i=0; i<seriesCount; i++) {
  reader.setSeries(i);
  String name = omexmlMetadata.getImageName(i); // this is the image name stored in the file
  String label = "Series " + (i + 1) + ": " + name;  // this is the label that you see in ImageJ
  // now you can read the pixel data for this series...
}
reader.close();


It's important to note that the "Series 1", "Series 2", etc. prefixes that you see in the "Bio-Formats Series Options" window are not part of the stored image name - they are added manually to make the labels easier to read and to make it easier to record a macro of the Bio-Formats importer plugin.

Regards,
-Melissa

[Oli]

Hi Melissa,

Thanks for the reply, the code you suggest is exaclty the one I was testing, now if I add the following line of code in your for loop after reader.setSeries(): (There are 135 Series in the LIF File, called "PosXXX_S001")

Code: Select all

String newname = omexmlMeta.getImageName(i);
Hashtable <String, Object> seriesData = reader.getSeriesMetadata(); //Getting the "Raw" Metadata as I understand it.
String name = omexmlMetadata.getImageName(i); // this is the image name stored in the file
    String seriesName = (String)seriesData.get("Name 7"); // This is the name stored in the Series (i) metarada.
    IJ.log("Series "+i+1+": OME XML = " + newname+" - vs. GetSeriesMetadata() = "+seriesName);

Series 1: OME XML = New collection/Pos001_S001 - vs. GetSeriesMetadata() = Pos002_S001
Series 2: OME XML = New collection/Pos002_S001 - vs. GetSeriesMetadata() =Pos003_S001
Series 3: OME XML = New collection/Pos003_S001 - vs. GetSeriesMetadata() = Pos004_S001
Series 4: OME XML = New collection/Pos004_S001 - vs. GetSeriesMetadata() = Pos005_S001
...
Series 135: OME XML = New collection/Pos135_S001 - vs. GetSeriesMetadata() = null

It appears that the series are not in order in the LIF file (Though they are when I open it in Leica LAS AF), so getSeries(i) seems to fetch "Pos002_S001" first and then goes through them until the end, which should be "Pos001_S001" by elimination (It doesn't show up on the metadata for some reason).

BUT the OME XML data has them in order, and so when we use the iterator (i) the name the IMetadata returns is offset. Any ideas as to why this is the case?

Thank you very much for your help!

Oli

[mlinkert]

Hi Oli,

Series 1: OME XML = New collection/Pos001_S001 - vs. GetSeriesMetadata() = Pos002_S001
Series 2: OME XML = New collection/Pos002_S001 - vs. GetSeriesMetadata() =Pos003_S001
Series 3: OME XML = New collection/Pos003_S001 - vs. GetSeriesMetadata() = Pos004_S001
Series 4: OME XML = New collection/Pos004_S001 - vs. GetSeriesMetadata() = Pos005_S001
...
Series 135: OME XML = New collection/Pos135_S001 - vs. GetSeriesMetadata() = null

It appears that the series are not in order in the LIF file (Though they are when I open it in Leica LAS AF), so getSeries(i) seems to fetch "Pos002_S001" first and then goes through them until the end, which should be "Pos001_S001" by elimination (It doesn't show up on the metadata for some reason).

BUT the OME XML data has them in order, and so when we use the iterator (i) the name the IMetadata returns is offset. Any ideas as to why this is the case?

The series themselves are in order, there was just a slight bug in how the names are stored in the original metadata hashtable. This has been resolved in the latest trunk build, so now this code:

Code: Select all

    String newname = omexmlMeta.getImageName(i);
    Hashtable <String, Object> seriesData = reader.getSeriesMetadata();
    String name = omexmlMetadata.getImageName(i); // this is the image name stored in the file
    String seriesName = seriesData.get("Image name");
     IJ.log("Series "+i+1+": OME XML = " + newname+" - vs. GetSeriesMetadata() = "+seriesName);


should produce output similar to this:

Code: Select all

Series 1: OME XML = New collection/Pos001_S001 - vs. GetSeriesMetadata() = New collection/Pos001_S001
Series 2: OME XML = New collection/Pos002_S001 - vs. GetSeriesMetadata() = New collection/Pos002_S001
Series 3: OME XML = New collection/Pos003_S001 - vs. GetSeriesMetadata() = New collection/Pos003_S001
Series 4: OME XML = New collection/Pos004_S001 - vs. GetSeriesMetadata() = New collection/Pos004_S001


with your data. You can see the relevant change in Bio-Formats here:

http://dev.loci.wisc.edu/trac/software/changeset/7317

Note that we do strongly recommend that you use the OMEXMLMetadata object to retrieve metadata such as image names, channel names, dimensions, etc. The original metadata hashtable is intended more to preserve the format-specific things that cannot be stored in OME-XML.

If you still see a problem after updating to the latest trunk build, please let us know.

Regards,
-Melissa