Zeiss ZVI file format support development for OpenSlide
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?
More information about the openslide-users