Zeiss ZVI file format support development for OpenSlide

Benjamin Gilbert bgilbert at cs.cmu.edu
Fri Jul 20 16:10:12 EDT 2012

On 07/19/2012 10:20 PM, Alexandre Kharlamov wrote:
> On 07/20/12 00:48, Benjamin Gilbert wrote:
>> openslide_read_region() is defined to fill the passed buffer with ARGB
>> image data.
> So what, I know how to convert greyscale to ARGB.

The application would need to allocate buffer space for four channels 
even though it only wants one.  It would then have to walk the buffer to 
extract the data for that channel.

>> /* Fluorescence, or arbitrary channel brightfield */
>> void openslide_read_region_channel(openslide_t *osr,
>>       openslide_cursor_t *cursor, uint8_t *buf, int channel,
>>       int64_t x, int64_t y, int level, int64_t w, int64_t h);
> I would suggest use unt16_t *buf, because a recent research showed
> that the greyscale images stored in ZVI format are actually 2-byte per
> pixel jpegs, despite my previous theory.

I think you mean 12-bit JPEGs?

Due to Cairo we can really only return the 8 high-order bits, but it 
might be worth leaving room in the ABI to fix that later.  However, 
there's a larger problem.

12-bit JPEG is not widely supported.  libjpeg can't even read 12-bit 
JPEGs unless it is specially compiled, in which case it no longer 
supports 8-bit JPEGs.  So, if we wanted the same OpenSlide binary to 
fully support ZVI *and* Hamamatsu *and* MIRAX, it'd need to be linked 
against two different copies of libjpeg.  The 12-bit version would have 
to have a different soname and all of its symbols would have to be 
renamed.  Not pretty.  And you'd still only get 8 bits out of Cairo.

(Actually this has been tried before: 

How common is BMP vs. JPEG in ZVI files?  Can they both be present in 
the same file?

--Benjamin Gilbert

More information about the openslide-users mailing list