openslide-users Digest, Vol 72, Issue 4

Tue Jan 19 06:20:26 EST 2016

@Dmitry

Thank you very much for your detailed clarification! This information will
help us a lot.

@Derek

Thank you for your point. I really like the approach of using the Aperio
.svs file format. Unfortunately it is a proprietary format and it will be
hard to convince my boss to use it after we are no licensing experts.

Maybe I should just ask Aperio if it is ok to use their format.

If it turns out that OME is not the right approach for the WSI world and
svs does not provide an appropriate license.

Does it make sense to introduce a BSD licensed WSI file format which is
just a slight modification of the aperio format? The new integration of
this format should be very easy for third party apps which already support
svs.

And what are the odds that this will lead to a wide third party support
aswell?

Cheers,
Andi

2016-01-13 16:43 GMT+01:00 <openslide-users-request at lists.andrew.cmu.edu>:

> Send openslide-users mailing list submissions to
>         openslide-users at lists.andrew.cmu.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users
> or, via email, send a message with subject or body 'help' to
>         openslide-users-request at lists.andrew.cmu.edu
>
> You can reach the person managing the list at
>         openslide-users-owner at lists.andrew.cmu.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openslide-users digest..."
>
>
> Today's Topics:
>
>    1. Re: OME-TIFF (Dmitry Fedorov)
>    2. FW: OME-TIFF (Derek Magee)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 12 Jan 2016 09:21:36 -0800
> From: Dmitry Fedorov <fedorov at ece.ucsb.edu>
> To: Andreas Schmid <andreas.schmid at precipoint.de>
> Cc: "openslide-users at lists.andrew.cmu.edu"
>         <openslide-users at lists.andrew.cmu.edu>
> Subject: Re: OME-TIFF
> Message-ID:
>         <CAERMcmTCTZZ7dA942Exw=eRSfS1t=
> X91mfbYwcnoaK2fbgpzOA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> You could use libbioimage <https://bitbucket.org/dimin/bioimageconvert>
> alongside OpenSlide to achieve full support for OME-TIFF and WSI. In fact
> it supports pyramidal and tiled OME-TIFF and OME-BigTIFF that are not
> strictly standardised. It also supports other formats not yet available in
> OpenSlide, like tiled JPEG-2000 (this will get a lot better with the next
> openjpeg library version).
>
> Libbioimage is a complimentary library for OpenSlide since it was designed
> to support multi-dimensional and multi-channel fluorescence imagery. In our
> system BisQue (management and analysis system) we use openslide for WSI and
> libbioimage for OME-TIFF for very large images daily. Finally, I decided to
> integrate OpenSlide into libbioimage as one of the decoders and this should
> be finished for the next version. I also hope to incorporate OpenSlide
> extensions like DICOM-WSI from Mathieu Malaterre and have started writing a
> CZI importer supporting fluorescence.
>
> Although I use OME-TIFF as our main interchange format and do like it, we
> have encountered a few problems in more than 10 years of use, I'll try to
> list those for your consideration.
>
> 1) Really large images require BigTIFF packaging and thus become unreadable
> by most programs supporting TIFF.
>
> 2) Pyramidal-tiled OME-TIFF is not standardised. I prefer sub-directory
> based approach (similar to Photoshop's pyramid) myself but implemented
> support for other cases I know.
>
> 3) Every channel plane is stored in a separate directory making it a bit
> slower to read all the channels since one must change directory several
> times for every tile.
>
> 4) TIFFs with many directories become very slow to read since one must
> traverse the whole file until the desired directory is reached. I've worked
> with very large 4D OME-TIFFs with hundreds of thousands of directories.
> Although libbioimage patched libtiff with a few optimizations for this case
> it is still a real problem. The solution to this is unfortunately a
> multi-file solution where each 3D block is stored as a separate OME-TIFF
> file.
>
> 5) OME-TIFF metadata model is quite rigid and designed for a specific use.
> It does provide a flat name-value list for extended information but it is
> very verbose and too simple to store a large amount of complex information.
> Thousands of tags will make that list very slow to parse.
>
> Folks at OME consortium published a paper proposing to use an HDF-5 based
> format for lifesciences. Although it sounds like a great idea there's no
> standard definition for it yet. Many companies are using HDF5 based formats
> for a long time but they are all proprietary, for example Imaris ims5.
>
> Cheers,
> dmitry
>
>
> On Tue, Jan 12, 2016 at 2:46 AM, Andreas Schmid via openslide-users <
> openslide-users at lists.andrew.cmu.edu> wrote:
>
> > Thoughts on OME-TIFF as an OpenSlide Format
> >
> > Actually our company saves the WSI images as an zipped deepzoom pyramid
> > simular to Martin Weihrauchs Smart Zoom Image approach. Unfortunately
> this
> > format lacks third party support and likely ever will and suffers from
> the
> > detriments of a non-image format (Like viewing it in any other tiff
> > supported software when it is not too large).
> >
> > We took some research in the past weeks and considering to switch to a
> > tiff-based WSI format but we are not strigency interested to do our's own
> > thing to be just another one who sheers off from a standardized WSI
> format.
> >
> > So we kept an wary eye on the OME-TIFF format.
> >
> > What do you think? Is OME-TIFF a canditate for beeing an openslide format
> > too?
> > How do you think will OME develop in the future?
> >
> > _______________________________________________
> > openslide-users mailing list
> > openslide-users at lists.andrew.cmu.edu
> > https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users
> >
> >
>
>
> --
> __________________________________
>
> Dmitry Fedorov Levit <dima at dimin.net>
> Web: http://www.dimin.net/
> __________________________________
>
> Center for Bio-Image Informatics:
>   <http://www.bioimage.ucsb.edu/>
>
> Vision Research Lab, Electrical and Computer Engineering:
>   <http://vision.ece.ucsb.edu/>
>
> University of California, Santa Barbara
> _________________________________
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.andrew.cmu.edu/pipermail/openslide-users/attachments/20160112/1f5ffcfd/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Wed, 13 Jan 2016 15:42:53 +0000
> From: Derek Magee <D.R.Magee at leeds.ac.uk>
> To: "openslide-users at lists.andrew.cmu.edu"
>         <openslide-users at lists.andrew.cmu.edu>
> Subject: FW: OME-TIFF
> Message-ID:
>         <
> DB5PR03MB141336CC3D4D99BE1DC66D6BE0CB0 at DB5PR03MB1413.eurprd03.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="utf-8"
>
> [Apparently I didn?t send this to the list first time? I?m really
> interested in others opinions on OME-TIFF too!]
>
> My 2c?
>
> We use Aperio .svs as the native format for writing output images in our
> digital pathology image analysis system (
> http://www.medicalimagemanager.com if were advertising ?). This is a
> (reasonably) well described tiled tiff format supporting jpeg and jpeg2000
> tiles, which is reasonably easy to write with open source libtiff
> (+openjpeg for jpeg2000). You also need BigTIFF support for larger files
> (but I can?t really see a way round that one), and it isn?t readable by
> standard tiff viewers (again if you are talking a tiled format I can?t see
> a way round that one either). Obviously the main advantage is it is
> supported by OpenSlide already (as well as Bioformats).
>
> I have no real issues with svs, but I was also thinking of looking at
> OME-TIFF too (I like the fact the format is openly described, although a
> bit too flexible maybe). It isn?t widely used in digital pathology though,
> but is quite widely used in other microscopy areas. I?m interested in
> other?s opinions if it will ever be a major format in digital microscopy?
>
> One thing about bio-formats that put me off is that it has a tangle of
> different licences. Some features require a commercial licence for
> commercial use (Open Microscopy isn?t quite as open as OpenSlide in that
> respect). It?s also written in Java, and while there are bindings for other
> languages (e.g. c++ binding in ITK) it does complicate things (i.e. Java
> needs to be installed an configured) if you aren?t using Java.
>
> Derek
>
> From: openslide-users [mailto:openslide-users-bounces+d.r.magee=
> leeds.ac.uk at lists.andrew.cmu.edu] On Behalf Of Dmitry Fedorov via
> openslide-users
> Sent: 12 January 2016 17:22
> To: Andreas Schmid
> Cc: openslide-users at lists.andrew.cmu.edu<mailto:
> openslide-users at lists.andrew.cmu.edu>
> Subject: Re: OME-TIFF
>
> You could use libbioimage <https://bitbucket.org/dimin/bioimageconvert>
> alongside OpenSlide to achieve full support for OME-TIFF and WSI. In fact
> it supports pyramidal and tiled OME-TIFF and OME-BigTIFF that are not
> strictly standardised. It also supports other formats not yet available in
> OpenSlide, like tiled JPEG-2000 (this will get a lot better with the next
> openjpeg library version).
>
> Libbioimage is a complimentary library for OpenSlide since it was designed
> to support multi-dimensional and multi-channel fluorescence imagery. In our
> system BisQue (management and analysis system) we use openslide for WSI and
> libbioimage for OME-TIFF for very large images daily. Finally, I decided to
> integrate OpenSlide into libbioimage as one of the decoders and this should
> be finished for the next version. I also hope to incorporate OpenSlide
> extensions like DICOM-WSI from Mathieu Malaterre and have started writing a
> CZI importer supporting fluorescence.
>
> Although I use OME-TIFF as our main interchange format and do like it, we
> have encountered a few problems in more than 10 years of use, I'll try to
> list those for your consideration.
>
> 1) Really large images require BigTIFF packaging and thus become
> unreadable by most programs supporting TIFF.
>
> 2) Pyramidal-tiled OME-TIFF is not standardised. I prefer sub-directory
> based approach (similar to Photoshop's pyramid) myself but implemented
> support for other cases I know.
>
> 3) Every channel plane is stored in a separate directory making it a bit
> slower to read all the channels since one must change directory several
> times for every tile.
>
> 4) TIFFs with many directories become very slow to read since one must
> traverse the whole file until the desired directory is reached. I've worked
> with very large 4D OME-TIFFs with hundreds of thousands of directories.
> Although libbioimage patched libtiff with a few optimizations for this case
> it is still a real problem. The solution to this is unfortunately a
> multi-file solution where each 3D block is stored as a separate OME-TIFF
> file.
>
> 5) OME-TIFF metadata model is quite rigid and designed for a specific use.
> It does provide a flat name-value list for extended information but it is
> very verbose and too simple to store a large amount of complex information.
> Thousands of tags will make that list very slow to parse.
>
> Folks at OME consortium published a paper proposing to use an HDF-5 based
> format for lifesciences. Although it sounds like a great idea there's no
> standard definition for it yet. Many companies are using HDF5 based formats
> for a long time but they are all proprietary, for example Imaris ims5.
>
> Cheers,
> dmitry
>
>
> On Tue, Jan 12, 2016 at 2:46 AM, Andreas Schmid via openslide-users <
> openslide-users at lists.andrew.cmu.edu<mailto:
> openslide-users at lists.andrew.cmu.edu>> wrote:
>
> Thoughts on OME-TIFF as an OpenSlide Format
>
>
> Actually our company saves the WSI images as an zipped deepzoom pyramid
> simular to Martin Weihrauchs Smart Zoom Image approach. Unfortunately this
> format lacks third party support and likely ever will and suffers from the
> detriments of a non-image format (Like viewing it in any other tiff
> supported software when it is not too large).
>
> We took some research in the past weeks and considering to switch to a
> tiff-based WSI format but we are not strigency interested to do our's own
> thing to be just another one who sheers off from a standardized WSI format.
>
> So we kept an wary eye on the OME-TIFF format.
>
> What do you think? Is OME-TIFF a canditate for beeing an openslide format
> too?
> How do you think will OME develop in the future?
>
> _______________________________________________
> openslide-users mailing list
> openslide-users at lists.andrew.cmu.edu<mailto:
> openslide-users at lists.andrew.cmu.edu>
> https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users
>
>
>
> --
> __________________________________
>
> Dmitry Fedorov Levit <dima at dimin.net<mailto:dima at dimin.net>>
> Web: http://www.dimin.net/
> __________________________________
>
> Center for Bio-Image Informatics:
>   <http://www.bioimage.ucsb.edu/>
>
> Vision Research Lab, Electrical and Computer Engineering:
>   <http://vision.ece.ucsb.edu/>
>
> University of California, Santa Barbara
> _________________________________
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.andrew.cmu.edu/pipermail/openslide-users/attachments/20160113/7623975a/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> openslide-users mailing list
> openslide-users at lists.andrew.cmu.edu
> https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users
>
>
> ------------------------------
>
> End of openslide-users Digest, Vol 72, Issue 4
> **********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/openslide-users/attachments/20160119/5edeff4b/attachment-0001.html>