New open image format

[Mathieu Malaterre]

On Thu, Jun 27, 2013 at 11:39 AM, Benjamin Gilbert <bgilbert at cs.cmu.edu> wrote:
> 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:
>>> 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?

Difficult to answer, since I picked exactly this solution for my DICOM
toolkit: GDCM. As you described I am providing 3 libjpeg
implementation (with different symbols mangling): 8, 12 and 16bits.
This is also the solution chosen by another popular DICOM toolkit:
DCMTK.
Technically nothing prevents you from using the 16bits version. I am
guessing some low level details may make the lib a little slower at
execution time, I have not tried it though.

When doing QA, I also use pvrg-jpeg [1]. Which is a single codec to
support sequential & progressive 8,12 and 16bits of ITU-81. The code
is not maintained so this is hardly a solution as of today.

And more recently a new JPEG implementation with decent support of the
standard came out:
https://github.com/thorfdbg/libjpeg
It is supposed to provide the full implementation of ITU-81, however
there has not been any recent commit. We'll see what comes out from
July 2nd meeting of the JPEG group.

As a word of caution, I doubt libjpeg-turbo support 12bits[2]. People
behind libjpeg-turbo are only interested toward the fastest possible
Sequential (progressive?) 8bits mode (which is the mode you convinced
OP not to use).

[1] http://packages.qa.debian.org/p/pvrg-jpeg.html
[2] http://sourceforge.net/p/libjpeg-turbo/discussion/1086868/thread/701941fc/

2cts
--
Mathieu