Multiplane and fluorescence API design

Yves Sucaet sucaet at histogenex.com
Tue Jul 10 11:38:08 EDT 2012 

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/openslide-users/attachments/20120710/140ea30d/attachment.html

More information about the openslide-users mailing list