Very basic question: associating png import into time series

[dps]

I am trying to import png files from a time series experiment using insight 5.1 but cannot accomplish the basic task of associating files at the same position with different time points into the same file set, i.e. generating some metadata about these pngs. The result is that viewing a file after import always shows T: 1/1, i.e. no ability to step through the frames of the "movie" that the png files describe.

The original naming of the files was like this:

p0001/t0001_Brightfield.png
p0001/t0001_Red.png
p0001/t0002_Brightfield.png
p0001/t0003_Brightfield.png
p0001/t0003_Cyan.png
p0001/t0004_Brightfield.png
etc.

i.e. position folder, timepoints per wavelength within.

I also tried changing the wavelength strings to the pattern "c0", "c1", etc. to no avail.

Finally, I read about setting a up a pattern file to instruct the importer what to do, and created a directory called "test" with the following contents:

import.pattern
t0001_c0.png
t0002_c0.png
t0003_c0.png
t0003_c1.png
t0004_c0.png
t0005_c0.png
t0006_c0.png
t0007_c0.png
t0008_c0.png
t0008_c1.png
t0009_c0.png

where import.pattern contains:
t<0000-9999>_c<0-9>.png

in the insight client i tried importing this whole test directory, only the import.pattern file, only the first time point of each wavelength, all the files within the dir, and the pattern file + the first file of each wavelength. in each case only exactly those files are imported (except the pattern file, which isn't a valid image) with no association between wavelength sets.

since this is a very basic aspect of the import process, i assume i am missing something that should be obvious. any help would be much appreciated!

-david

[dgault]

Hi David,

There are a few possible things that could be going wrong here, when using the patterns we are building up a list of every possible file we expect to find as part of a series and then stitching the files together. By using a pattern such as <0000-9999> you will likely see either file not found errors or possibly even encounter memory issues when attempting to process tens of thousands of files.

If you use a more specific pattern then hopefully you should not encounter these issues and your files should be grouped correctly. In this case you could use something like: t<0001-0009>_c<0-1>.png

[dps]

thanks for the reply!

i tried changing the pattern, and i even now used the "File Pattern" file format in the dropdown (which i hadn't seen before). when i import just the import.pattern file, it says "File Not Valid". when i import the whole dir (even with "File Pattern" file format selected), all images are uploaded individually; the original problem is still there.

The client gives me no feedback about the existence or significance of the import.pattern file, nor were there file not found or memory error popups. Are there any logs produced by insight that might help?

in the end i want to use the CLI for imports, so if there is a working suggestion involving that, I am all ears.

BTW, this is OS X.

thank you!
david

[dgault]

To import the fileset you should only have to select and import the .pattern file that you created.

When you imported the pattern file on its own and got the File Not Valid error, could you hover over the red X beside were it says Failed, do you see any further details on the error message? I would expect to see something such as a FileNotFoundException.

[dps]

OK, somehow i missed the very obvious button to look at the stack trace that caused the failure, and it's indeed an improperly specified pattern file. the first and last numbers in the pattern may not be out of the range.

so now i set up two pattern files like this:

c0.pattern:
t<0001-0009>_c0.png

c1.pattern:
t<0003-0008:5>_c1.png

one for each wavelength because c1 occurs only every 5 time points.

now the import works! but the viewer does not: when i view c0.pattern and c1.pattern in insight or the web client, i now see the correct number of time points within each, but it does not show me the images themselves, i.e. the files appear to be imported but are not viewable.

[dps]

i should also mention that ideally even these two patterns should be part of the same fileset, since they are taken at the same position on the slide and contain different wavelengths acquired at basically the same time point.

so at certain time points, we don't take an image with wavelength c2, because it would be too toxic by the end of the experiment (multiple days of imaging). this is the only way to run the experiment for this long.

simplified example:

t0001_c0.png
t0001_c1.png
t0001_c2.png
t0002_c0.png
t0003_c0.png
t0003_c1.png
t0004_c0.png
t0005_c0.png
t0005_c1.png
t0005_c2.png
t0006_c0.png
t0007_c0.png
t0007_c1.png
t0008_c0.png
...

i.e. c1 comes every other time point, and c2 is there only every fourth time point. the even-numbered time points only have c0 (brightfield imaging doesn't kill the cells in this time frame yet assists in tracking their movement)

in the end, of course i want to be able to flip through the images of a given wavelength as well as see a given time point's wavelengths side-by-side.

is it possible to accommodate this kind of time series in Omero?

[rleigh]

It's not possible to represent this directly with the current patterns, and nor is it possible to represent with the current data model internally--they don't at this time handle sparse data.

What current readers do, depending upon the context, is to either insert a blank plane or to duplicate the plane.

In your case, you could do either. Since the data is "missing" since you didn't acquire it, you could insert empty images here. But if nicer viewing is a priority, you could copy the plane from the previous timepoint.


Regards,
Roger

[dps]

thank you for the reply - "copying" the plane sounds like a good solution.

but since some of these wavelengths are quite sparse, it would be best to simply refer to the image data of the previous time point rather than creating, storing and importing a lot of duplicate information - is this possible? otherwise i will probably need to triple my import time.

[rleigh]

Dear David,

I've prepared an example of how to do this. Please try downloading http://users.openmicroscopy.org.uk/~rle ... xample.zip and taking a look at the files here. Also, please take a look at https://www.openmicroscopy.org/site/sup ... ml-fileset which explains some of the background to this solution.

In the zip, you'll see a collection of PNGs (sparse in T), and a corresponding set of TIFFs. There is a script (gensparse) which generates this sparse PNG dataset to match your example (note: will only work on Linux, will need tweaking for other systems). There's a brightfield channel at all timepoints, and then red and cyan channels every 4 timepoints, staggered by 2, starting at t1 and t3, respectively.

The script converts these PNG images into a multi-file OME-TIFF dataset. Each PNG image is separately converted into a TIFF, and a small OME-XML fragment is embedded in each TIFF, containing a reference to the metadata file (multifile.companion.ome). This file contains a complete record of each file in the dataset, and which timepoint and channel it refers to. Note that each filename has a corresponding UUID which is used to reference it; we generate these in the script when we embed the OME-XML in each script, and then again when creating the companion metadata. I included some ancillary metadata in the companion metadata as an example, which includes timestamps for each plane as well as exposure time and stage positions. These are all optional; you can omit the plane information if you wish.

I also generated a blank plane for use in the red and cyan channels before the first acquired plane. We then reuse the last acquired plane in each channel for timepoints between acquisitions for those channels, and because we refer to an already used TIFF this will be avoiding any duplication of pixel data when reusing it for following timepoints. If you load this OME-TIFF with bioformats showinf, or import into OMERO or ImageJ, you'll be able to navigate around the channels and timepoints and see how things are laid out. In the example, I've overlaid text descriptions over each plane so you can see its position, and also added channel colours so they get false coloured in a viewer which supports this.

While the example I've used makes use of graphicsmagick to create the PNG files, and then to do the TIFF conversion and OME-XML embedding, these are just examples. You can use any tool of your choice to do these steps, for example Bio-Formats bfconvert and tiffcomment. I wrote this as a shell script so that the steps were clear, but again any scripting or other language of your choice could be used for these tasks. There are also other possible solutions. While this example uses a separate TIFF file per plane, you can adjust it to use one file per timepoint, or per channel, or have everything in a single file. You just need to adjust the IFD numbers in the TiffData to point to the appropriate plane in the file. If you go with a single file approach, you then don't need the companion metadata file; you can simply embed it in the single TIFF and the whole thing will be self-contained.

Also note that this example uses the 2016-06 data model, which is not yet in a released version of Bio-Formats. You'll probably want to adjust this to use 2015-01 in your own files, which is the currently supported version (no other changes are required).

Though the script is unlikely to be useful to you without modification, I hope that this at least illustrates the concepts of how you could go about doing this, which should make it possible to adapt or reimplement to make something which works for your datasets.

If there's anything unclear or for which you would like some further explanation, or if this doesn't work for you, please do let us know and we can go into this in more detail.


Kind regards,
Roger

[dps]

Roger,

many thanks for the reply - i will test it out!

-david