Implementation of a CZI (Zeiss) driver

[Adam Goode]

Regarding JPEG XR: this library looks extremely promising, though it
would need to get shared library (and probably pkg-config) support.
Then I suspect it would be packagable in Fedora.

https://jxrlib.codeplex.com/


Adam


On Thu, Jun 12, 2014 at 2:45 PM, Dmitry Fedorov <fedorov at ece.ucsb.edu> wrote:
> 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
> _________________________________
> _______________________________________________
> openslide-users mailing list
> openslide-users at lists.andrew.cmu.edu
> https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users