LSM files: differentiate between positions and tiles

[StefanoMas]

Hi,

I have a moltitude of files wirtten in the LSM format. I'd like to use the Bioformat library to extract all the metadata information about those files, but I can't seem to find a properway to distinguish between different tiles (that is, images combaining to form a single, bigger image plane) and positions, that is, what the ZEN software display as different position when visualizing data:


By looking at the xml containing the metadata in the OME format it seems the both tiles and positions are simply stored as different Images, each one in turn containing one or more planes, where information about X and Y position, as well as info about Channel, Time and Z are stored.

Neither looking at the documentation nor manually reading the xml data was I able to find a way to distinguish tiles and position. Is there a standard way to do that?

Just as an example, I uploaded two sample files: the first one, 5Z10T2Pos.lsm, contains 2 positions and each of them contains a timeseries of 10 images as well as 5 slices in Z. The second files, U4_20150217_TileStack_5x_Overview.lsm, is a stack of 21 images composed by 2x2 tiles.

Many thanks in advance for any feedback :-)

[mlinkert]

Thank you for uploading relevant sample files.

By looking at the xml containing the metadata in the OME format it seems the both tiles and positions are simply stored as different Images, each one in turn containing one or more planes, where information about X and Y position, as well as info about Channel, Time and Z are stored.

Yes, that's correct.

Neither looking at the documentation nor manually reading the xml data was I able to find a way to distinguish tiles and position. Is there a standard way to do that?

There isn't a good standard way to do this across all formats, but in the case of Zeiss LSM files the original metadata table contains the number of tiles and positions. U4_20150217_TileStack_5x_Overview.lsm will have the following in its original metadata table:

Code: Select all

DimensionM: 4
DimensionP: 1


and 5Z10T2Pos.lsm will have:

Code: Select all

DimensionM: 1
DimensionP: 2


i.e. DimensionM is the number of tiles and DimensionP the number of positions.

The original metadata table is shown by default if you are using the 'showinf' command line tool. In ImageJ, it can be displayed by checking the "Display original metadata" box during import. If you are using Bio-Formats from your own code, the following (through line 934) illustrates how to work with the original metadata table programatically:

https://github.com/openmicroscopy/biofo ... .java#L915

[StefanoMas]

Hi, thanks a lot for the quick reply.

Indeed what we are doing now is reading the original metadata table.

We are building a wrapper around the BioReader library and we were hoping that checking the metadata in the OME format was sufficient to extract all the information we needed to read the data, but apparently that's not the case, yet.

One more question: is there a standard way to contribute to the project? Or it is just a matter of forking the repo and submitting pull requests?

Thanks again!

[mtbc]

Dear Stefano,

http://www.openmicroscopy.org/site/supp ... tributing/ is probably the canonical reference for contributing, especially http://www.openmicroscopy.org/site/supp ... evelopers/ -- but, yes, forking the repo and opening a pull request is generally the way to go. Especially over the holiday period please be patient with us. If anything in the above documentation seems relevant but unclear then let us know and we'll try to improve it.

Absolutely do feel free to first ask here about technical approach, etc., if you are not sure how well the changes you want to propose fit in with how we try to do things in the codebase or with the future plans that we discuss at https://trello.com/ome then it is fine to chat in advance before putting a bunch of work into the specific code changes. But, if they are small or you pretty much have them ready to go anyway then of course a PR can be a fine anchor for any necessary discussion.

Thank you very much for looking to contribute as we greatly welcome such partnership with the community.

Cheers,

Mark

[StefanoMas]

Cool, thanks a lot.

We are internally discussing whether it makes more sense to develop separate file format readers or directly contribute to the OME projects, so it's good to have this information

Bets regards,
Stefano