importing OME.tiffs in Omero 5

[sbesson]

Hi Yuriy,

I don't think you need to use the filename to generate the unicity. Your previous schema was fine but lacked an iteration. Andrew mentioned to me this afternoon, you could also introduce your own convention after Annotation:. For instance, the following would generate Annotation:OPT:0, Annotation:OPT:1,...

Code: Select all

for i = 1:num_files
...
metadata.setCommentAnnotationID(['Annotation:OPT:' num2str(i-1)',i-1);
...
end


As for setting the plane annotation, the corresponding Javadoc is available at here. So I would expect something like this would work:

Code: Select all

for i = 1:num_files
...
metadata.setPlaneAnnotationRef(['Annotation:OPT:' num2str(i-1)', 0, i-1, 0);
...
end


Sebastien

[yuriy_alexandrov]

Great, many thanks Sebastien, -it works now for our purposes!

The line

Code: Select all

metadata.setPlaneAnnotationRef(['Annotation:' num2str(i-1)],0,i-1,0);

still causes failure on import. But, since this place for Plane annotation is excessive, one can skip it.

This code works and doesn't create problems on import -

Code: Select all

..
metadata.setCommentAnnotationID(['Annotation:' num2str(i-1)],i-1);
metadata.setCommentAnnotationValue(char(file_names{i}),i-1);
..

However, I found that Gated FLIM OME-tiffs created with these CommentAnnotations aren't recognized by Ian's Bioformats-FLIMfit.
So for now we won't save this info for Gated FLIM OME, which we never did anyway.
We will look at it more attentively later.

Thanks again,
Y.

[sbesson]

Hi Yuriy,

it would still be interesting for us to have concrete examples for the failing OME-TIFFs with PlaneAnnotation references. Does https://github.com/openmicroscopy/Imperial-FLIMfit contain the latest version of the code so that we can reproduce the issue?

Best,
Sebastien

[yuriy_alexandrov]

Thanks Sebastien!

It is strange but now I can't reproduce this error.
That was because the string

Code: Select all

metadata.setPlaneAnnotationRef(['Annotation:' num2str(i-1)],0,i-1,0);

I use XMLValidate as You advised, and it produces all corresponding expected outputs.
So it looks like system has miraculously self-healed - no objections to that .
We'll certainly keep eye on it.

Best,
Y.

[yuriy_alexandrov]

Hi All,

The case when the Insight import error happens (described in previous post) was reproduced.
Difference between this OME-tiff and the files that were imported successfully is that 1) the file is bigger, 1) different dimension (Z instead of T) is used to pack XY planes, and 3) there is no FLIM XML Modulo annotaiton.
I will send the file by usual channel via OMERO.qa.

The only difference in code is that the line

Code: Select all

metadata.setPlaneAnnotationRef(['Annotation:' num2str(i-1)],0,i-1,0);

is uncommented.

The "Processing" progress bars in Insight Import shows the message "Failed to Import Metadata", while the "Upload" bar is completed.

Cheers,
Y.

[sbesson]

As a follow-up, most of the issues reported in this thread seem to be related to the default TransformerFactory used by MATLAB:

Code: Select all

>> java.lang.System.getProperty('javax.xml.transform.TransformerFactory')

ans =

com.icl.saxon.TransformerFactoryImpl


This TransformerFactory seems to corrupt the output of dumpXML() for complex OME-XML metadata objects (in particular the namespaces of StructuredAnnotations) leading to malformed/invalid OME-TIFFs which are thus unsucessfully/uncompletely imported.

The current workaround it to explicitly set this TransformerFactory to another implementation which now works both for the ModuloAnnotation and the SPW:

Code: Select all

java.lang.System.setProperty('javax.xml.transform.TransformerFactory', 'com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl');


Future investigation will be required to assess whether specifying a specific TransformerFactory could be performed at the XMLTools class level.

Sebastien