Multiplane and fluorescence API design

Tue Jul 10 12:11:12 EDT 2012

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>_
> <mailto:bgilbert at cs.cmu.edu>
> To:        _openslide-users at lists.andrew.cmu.edu_
> <mailto: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_
> <mailto: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_
> <mailto: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_
> <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/openslide-users/attachments/20120710/022b3262/attachment.html 