Multiplane and fluorescence API design
Yves Sucaet
sucaet at histogenex.com
Wed Jul 11 03:48:01 EDT 2012
Hi Alexandre,
You are correct. The ZVI images and subimages only contain the highest
resolution images. There can be 4 different types of image data: ZiImage,
ZiRawImage, ZiSubImage and ZiSubImages. ZiRawImage and ZiSubImage are the
most relevant for integration in OpenSlide I believe.
You should be aware that the ZiImage is set up as a 6D hyperspace. A
ZiRawImage represents a 2D pixel matrix, the 'real' image
In addition, each ZiRawImage contains information about its place within
this hyperspace, which is defined as follows:
* P = tile image within the XY plane (MosaiX)
* Z = depth coordinate
* T = time coordinate
* C = channel coordinate
* S = scene coordinate (semantically distinct objects, e.g. a cell)
* A = view coordinate (arbitray view, e.g. 3D view)
You can see how a file is organized in Axiovision by activating the Tree
view (Tools > Options > Display)
Fwiw, zvi-files can also contain time-lapse data (e.g. take a picture of a
growing bacterial colony every 10 minutes overnight). As long as we're
redesigning the API, this may be something taking into consideration.
Clearly the reason why there are so many different formats at least in
part has to do with the fact that so many different techniques exist
(EM-specific formats, anybody?).
I'm in the process of gathering MosaiX data for you to work with, but I
don't have time-lapse data (we don't work on live tissue). Perhaps
somebody else can help with additional datatypes?
hth,
Yves
From: Alexandre Kharlamov <kharlamovalexandre at gmail.com>
To: openslide-users at lists.andrew.cmu.edu
Date: 10-07-12 18:12
Subject: Re: Multiplane and fluorescence API design
Sent by:
openslide-users-bounces+sucaet=histogenex.com at lists.andrew.cmu.edu
Yves, when you say "not a pyramidal format", do you actually mean that no
lower-resolution copies
are stored in the file?
As for COM-object, I'm not sure we really need to go into their API. We'll
see...
On 07/10/12 21:38, Yves Sucaet wrote:
Hi Alexandre,
ZVI is used for a variety of things. You can have z-stacks, or merged
files. You can also have mosaic-files, which are essentially tiled (and
rather labor-intensive to create as well). Each tile again may have
mutiple channels and planes.
BUT, to the knowledge of the image analysts I consulted today: ZVI should
not be a pyramidal format.
Also: after installation of AxioVision you'll find a host of COM-objects.
It may be worth playing around with these (Any version of Visual Studio
will do, or even Office VBA), just to see how they organize their API.
Yves
From: Alexandre Kharlamov <kharlamovalexandre at gmail.com>
To: openslide-users at lists.andrew.cmu.edu
Date: 10-07-12 17:08
Subject: Re: Multiplane and fluorescence API design
Sent by:
openslide-users-bounces+sucaet=histogenex.com at lists.andrew.cmu.edu
Greetings!
Benjamin, further investigations are needed, namely I require a
large sample to answer most of your questions, because for all 6 samples I
saw, there is only
one resolution picture (1388x1040 pixels), and yes, all focal planes and
fluorescent channels
grayscale images are same resolution. There seems to be no combined color
image inside the
file. But this is only conclusions based on 6 similar type of samples, so
I'll be checking that.
- For fluorescence images, is it reasonable to return only one channel
per API call?
This is absolutely certain at this point, since, what can be seen clearly
from examples, the
different fluorescence images can be absolutely different, nothing in
common. And same
applies to the focus layers. The distance between layers in um is also
stored in the file.
- Is it critical to support more than 8 bits per channel? This would
require (non-trivial) additional support from Cairo and pixman.
This seems to be true, but this conclusion is only based on the fact that
the Zeiss native software
exports these images into 24-bit color jpegs, which is equivalent to
8-bits of data per pixel. However,
the file format itself does not seem to limit the data to 8-bits per
grayscale image.
- How should existing API behave when confronted with a fluorescence
image? Should openslide_read_region() return the first three
fluorescence channels?
I think this behaviour is reasonable and simplest to implement. However,
I'm pretty sure that the
color of every layer is stored in the file format, so it's equally
possible to return all channels in the
exact same form as it was intended by the person who saved this file.
- You will probably want to take a look at libgsf.
I will take a look, thanks.
BTW, is there a GUI frontend I can use to test the OpenSlide API? I can't
seem to find any.
Yves: I will install AxioVision tomorrow the first thing in the morning...
Best regards,
-Alexandre Kharlamov
On 07/10/12 13:56, Yves Sucaet wrote:
Hi list,
For those of you who are interested in this, it may be useful to play
around with some of the software that handles these filetypes (and
fluorescence imaging in itself). One such package that anyone can download
is AxioVision LE, which is available at http://www.zeiss.de/axiovision.
I've submitted four ZVI sample datasets to Benjamin yesterday. That in
combination with the files from Mailly Philippe should help you get
started, to appreciate what common tasks and operations are performed on
these data.
Another thought I've had: does the upcoming DICOM 145 format say anything
about this? As this WILL be the standard in the future (if the evolution
in radiology is any guide), it may be desirable for OpenSlide to model any
new functionality after DICOM, if they have any notes on such functions
yet.
Just my two cents,
Yves
From: Benjamin Gilbert <bgilbert at cs.cmu.edu>
To: openslide-users at lists.andrew.cmu.edu
Date: 09-07-12 20:01
Subject: Multiplane and fluorescence API design
Sent by:
openslide-users-bounces+sucaet=histogenex.com at lists.andrew.cmu.edu
Hello list,
Hamamatsu VMS and Zeiss ZVI both support multiplane images, and MIRAX
and ZVI both support fluorescence imaging. Either or both of these
features would require additions to the OpenSlide API. Consistent with
the rest of OpenSlide, any additional API should be as simple as
possible but not too much simpler.
I am interested in any comments on what an API for these features should
look like. Off the top of my head, the design issues include:
- For fluorescence images, is it reasonable to return only one channel
per API call?
- What principal metadata should be associated with each channel? (Is
it sufficient to provide a short name such as "Cy3"?) With each focal
plane?
- Can we assume that every focal plane and fluorescence channel at a
particular pyramid level has the same pixel dimensions?
- Should alpha be treated as just one of the channels, or should it be
returned alongside each channel? MIRAX could conceivably discard
different tiles in different channels. (I'm not sure whether the format
actually supports this, however.)
- Will every channel exist on every focal plane and pyramid level? If
not, is it sufficient to return fully-transparent alpha for the missing
channels?
- Is it critical to support more than 8 bits per channel? This would
require (non-trivial) additional support from Cairo and pixman.
- How should existing API behave when confronted with a fluorescence
image? Should openslide_read_region() return the first three
fluorescence channels?
--Benjamin Gilbert
_______________________________________________
openslide-users mailing list
openslide-users at lists.andrew.cmu.edu
https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users
WARNING: This e-mail, including any attachments, may contain CONFIDENTIAL
INFORMATION, including privileged and/or health information. It is for the
sole use of the intended recipients. Any unauthorized copying, disclosure,
distribution, reproduction, use or retention of this email or the
information in it, is strictly FORBIDDEN. If you are not an intended
recipient, please notify the sender immediately (REPLY this e-mail) and
permanently DELETE the related e-mail. Please be aware that this email and
replies to it may be monitored by the sender's company for quality
assurance, policy compliance and/or security purposes.
_______________________________________________
openslide-users mailing list
openslide-users at lists.andrew.cmu.edu
https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users
_______________________________________________
openslide-users mailing list
openslide-users at lists.andrew.cmu.edu
https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users
WARNING: This e-mail, including any attachments, may contain CONFIDENTIAL
INFORMATION, including privileged and/or health information. It is for the
sole use of the intended recipients. Any unauthorized copying, disclosure,
distribution, reproduction, use or retention of this email or the
information in it, is strictly FORBIDDEN. If you are not an intended
recipient, please notify the sender immediately (REPLY this e-mail) and
permanently DELETE the related e-mail. Please be aware that this email and
replies to it may be monitored by the sender's company for quality
assurance, policy compliance and/or security purposes.
_______________________________________________
openslide-users mailing list
openslide-users at lists.andrew.cmu.edu
https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users
_______________________________________________
openslide-users mailing list
openslide-users at lists.andrew.cmu.edu
https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users
--
WARNING: This e-mail, including any attachments, may contain CONFIDENTIAL INFORMATION, including privileged and/or health information. It is for the sole use of the intended recipients. Any unauthorized copying, disclosure, distribution, reproduction, use or retention of this email or the information in it, is strictly FORBIDDEN. If you are not an intended recipient, please notify the sender immediately (REPLY this e-mail) and permanently DELETE the related e-mail. Please be aware that this email and replies to it may be monitored by the sender's company for quality assurance, policy compliance and/or security purposes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/openslide-users/attachments/20120711/5668cf87/attachment.html
More information about the openslide-users
mailing list