<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
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>
<br>
<tt><font size="2">- For fluorescence images, is it reasonable to
return only one channel
<br>
per API call?<br>
<br>
</font></tt>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>
<br>
<tt><font size="2">- Is it critical to support more than 8 bits per
channel? This would
<br>
require (non-trivial) additional support from Cairo and pixman.<br>
</font></tt><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>
<br>
<tt><font size="2">- 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><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>
<br>
<pre wrap="">- You will probably want to take a look at libgsf.</pre>
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:
<blockquote
cite="mid:OFFA90709B.55BF0CD6-ONC1257A37.002AEEE3-C1257A37.002B9929@histogenex.com"
type="cite"><font face="sans-serif" size="2">Hi list,</font>
<br>
<br>
<font face="sans-serif" size="2">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 face="sans-serif"
size="2">http://www.zeiss.de/axiovision</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>
<br>
<br>
<font face="sans-serif" size="2">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>
<br>
<br>
<font face="sans-serif" size="2">Just my two cents,</font>
<br>
<br>
<font face="sans-serif" size="2">Yves</font>
<br>
<br>
<br>
<br>
<font color="#5f5f5f" face="sans-serif" size="1">From:
</font><font face="sans-serif" size="1">Benjamin Gilbert
<a class="moz-txt-link-rfc2396E" href="mailto:bgilbert@cs.cmu.edu"><bgilbert@cs.cmu.edu></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">09-07-12 20:01</font>
<br>
<font color="#5f5f5f" face="sans-serif" size="1">Subject:
</font><font face="sans-serif" size="1">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>
<tt><font size="2">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<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>