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