Implementation of a CZI (Zeiss) driver

[Dmitry Fedorov]

Hi,

We use OpenSlide with the BisQue system for cloud-based management,
annotations and analysis and also would like to see CZI whole slide
support in OpenSlide. I would support this endeavour and volunteer to
help with coding! I agree with Yael in that CZI file format parsing
should be written as a separate file/class since additional libraries
would already be needed, like jpeg xr.

I would suggest one additional requirement for the CZI reader. Since
Zeiss CZI file container may hold many 6D image variants and I use
another decoder for those it would be great if the openslide would
only accept the file if it is a 2D pyramidal tiled RGB image. This is
because OpenSlide does not support n-d images nor arbitrary number of
channels per image.

Dmitry


On Thu, Jun 12, 2014 at 8:08 AM, BALBASTRE Yael 237482 Thésard
<yael.balbastre at cea.fr> wrote:
> Hi,
>
> Since our lab has acquired a Zeiss Axio-Scan scanner, we are interested in
> adding a czi reader to OpenSlide (that we are already using to read other
> WSI images). We already had a few contacts with Benjamin Gilbert, but it
> must be better to ask my questions using this mailing list.
>
> The CZI format has been entirely specified by Zeiss and, contrary to most
> formats present in OpenSlide, does not use a tiff base, even though the
> principles are shared. A file contains several subblocks, each containing a
> subimage which can be compressed (jpeg or jpegXR mainly) or not, as well as
> metadata stored in the file as xml blocks.
>
> To follow up the question I asked to Mr Gilbert regarding the file supposed
> to host czi-related code, I am not comfortable with having all of it in a
> single openslide-zeiss-vendor.c source, especially since it would deal both
> with file stream reading (decoding of the hard
> directories/subblocks/attachments structure) and with more high-level,
> microscopy-related treatment (metadata, grid-building, subimages
> decoding...).
> I would rather have the stream reading separated and placed in a different
> source file along with a clear API (which would resemble the tiff decoder).
> I understand that it is different from what has been done before, but maybe
> the issue had never been on the table because none of the previous formats
> had such a specification ? (the only one I see coming close is MIRAX).
> If you still prefer to have everything in one big source, I will obviously
> go this way.
>
> Thanks a lot for your time.
>
> Best regards,
> Yaël Balbastre
>
> Yaël Balbastre - PhD student
> CEA/DSV/I²BM/MIRCen/LMN
> Image Processing Team - bioPICSEL
> 18 route du Panorama - BP6
> 92265 FONTENAY-AUX-ROSES CEDEX
> FRANCE
> T 33 (1) 46 54 92 83
>
> _______________________________________________
> openslide-users mailing list
> openslide-users at lists.andrew.cmu.edu
> https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users
>



-- 
__________________________________

Dmitry Fedorov Levit <dima at dimin.net>
Web: http://www.dimin.net/
__________________________________

Center for Bio-Image Informatics:
  <http://www.bioimage.ucsb.edu/>

Vision Research Lab, Electrical and Computer Engineering:
  <http://vision.ece.ucsb.edu/>

University of California, Santa Barbara
_________________________________