[ome-devel] TIFF pyramid support in Bio-Formats - reference files for review

[Roger Leigh]

On 26/03/2018 22:41, Damir Sudar wrote:
> Hi Roger,
>
> I'm having a bit of fun with creating type "C" pyramidal OME-Tiffs. The
> makepyramid-ptif script works for single-channel files but I expanded it
> a bit to allow creation of multi-channel ones as well. Enclosed is
> makepyramid-multi. That didn't make the script any prettier but as you
> said, this is only a hack to create some test data and better understand
> how best to structure the tiff and associated ome-xml. Using the multi
> script, I generated a 2-channel image with pyramids inside and I
> attached bogus "label" and "macro" images (had to hand-edit the XML to
> get them to meet OME-XML requirements). I uploaded that file to the QA
> system for your enjoyment.

Did this upload correctly?  I can't see any recent uploads to the QA
system.  I'll certainly take a look when I can find it!

>>> - the Leica-Fluorescence-1.scn (and thus all its result files) has the
>>> channels stored in a way that is not exactly conform how one would
>>> normally store the channels in the OME-standard way. Am I correct in
>>> thinking that those channels would normally be in separate top-level
>>> IFDs each and have their sub-resolutions arranged in SubIFDs under each
>>> of those top-levels?
>>
>> Both are permitted, even combined, though this way is certainly less
>> typical for fluorescence.  For RGB data it's expected though. You're
>> absolutely correct about each top-level IFD having separate
>> sub-resolutions.
> One thing I noticed about the Leica-Fluorescence-1 type "C" ome-tiff
> result file, is that while it passes xmlvalid, showinf doesn't really
> like it. The file I uploaded appears to pass all tests and I even
> uploaded it to OMERO which of course doesn't even see the sub-resolution
> SubIFDs but has no issues with it.
>
> If the team indeed decides to go with the "C" approach, this indicates
> that it should ??always?? be possible to create the pyramid OME-TIFF
> file in such a way that any old-style OME-TIFF reader that is compatible
> with the current standard, should be able to read the new-style files
> and simply ignore the subresolutions.

In theory, all "C" files should work with all tools with or without
support for SUBIFDs.  As you say, readers which don't handle SUBIFDS
should simply ignore them.

I had noticed the odd behaviour of Leica-Fluorescence-1, but I haven't
yet dug into why this is happening in detail.  It's likely to be
something odd in the OME-XML, maybe because the shell script isn't doing
the conversion quite right.  Since it's only for the OME-XML, and not
the plain TIFF (I think), this is likely bad OME-XML metadata.

>>> - also, all these examples carry some of those ancillary images such as
>>> slide labels, overview images, etc. While the scripts handled those
>>> correctly as far as I can see, a reader would have to be pretty smart to
>>> figure out which of the contents of such an output file is the actual
>>> image and which are those ancillary images.
>>
>> Absolutely.  We will need to do something about these as a followup
>> task, to add the metadata to identify these as labels, overviews, etc.
>>
> In the file I uploaded the mocked up label and macro/overview images are
> stored as top-level IFDs and in the OME-XML coded as separate series.
> Would this be an appropriate way to store such ancillary images? If so,
> then we could codify where in the file they should be (at the end?),
> standardize what name they should have to identify them, and anything else?

I think they would need to be separate top-level images.  What's needed
is some extra metadata to tie the images together.  There are several
possibilities for this, including

- annotations to specify the image is from a particular slide and what
type of image it is (label, overview, full size image)
- regions of interest on the overview pointing to the full size image
for the region
- (harder) slide-specific data modelling to parallel the
screen-plate-well (SPW) support; this could cater for specific metadata
for digital pathology, arrays of separate cores in wax blocks etc (I
forget the name)

In some ways the metadata for "slides" is very similar to "plates", with
sections being equivalent to wells with multiple fields of view in each.
  I wonder if we can't reuse or repurpose some of the logic.


Regards,
Roger

The University of Dundee is a registered Scottish Charity, No: SC015096