Bio-Formats 6 update

fiji
bio-formats
ome
imagej
ome-tiff
industry
wsi
#1

Dear all,

The OME Consortium published an update on the status of Bio-Formats 6 and the OME-TIFF pyramidal format - see https://blog.openmicroscopy.org/file-formats/community/2018/11/29/ometiffpyramid/ for more information.

We plan to release several more milestones leading up to Bio-Formats 6 over the next few months. For the Fiji community, we are planning to start distributing these milestone releases via the Bio-Formats development update site soon. We will publish announcements in this forum when this happens.

Best,
The OME Team

11 Likes
Bio-Formats 6.0.0-m4 release available
New proposed tag: "industry"
#2

Great! Looking very much forward to testing the pyramidal Tiff!
Did you check what happens if you open such a file in CellProfiler?
Will it just open the highest resolution and ignore the others?

#3

Hi @Christian_Tischer,

that’s correct. One of the criteria used for the design of the format extension was to preserve backwards-compatible behavior with existing software. Practically, that means that when reading a new pyramidal OME-TIFF, the behavior should be the following:

  • any software using Bio-Formats 5.x or an earlier version should simply treat a regular OME-TIFF reading only the planes of largest resolution and ignore all pyramidal levels,
  • any software using Bio-Formats 6.x should be able to access the new features and read the pyramidal levels via the sub-resolution API
5 Likes
#4

Are there any official reference sample files for the OME-TIFF pyramidal format that can be used for testing 3rd party OME-TIFF readers? The files produced by the scripts at https://openmicroscopy.github.io/design/OME005/ do not look quite right to me (discrepancy between TIFF tags and OME-XML regarding YCbCr sample storage).

#5

@cgohlke: thanks for your comment. A similar request had been previous discussed to make samples public but nothing has been actioned so far. We have a few samples we have been using for testing including the ones generated by the scripts you are mentioning from the original design document.

At this stage, probably more back and forth will be required to get to an authoritative final set of reference samples. This is why we have been holding off on adding them to the official location. We will look into a more transient URL where we can make our data public for consumption and testing. Also we would welcome submissions from the community to achieve a coverage as large as possible.

Finally, thanks for raising the discrependency with regard to the PhotometricInterpretation. We will take a look at it.

#6

@joshmoore
Did someone already commit to implement a BigDataViewer reader of the multi-resolution Tiff, which makes use of the resolution pyramid?

#7

Thank you! It’s not so much the PhotometricInterpretation=YCbCr tag but the discrepancy between the PlanarConfiguration=CONTIG TIFF tag and DimensionOrder="XYCZT" Interleaved="false" in the OME-XML. It is possible I misunderstood the relation between TIFF samples and OME channels from the OME XML schema. Again, I could not find official reference OME-TIFF images with multi-channel RGB data and bfconvert seems to always produce files with PlanarConfiguration=SEPARATE and Interleaved="false".

#8

My assumption would be that the Bio-Formats backend would “just work”, but it would be good to hear if that’s not the case.

#9

Ooops, based on an in-person conversation, I misunderstood. The question is whether or not BDV will automagically start using the subresolutions. My assumption there is that it won’t. There is new API that will likely need to be used, namely detecting if the Bio-Formats reader is a SubResolutionFormatReader. This will also be of use for other non-OME-Tiff formats that support sub-resolutions.

#10

As far as I know one would need to construct a Source object for it to be displayed in Bdv:

@tpietzsch: correct?

#11

Correct.

I didn’t read the full conversation above yet (will do). Just quickly:
I think what is needed is to make “BigDataViewable” dataset more of a first-class citizen in IJ2.
You could write something that explicitly takes a pyramidal tiff and wraps it as a source, but it would be nice if that would be more automatic. A pyramidal-image type that is understood throughout IJ2

2 Likes
#12

@s.besson @joshmoore
Are there java code snippets for writing and reading the new pyramidal ome.tif files?

2 Likes
#13

@Christian_Tischer the documentation page about working with whole slide images should contain most initial pointers for reading and writing.

The code for reading these files should be unchanged. The only difference is that you can now accessing sub-resolutions as shown in the SubResolutionExample.java example.

The GeneratePyramidResolution.java snippet is an example of using the new writer API to write sub-resolutions.

Feedback on these examples and/or suggestions and contributions to improve the usability very welcome as always.

1 Like
#14

Thanks!

I tried the writer code.

Fiji: drag and drop

Drag and drop of the resulting image

test01.tif (11.9 MB)

onto Fiji results in the message:


…but then it opens the highest resolution image anyway:

Fiji: [ File > Import > Bio-Formats ]

Going through [ File > Import > Bio-Formats ] opens the attached image without error, however one gets an image with 4 slices (corresponding to the number of resolutions: https://github.com/tischi/fiji-plugin-plateViewer/blob/master/src/test/java/explore/WriteMultiResolutionTiff.java#L22). Below is a screenshot of the last slice:

I guess, I am doing something wrong… :slight_smile:

CellProfiler 3.1.5

In CellProfiler 3.1.5 it opens the highest resolution layer without problems:

1 Like
#15

@Christian_Tischer yes your attached TIFF file is definitely not matching what you expect i.e. it contains 4 IFDs of the same dimension with no sub-resolutions. Also there is no OME metadata i.e. this is a plain (ImageJ) TIFF file as far as I can tell.

I assume this is something to fix in the generation code. Should we move further debugging to a separate dedicated topic or a GitHub issue on your repository?

1 Like
#16

Thanks! Yes.
This is the code that generates the file:

Please fill free to answer via an issue in that repo.