<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
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:
<blockquote
cite="mid:OFB4855275.FEDF2263-ONC1257A37.005557D1-C1257A37.0055E3A9@histogenex.com"
type="cite"><font face="sans-serif" size="2">Hi Alexandre,</font>
<br>
<br>
<font face="sans-serif" size="2">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>
<br>
<br>
<font face="sans-serif" size="2">BUT, to the knowledge of the
image analysts
I consulted today: ZVI should not be a pyramidal format.</font>
<br>
<br>
<font face="sans-serif" size="2">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>
<br>
<br>
<font face="sans-serif" size="2">Yves</font>
<br>
<br>
<br>
<br>
<br>
<font color="#5f5f5f" face="sans-serif" size="1">From:
</font><font face="sans-serif" size="1">Alexandre Kharlamov
<a class="moz-txt-link-rfc2396E" href="mailto:kharlamovalexandre@gmail.com"><kharlamovalexandre@gmail.com></a></font>
<br>
<font color="#5f5f5f" face="sans-serif" size="1">To:
</font><font face="sans-serif" size="1"><a class="moz-txt-link-abbreviated" href="mailto:openslide-users@lists.andrew.cmu.edu">openslide-users@lists.andrew.cmu.edu</a></font>
<br>
<font color="#5f5f5f" face="sans-serif" size="1">Date:
</font><font face="sans-serif" size="1">10-07-12 17:08</font>
<br>
<font color="#5f5f5f" face="sans-serif" size="1">Subject:
</font><font face="sans-serif" size="1">Re: Multiplane
and fluorescence API design</font>
<br>
<font color="#5f5f5f" face="sans-serif" size="1">Sent by:
</font><font face="sans-serif" size="1"><a class="moz-txt-link-abbreviated" href="mailto:openslide-users-bounces+sucaet=histogenex.com@lists.andrew.cmu.edu">openslide-users-bounces+sucaet=histogenex.com@lists.andrew.cmu.edu</a></font>
<br>
<hr noshade="noshade">
<br>
<br>
<br>
<font size="3">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.<br>
</font><tt><font size="2"><br>
- For fluorescence images, is it reasonable to return only one
channel
<br>
per API call?<br>
</font></tt><font size="3"><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.<br>
</font><tt><font size="2"><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.<br>
</font><tt><font size="2"><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>
<br>
<tt><font size="3">- You will probably want to take a look at
libgsf.</font></tt>
<br>
<font size="3">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>
<br>
<font face="sans-serif" size="2">Hi list,</font><font size="3"> <br>
</font><font face="sans-serif" size="2"><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 moz-do-not-send="true"
href="http://www.zeiss.de/axiovision"><font color="blue"
face="sans-serif" size="2"><u>http://www.zeiss.de/axiovision</u></font></a><font
face="sans-serif" size="2">.
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">
<br>
</font><font face="sans-serif" size="2"><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"> <br>
</font><font face="sans-serif" size="2"><br>
Just my two cents,</font><font size="3"> <br>
</font><font face="sans-serif" size="2"><br>
Yves</font><font size="3"> <br>
<br>
<br>
</font><font color="#5f5f5f" face="sans-serif" size="1"><br>
From: </font><font face="sans-serif" size="1">Benjamin
Gilbert </font><a moz-do-not-send="true"
href="mailto:bgilbert@cs.cmu.edu"><font color="blue"
face="sans-serif" size="1"><u><bgilbert@cs.cmu.edu></u></font></a><font
size="3">
</font><font color="#5f5f5f" face="sans-serif" size="1"><br>
To: </font><a moz-do-not-send="true"
href="mailto:openslide-users@lists.andrew.cmu.edu"><font
color="blue" face="sans-serif" size="1"><u>openslide-users@lists.andrew.cmu.edu</u></font></a><font
size="3">
</font><font color="#5f5f5f" face="sans-serif" size="1"><br>
Date: </font><font face="sans-serif" size="1">09-07-12
20:01</font><font size="3"> </font><font color="#5f5f5f"
face="sans-serif" size="1"><br>
Subject: </font><font face="sans-serif" size="1">Multiplane
and
fluorescence API design</font><font size="3"> </font><font
color="#5f5f5f" face="sans-serif" size="1"><br>
Sent by: </font><a moz-do-not-send="true"
href="mailto:openslide-users-bounces+sucaet=histogenex.com@lists.andrew.cmu.edu"><font
color="blue" face="sans-serif" size="1"><u>openslide-users-bounces+sucaet=histogenex.com@lists.andrew.cmu.edu</u></font></a><font
size="3">
<br>
</font>
<hr noshade="noshade"><font size="3"><br>
<br>
</font><tt><font size="2"><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><tt><font color="blue"
size="2"><u><br>
</u></font></tt><a moz-do-not-send="true"
href="mailto:openslide-users@lists.andrew.cmu.edu"><tt><font
color="blue" size="2"><u>openslide-users@lists.andrew.cmu.edu</u></font></tt></a><font
color="blue" size="3"><u><br>
</u></font><a moz-do-not-send="true"
href="https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users"><tt><font
color="blue" size="2"><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 moz-do-not-send="true"
href="mailto:openslide-users@lists.andrew.cmu.edu"><tt><font
color="blue" size="3"><u>openslide-users@lists.andrew.cmu.edu</u></font></tt></a><tt><font
size="3"><br>
</font></tt><a moz-do-not-send="true"
href="https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users"><tt><font
color="blue" size="3"><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>
<a class="moz-txt-link-abbreviated" href="mailto:openslide-users@lists.andrew.cmu.edu">openslide-users@lists.andrew.cmu.edu</a><br>
</font></tt><a moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
openslide-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:openslide-users@lists.andrew.cmu.edu">openslide-users@lists.andrew.cmu.edu</a>
<a class="moz-txt-link-freetext" href="https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users">https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users</a>
</pre>
</blockquote>
<br>
</body>
</html>