JPEG support for *both* 8 and 12 bits ? (IJG libjpeg ?)
Sébastien Barré
I'm trying to evaluate JPEG support for my small (and free) medical
image converter (dicom2).
As I do not want to reinvent the wheel, and as I know that they must be
very valuable jpeg libraries out there, I was wondering if anyone ever
met a library supporting *both* 8 and 12 bit depth.
I read the JPEG image compression faq as well as various other
resources, and had a look at the PVRG and IJG libjpeg. The latest seems
great, but the bit depth is a *compile-time* setting, you have to choose
whether the generated library will support 8 *or* 12 bits, but not both.
I quote a part of the IJG documentation : "If you need to include both
8- and 12-bit libraries in a single application, you could probably do
it by defining NEED_SHORT_EXTERNAL_NAMES for just one of the copies.
You'd have to access the 8-bit and 12-bit copies from separate
application source files. This is untested ... if you try it, we'd like
to hear whether it works!)".
=> looks tricky. I was wondering if anyone ever tested that feature, and
succeeded in using both depth at the same time. Any help would be
appreciated.
Thanks
--
Sebastien Barre : http://www.hds.utc.fr/~barre/medical/
Tom Lane
> I quote a part of the IJG documentation : "If you need to include both
> 8- and 12-bit libraries in a single application, you could probably do
> it by defining NEED_SHORT_EXTERNAL_NAMES for just one of the copies.
> You'd have to access the 8-bit and 12-bit copies from separate
> application source files. This is untested ... if you try it, we'd like
> to hear whether it works!)".
> => looks tricky. I was wondering if anyone ever tested that feature, and
> succeeded in using both depth at the same time. Any help would be
> appreciated.
It does work (that part of the docs needs updated ;-)). I've got
as-yet-unsubmitted patches to libtiff that allow libtiff to be built
with two libjpegs to handle either bit depth. I agree it's a pain,
but there are so few people who need to do this that modifying libjpeg
to allow run-time depth selection is not high on my to-do list.
Don't forget that for a full DICOM implementation, you'd also need
to find a lossless-JPEG library...
regards, tom lane
organizer, Independent JPEG Group
Sébastien Barré
(oops, you did override my follow-up :)
>It does work (that part of the docs needs updated ;-)). I've got
>as-yet-unsubmitted patches to libtiff that allow libtiff to be built
>with two libjpegs to handle either bit depth. I agree it's a pain,
Well, I'd really have a look at some insights regarding that point, if
you please. Any URL, text, or even these patches ?
>but there are so few people who need to do this that modifying libjpeg
>to allow run-time depth selection is not high on my to-do list.
I see. Forgive my naivety, but what were the design choices related to
that topic when the development started ? I mean, what is so hard (sorry
for the question) ? Handling various bit depths is something done by
most (or all) converters/formats/libs, like PNG, GIF and so on (libpng,
libgif, libtiff), that's the first time I see that kind of
"limitations".
>Don't forget that for a full DICOM implementation, you'd also need
>to find a lossless-JPEG library...
Yes, but once again I do not know what to choose. There seems to be even
less choices than with JPEG. I had a look at jpeg_ls, but could not find
any public 2.1. I had a look at loco, but sources are not available. Any
advices ?
Thanks *a lot*
--
Sebastien Barre : http://www.hds.utc.fr/~barre/
Jack Berlin
Our (Pegasus) medical toolkits are specifically designed for hi-grey
images, with support for JPEG, Lossless JPEG and Wavelet of up to 16 BPP
(Lossy JPEG only supports 8 or 12). Info and trial DLLs are
here: http://medical.jpg.com/
Please let me know if I can be of help.
Best wishes,
jack
PS - We do offer free copies of our tools for educational/research
projects.
--
http://www.pegasusimaging.com/ - Pegasus - BETTER DIGITAL IMAGING!
|------------------------------------------------------------------|
Sébastien Barré wrote:
>
> Hi
>
> I'm trying to evaluate JPEG support for my small (and free) medical
> image converter (dicom2).
>
> As I do not want to reinvent the wheel, and as I know that they must be
> very valuable jpeg libraries out there, I was wondering if anyone ever
> met a library supporting *both* 8 and 12 bit depth.
>
> I read the JPEG image compression faq as well as various other
> resources, and had a look at the PVRG and IJG libjpeg. The latest seems
> great, but the bit depth is a *compile-time* setting, you have to choose
> whether the generated library will support 8 *or* 12 bits, but not both.
>
> 8- and 12-bit libraries in a single application, you could probably do
> it by defining NEED_SHORT_EXTERNAL_NAMES for just one of the copies.
> You'd have to access the 8-bit and 12-bit copies from separate
> application source files. This is untested ... if you try it, we'd like
> to hear whether it works!)".
>
> => looks tricky. I was wondering if anyone ever tested that feature, and
> succeeded in using both depth at the same time. Any help would be
> appreciated.
>
David Clunie
> Don't forget that for a full DICOM implementation, you'd also need
> to find a lossless-JPEG library...
If one wanted to support all the JPEG transfer syntaxes (processes)
mentioned in the DICOM standard, one would have to support arithmetic
coding as well as the Huffman varieties, etc.
This is probably unrealistic, since only a very few of the processes
are ever used in practice, and since these are either negotiated at
network association time or defined a priori in a media application
profile, it is practical to support only a couple.
The lossless Huffman process is definitely the most widely used on
media.
david
--
David A. Clunie mailto:dcl...@idt.net
Director, Medical Imaging Technologies http://idt.net/~dclunie/
Quintiles Intelligent Imaging http://www.i2image.com/
521 Plymouth Rd #115 Work 610-238-0572 Fax -0578
Plymouth Meeting PA 19462 Home 570-897-7123 Fax -5117
Sébastien Barré
>Hi,
>Our (Pegasus) medical toolkits are specifically designed for hi-grey
>images, with support for JPEG, Lossless JPEG and Wavelet of up to 16 BPP
>(Lossy JPEG only supports 8 or 12). Info and trial DLLs are
>here: http://medical.jpg.com/
Thanks for the URL, but I'm looking for free libraries, not tools.
>PS - We do offer free copies of our tools for educational/research
>projects.
That's very interesting, I'll keep in touch with you.
Sébastien Barré
>The lossless Huffman process is definitely the most widely used on
>media.
Would you recommend me any public library to handle the losless huffman
process ?
Thanks
David Clunie
I generally prefer the Stanford PVRG code, but others use
the Cornell code, modified to handle > 8 bits.
There is a patch for the PVRG code to handle GE bugs available
from my web site also in case you encounter old GE DICOM MODs.
See the FAQ Part 7 for sites.
david
"Sébastien Barré" wrote:
> Would you recommend me any public library to handle the losless huffman
> process ?
david
Ken Murchison
"Sébastien Barré" wrote:
>
> David Clunie <dcl...@idt.net> wrote:
>
> >The lossless Huffman process is definitely the most widely used on
> >media.
>
> Would you recommend me any public library to handle the losless huffman
> process ?
I have a patch to IJG libjpeg v6b which adds support for the original
lossless scheme (ISO 10918-1). I have not yet updated all of the
documentation, but the code is pretty straight forward to use in that it
defaults to lossy and needs only one function call to setup lossless. I
can post this patch (or put it on our ftp site) if anyone is interested.
Regards,
Ken
--
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
mailto:k...@oceana.com Orchard Park, NY 14127
http://www.oceana.com 716-662-8973 x26
Sébastien Barré
>> Would you recommend me any public library to handle the losless huffman
>> process ?
>I have a patch to IJG libjpeg v6b which adds support for the original
>lossless scheme (ISO 10918-1). I have not yet updated all of the
>documentation, but the code is pretty straight forward to use in that it
>defaults to lossy and needs only one function call to setup lossless. I
>can post this patch (or put it on our ftp site) if anyone is interested.
I AM. Definitely. Thanks in advance.
Sébastien Barré
David Clunie <dcl...@idt.net> wrote:
>I generally prefer the Stanford PVRG code, but others use
>the Cornell code, modified to handle > 8 bits.
Do you mean that there is a patch to the Cornell code ?
>There is a patch for the PVRG code to handle GE bugs available
>from my web site also in case you encounter old GE DICOM MODs.
I saw it too. I'll first have a look at the PVRG code, but if David
Clunie is using it, then that might solve the problem :)
Thanks
Sébastien Barré
>I generally prefer the Stanford PVRG code,
I had a look at the archive, and found only one documentation (doc.ps).
Well, it is not straightforward, not as user/programmer-oriented as the
IJG lib, but that might do the trick, do you think so ? For now on I am
not sure it supports 12 bits, but I might read deeper...
Marco Eichelberg
Ken Murchison wrote in message <3725C10F...@oceana.com>...
>I have a patch to IJG libjpeg v6b which adds support for the original
>lossless scheme (ISO 10918-1). I have not yet updated all of the
>documentation, but the code is pretty straight forward to use in that it
>defaults to lossy and needs only one function call to setup lossless. I
>can post this patch (or put it on our ftp site) if anyone is interested.
Ken,
I think many people would be interested in this patch.
Please post it, or if it is too big, somebody would surely
volunteer to offer you FTP space for it (i.e. I would).
Best regards,
Marco Eichelberg
--
Marco Eichelberg <Eiche...@OFFIS.Uni-Oldenburg.DE>
OFFIS - Oldenburger F&E-Institut fuer Informatik-Werkzeuge und -Systeme
Escherweg 2, D-26121 Oldenburg, Germany
Tel: (+49)441-9722-147 Fax: (+49)441-9722-102
Ken Murchison
newgroups, a number of people have been interested in my patch which
adds lossless JPEG support (per the original spec -- not JPEG-LS) to
libjpeg v6b. I have decided to make this patch available via my ftp
site (ftp://ftp.oceana.com/pub/ljpeg-6b.tar.gz) for anyone who wants to
try it. The code has been tested on IRIX 6.x and Solaris 2.x using the
JPEG reference data and compliance images and has been verified at the
pixel level.
To install do the following:
1. Move the compressed tar into your jpeg-6b tree
2. Uncompress the archive (ie, gzip -d ljpeg-6b.tar.gz)
3. Extract the archive (ie, tar xvf ljpeg-6b.tar) which contains the
patch and 2 test images
4. Apply the patch (ie, patch < ljpeg-6b.patch)
Notes on compiling and use:
* The lossless support is a compile time option which can be set in
jmorecfg.h (the patch turns it on by default).
* I have only modified makefile.cfg, so if you're not using a UNIX box
or configure, then you'll have to modify the appropriate makefile.
* There are no changes to the existing API, so that no application code
needs to be changed (only a recompile).
* The only addition to the API is jpeg_simple_lossless() for creating
lossless images (see libjpeg.doc).
* A -lossless option has been added to cjpeg(1) for creating lossless
images (see man page for use).
* Read structure.doc for the internal changes to the library.
Other stuff:
* No warranties are expressed or implied, use this code at your own
risk. If you misdiagnose an MRI as a result of using this code, DO NOT
blame me ;-)
* Although I did all of the coding on this project, it would not have
been possible without all of the help that I received from Tom Lane.
Thanks Tom!
* The documentation for the lossless stuff is by no means complete. I
have taken a quick whack at the big stuff, but the best documentation is
the source itself.
* Because of the extra level of indirection added to the internal
structure, performance of the lossy codec may suffer slightly. I would
be interested in any feedback on this subject.
Please direct all comments/questions/suggestions/bug reports/patches to
me. Do NOT bother Tom Lane with this stuff -- he is not responsible for
this code (at least not yet ;-).
Enjoy
Ken Murchison
NOT done any dev work on Win32 (or Mac, OS2, etc) with this patch, but
feel free to give it a try and let me know how it works. Second, I do
not have first hand knowledge of a patch utility for non-UNIX
platforms. So for those who do not have access to a patch utility, I
have uploaded complete archives of my source tree in both zip and tar.gz
formats to ftp://ftp.oceana.com/pub.
as9...@my-dejanews.com
dcl...@idt.net wrote:
> Hi Sébastien
>
> I generally prefer the Stanford PVRG code, but others use
> the Cornell code, modified to handle > 8 bits.
>
> from my web site also in case you encounter old GE DICOM MODs.
>
>
> david
>
Does someone know where I can get the patch to Cornell library to make
it work for > 8 bits ?? ( Or are the changes required documented
somewhere ?? )
Thanks for help.
AS
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
Philippe Marzin
The posting from Kenneth is replicated below for convenience, hope this helps.
Philippe Marzin
GMATEK Informatique
http://perso.wanadoo.fr/gmatek
--
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
mailto:k...@oceana.com Orchard Park, NY 14127
http://www.oceana.com 716-662-8973 x26