<font size=2 face="sans-serif">Hi Alexandre,</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">You should be aware that the ZiImage
is set up as a 6D hyperspace. A ZiRawImage represents a 2D pixel matrix,
the 'real' image</font>
<br>
<br><font size=2 face="sans-serif">In addition, each ZiRawImage contains
information about its place within this hyperspace, which is defined as
follows:</font>
<br><font size=2 face="sans-serif">* P = tile image within the XY plane
(MosaiX)</font>
<br><font size=2 face="sans-serif">* Z = depth coordinate</font>
<br><font size=2 face="sans-serif">* T = time coordinate</font>
<br><font size=2 face="sans-serif">* C = channel coordinate</font>
<br><font size=2 face="sans-serif">* S = scene coordinate (semantically
distinct objects, e.g. a cell)</font>
<br><font size=2 face="sans-serif">* A = view coordinate (arbitray view,
e.g. 3D view)</font>
<br>
<br><font size=2 face="sans-serif">You can see how a file is organized
in Axiovision by activating the Tree view (Tools > Options > Display)</font>
<br>
<br><font size=2 face="sans-serif">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?).</font>
<br>
<br><font size=2 face="sans-serif">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?</font>
<br>
<br><font size=2 face="sans-serif">hth,</font>
<br>
<br><font size=2 face="sans-serif">Yves</font>
<br>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Alexandre Kharlamov
<kharlamovalexandre@gmail.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">openslide-users@lists.andrew.cmu.edu</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">10-07-12 18:12</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: Multiplane
and fluorescence API design</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">openslide-users-bounces+sucaet=histogenex.com@lists.andrew.cmu.edu</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3>Yves, when you say "not a pyramidal format",
do you actually mean that no lower-resolution copies<br>
are stored in the file?<br>
<br>
As for COM-object, I'm not sure we really need to go into their API. We'll
see...<br>
<br>
On 07/10/12 21:38, Yves Sucaet wrote: </font>
<br><font size=2 face="sans-serif">Hi Alexandre,</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
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.</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
BUT, to the knowledge of the image analysts I consulted today: ZVI should
not be a pyramidal format.</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
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.</font><font size=3>
<br>
</font><font size=2 face="sans-serif"><br>
Yves</font><font size=3> <br>
<br>
<br>
<br>
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
From: </font><font size=1 face="sans-serif">Alexandre
Kharlamov </font><a href=mailto:kharlamovalexandre@gmail.com><font size=1 color=blue face="sans-serif"><u><kharlamovalexandre@gmail.com></u></font></a><font size=3>
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
To: </font><a href="mailto:openslide-users@lists.andrew.cmu.edu"><font size=1 color=blue face="sans-serif"><u>openslide-users@lists.andrew.cmu.edu</u></font></a><font size=3>
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
Date: </font><font size=1 face="sans-serif">10-07-12
17:08</font><font size=3> </font><font size=1 color=#5f5f5f face="sans-serif"><br>
Subject: </font><font size=1 face="sans-serif">Re:
Multiplane and fluorescence API design</font><font size=3> </font><font size=1 color=#5f5f5f face="sans-serif"><br>
Sent by: </font><a href="mailto:openslide-users-bounces+sucaet=histogenex.com@lists.andrew.cmu.edu"><font size=1 color=blue face="sans-serif"><u>openslide-users-bounces+sucaet=histogenex.com@lists.andrew.cmu.edu</u></font></a><font size=3>
<br>
</font>
<hr noshade><font size=3><br>
<br>
<br>
Greetings!<br>
<br>
Benjamin, further investigations are needed, namely I require a<br>
large sample to answer most of your questions, because for all 6 samples
I saw, there is only<br>
one resolution picture (1388x1040 pixels), and yes, all focal planes and
fluorescent channels<br>
grayscale images are same resolution. There seems to be no combined color
image inside the<br>
file. But this is only conclusions based on 6 similar type of samples,
so I'll be checking that.</font><tt><font size=2><br>
<br>
- For fluorescence images, is it reasonable to return only one channel
<br>
per API call?</font></tt><font size=3><br>
<br>
This is absolutely certain at this point, since, what can be seen clearly
from examples, the<br>
different fluorescence images can be absolutely different, nothing in common.
And same<br>
applies to the focus layers. The distance between layers in um is also
stored in the file.</font><tt><font size=2><br>
<br>
- Is it critical to support more than 8 bits per channel? This would
<br>
require (non-trivial) additional support from Cairo and pixman.</font></tt><font size=3><br>
<br>
This seems to be true, but this conclusion is only based on the fact that
the Zeiss native software<br>
exports these images into 24-bit color jpegs, which is equivalent to 8-bits
of data per pixel. However,<br>
the file format itself does not seem to limit the data to 8-bits per grayscale
image.</font><tt><font size=2><br>
<br>
- How should existing API behave when confronted with a fluorescence <br>
image? Should openslide_read_region() return the first three <br>
fluorescence channels?</font></tt><font size=3><br>
<br>
I think this behaviour is reasonable and simplest to implement. However,
I'm pretty sure that the<br>
color of every layer is stored in the file format, so it's equally possible
to return all channels in the<br>
exact same form as it was intended by the person who saved this file.<br>
</font><tt><font size=3><br>
- You will probably want to take a look at libgsf.</font></tt><font size=3>
<br>
I will take a look, thanks.<br>
<br>
BTW, is there a GUI frontend I can use to test the OpenSlide API? I can't
seem to find any.<br>
<br>
Yves: I will install AxioVision tomorrow the first thing in the morning...<br>
<br>
Best regards,<br>
<br>
-Alexandre Kharlamov<br>
<br>
On 07/10/12 13:56, Yves Sucaet wrote: </font><font size=2 face="sans-serif"><br>
Hi list,</font><font size=3> </font><font size=2 face="sans-serif"><br>
<br>
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 </font><a href=http://www.zeiss.de/axiovision><font size=2 color=blue face="sans-serif"><u>http://www.zeiss.de/axiovision</u></font></a><font size=2 face="sans-serif">.
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.</font><font size=3>
</font><font size=2 face="sans-serif"><br>
<br>
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.</font><font size=3> </font><font size=2 face="sans-serif"><br>
<br>
Just my two cents,</font><font size=3> </font><font size=2 face="sans-serif"><br>
<br>
Yves</font><font size=3> <br>
<br>
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
<br>
From: </font><font size=1 face="sans-serif">Benjamin
Gilbert </font><a href=mailto:bgilbert@cs.cmu.edu><font size=1 color=blue face="sans-serif"><u><bgilbert@cs.cmu.edu></u></font></a><font size=3>
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
To: </font><a href="mailto:openslide-users@lists.andrew.cmu.edu"><font size=1 color=blue face="sans-serif"><u>openslide-users@lists.andrew.cmu.edu</u></font></a><font size=3>
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
Date: </font><font size=1 face="sans-serif">09-07-12
20:01</font><font size=3> </font><font size=1 color=#5f5f5f face="sans-serif"><br>
Subject: </font><font size=1 face="sans-serif">Multiplane
and fluorescence API design</font><font size=3> </font><font size=1 color=#5f5f5f face="sans-serif"><br>
Sent by: </font><a href="mailto:openslide-users-bounces+sucaet=histogenex.com@lists.andrew.cmu.edu"><font size=1 color=blue face="sans-serif"><u>openslide-users-bounces+sucaet=histogenex.com@lists.andrew.cmu.edu</u></font></a><font size=3>
<br>
</font>
<hr noshade><font size=3><br>
</font><tt><font size=2><br>
<br>
Hello list,<br>
<br>
Hamamatsu VMS and Zeiss ZVI both support multiplane images, and MIRAX <br>
and ZVI both support fluorescence imaging. Either or both of these
<br>
features would require additions to the OpenSlide API. Consistent
with <br>
the rest of OpenSlide, any additional API should be as simple as <br>
possible but not too much simpler.<br>
<br>
I am interested in any comments on what an API for these features should
<br>
look like. Off the top of my head, the design issues include:<br>
<br>
- For fluorescence images, is it reasonable to return only one channel
<br>
per API call?<br>
<br>
- What principal metadata should be associated with each channel? (Is
<br>
it sufficient to provide a short name such as "Cy3"?) With
each focal <br>
plane?<br>
<br>
- Can we assume that every focal plane and fluorescence channel at a <br>
particular pyramid level has the same pixel dimensions?<br>
<br>
- Should alpha be treated as just one of the channels, or should it be
<br>
returned alongside each channel? MIRAX could conceivably discard
<br>
different tiles in different channels. (I'm not sure whether the
format <br>
actually supports this, however.)<br>
<br>
- Will every channel exist on every focal plane and pyramid level? If
<br>
not, is it sufficient to return fully-transparent alpha for the missing
<br>
channels?<br>
<br>
- Is it critical to support more than 8 bits per channel? This would
<br>
require (non-trivial) additional support from Cairo and pixman.<br>
<br>
- How should existing API behave when confronted with a fluorescence <br>
image? Should openslide_read_region() return the first three <br>
fluorescence channels?<br>
<br>
--Benjamin Gilbert<br>
_______________________________________________<br>
openslide-users mailing list</font></tt><font size=3 color=blue><u><br>
</u></font><a href="mailto:openslide-users@lists.andrew.cmu.edu"><tt><font size=2 color=blue><u>openslide-users@lists.andrew.cmu.edu</u></font></tt></a><font size=3 color=blue><u><br>
</u></font><a href="https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users"><tt><font size=2 color=blue><u>https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users</u></font></tt></a><font size=3><br>
<br>
<br>
</font>
<hr><font size=3><br>
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. <br>
<br>
</font><tt><font size=3><br>
_______________________________________________<br>
openslide-users mailing list</font></tt><font size=3 color=blue><u><br>
</u></font><a href="mailto:openslide-users@lists.andrew.cmu.edu"><tt><font size=3 color=blue><u>openslide-users@lists.andrew.cmu.edu</u></font></tt></a><font size=3 color=blue><u><br>
</u></font><a href="https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users"><tt><font size=3 color=blue><u>https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users</u></font></tt></a><font size=3><br>
</font><tt><font size=2><br>
_______________________________________________<br>
openslide-users mailing list</font></tt><tt><font size=2 color=blue><u><br>
</u></font></tt><a href="mailto:openslide-users@lists.andrew.cmu.edu"><tt><font size=2 color=blue><u>openslide-users@lists.andrew.cmu.edu</u></font></tt></a><font size=3 color=blue><u><br>
</u></font><a href="https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users"><tt><font size=2 color=blue><u>https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users</u></font></tt></a><font size=3><br>
<br>
<br>
</font>
<hr><font size=3><br>
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. <br>
<br>
</font>
<br><tt><font size=3>_______________________________________________<br>
openslide-users mailing list<br>
</font></tt><a href="mailto:openslide-users@lists.andrew.cmu.edu"><tt><font size=3 color=blue><u>openslide-users@lists.andrew.cmu.edu</u></font></tt></a><tt><font size=3><br>
</font></tt><a href="https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users"><tt><font size=3 color=blue><u>https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users</u></font></tt></a><tt><font size=3><br>
</font></tt>
<br><tt><font size=2>_______________________________________________<br>
openslide-users mailing list<br>
openslide-users@lists.andrew.cmu.edu<br>
</font></tt><a href="https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users"><tt><font size=2>https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users</font></tt></a><tt><font size=2><br>
</font></tt>
<br>
<br>
<HR><BR>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.
<br>