New open image format

Benjamin Gilbert bgilbert at cs.cmu.edu
Thu Jun 27 05:39:42 EDT 2013


On 06/27/2013 03:06 AM, Mathieu Malaterre wrote:
> On Thu, Jun 27, 2013 at 5:56 AM, Benjamin Gilbert <bgilbert at cs.cmu.edu> wrote:
>> AFAICT, the only plausible alternative is to create Yet Another TIFF
>> Variant.  Leica SCN does this reasonably well
>
> When Benjamin use the word "plausible", you should be very worried ;)
> I would suggest reading issue #49 [1], excerpts:
>
> "First, we need a custom TIFF parser, libtiff isn't up to the task"

That's for Hamamatsu NDPI, not SCN.  NDPI is a good example of how not 
to do things.

>> but open-source support for 12-bit JPEG is abysmal.
> JPEG (ITU-81) is indeed not the best choice today. However it's
> support is extremely wide, and is a no-op when you have to deal with
> web-apps. As mentioned before you will be forced to use the lossy
> 8bits mode of ITU-81, since support from other part of this standard
> is not as widely spread ("abysmal" is a bit strong, when you look at
> open-source DICOM implementations).

The only [C-compatible] open-source 12-bit JPEG implementations that I 
know of are libjpeg and libjpeg-turbo, and those support it as a 
*compile-time* option.  To build an application that can read both 8-bit 
and 12-bit JPEG, you have to build a second copy of libjpeg after 
patching the source to rename all the symbols and change the soname.

Do you know of a better way?

> I would rephrase "you do need to store tiles" into:
> - you need a fast API to access tiles within your slide.

Well, yeah, fair enough.

--Benjamin Gilbert



More information about the openslide-users mailing list