Implementation of a CZI (Zeiss) driver

[BALBASTRE Yael 237482 Thésard]

Hi all,

A little follow up on messages from last week.

JpegXR is the default compression mode in Zen (Zeiss software), and is thus used in all files if a jpeg compression mode wasn't actively specified. A "Lemple-Ziff-Welch" mode is also present, though it is said not to be used in widefield acquisitions.

For now I am only working with jpeg compressed images, but it will be necessary to add a jpegXR decoder. I saw that jxrlib existed, but did not studied it in detail.

An issue I have right now is that no grid position (row/column) is specified for the tiles. Only their position relative to a global landmark is given. I hope it is possible to compute it  back.

Best regards,
Yaël Balbastre

________________________________________
From: openslide-users-bounces+yael.balbastre=cea.fr at lists.andrew.cmu.edu [openslide-users-bounces+yael.balbastre=cea.fr at lists.andrew.cmu.edu] on behalf of Benjamin Gilbert [bgilbert at cs.cmu.edu]
Sent: Friday, June 13, 2014 5:52 AM
To: openslide-users at lists.andrew.cmu.edu
Subject: Re: Implementation of a CZI (Zeiss) driver

On 06/12/2014 11:08 AM, BALBASTRE Yael 237482 Thésard wrote:
> 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.

Is JPEG XR often used in these files?  Are other image formats supported
besides JPEG and JPEG XR?

> 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...).

It's a valid concern.  OpenSlide tends to have fewer, large modules
rather than many smaller ones, and this has benefits and drawbacks.  One
benefit is that individual source files only expose symbols that are
useful to the library as a whole [*], and not internal implementation
details.  It does lead to cases like the Hamamatsu driver, which has
support for three formats in a single source file.  (I've never been
entirely comfortable with that, but they *are* all the same vendor, and
they do share code.)

* Exceptions: openslide-tables, which is generated at build time, and
openslide-jdatasrc, which is copied verbatim from libjpeg.

We may want to reconsider this layout at some point, but I don't think
it's causing us real pain yet.  You can (and should) still create a
clean internal API within the single source file.  (MIRAX does not do
this.)  If we restructure the code later on, that will make it easy to
move the container parsing into a separate file.

--Benjamin Gilbert

_______________________________________________
openslide-users mailing list
openslide-users at lists.andrew.cmu.edu
https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users