| |
 |
|
|
Science Forum Index » Compression Forum » Looking for a JPEG guru
Page 1 of 1
|
| Author |
Message |
| mathieu |
 Posted: Wed Mar 12, 2008 11:56 pm |
|
|
|
Guest
|
|
| Back to top |
|
| mathieu |
| Posted: Thu Mar 13, 2008 3:52 am |
|
|
|
Guest
|
On Mar 13, 2:34 pm, Thomas Richter <t...@math.tu-berlin.de> wrote:
Quote: mathieu schrieb:
Hi there,
I have an issue using the IJG on a 12bits JPEG file. The original
file is:
http://jpeg.sourceforge.net/ljpeg12/D_CLUNIE_RG3_JPLY.jpg
and the decompress file as given by djpeg:
http://jpeg.sourceforge.net/ljpeg12/D_CLUNIE_RG3_JPLY.pgm.gz
What I do not understand is that the library is giving me value that
are greater than 12bits data. I can see that right after the call to
jpeg_read_scanlines.
Which code do you use? The IJG code makes this a compile time decision whether 8bpp or
12bpp data is supported. If you decode 12bpp with the code compiled for 8bpp, strange things
will happen. See jmorecfg.h for the parameters.
Hi Thomas,
Have you actually tried what you said ? If so you will have surely
noticed that djpeg (compiled with 8bpp) will quickly returns with a
message:
Unsupported JPEG data precision 12
and a return value 1.
Please take me seriously, I did do my homework, I am not simply
whinning in some random newsgroup. I have written the proper
cmakelist.txt file for ijg, wich allows compilation of executables for
both 8bpp and 12bpp, see:
http://jpeg.svn.sourceforge.net/viewvc/jpeg/jpeg-6b/
And because I am paranoid, I also rerun the same experiment using
IJG + lossless patch from Ken Murchison. I even tried decompressing
the JPEG data using the 16bpp decompressor (yes you can have 16bpp in
lossless mode), see:
http://jpeg.svn.sourceforge.net/viewvc/jpeg/ljpeg-6b/
Regards,
-Mathieu |
|
|
| Back to top |
|
| Thomas Richter |
| Posted: Thu Mar 13, 2008 8:34 am |
|
|
|
Guest
|
mathieu schrieb:
Which code do you use? The IJG code makes this a compile time decision whether 8bpp or
12bpp data is supported. If you decode 12bpp with the code compiled for 8bpp, strange things
will happen. See jmorecfg.h for the parameters.
So long,
Thomas |
|
|
| Back to top |
|
| Thomas Richter |
| Posted: Thu Mar 13, 2008 10:12 am |
|
|
|
Guest
|
mathieu schrieb:
Quote: On Mar 13, 2:34 pm, Thomas Richter <t...@math.tu-berlin.de> wrote:
mathieu schrieb:
Hi there,
I have an issue using the IJG on a 12bits JPEG file. The original
file is:
http://jpeg.sourceforge.net/ljpeg12/D_CLUNIE_RG3_JPLY.jpg
and the decompress file as given by djpeg:
http://jpeg.sourceforge.net/ljpeg12/D_CLUNIE_RG3_JPLY.pgm.gz
What I do not understand is that the library is giving me value that
are greater than 12bits data. I can see that right after the call to
jpeg_read_scanlines.
Which code do you use? The IJG code makes this a compile time decision whether 8bpp or
12bpp data is supported. If you decode 12bpp with the code compiled for 8bpp, strange things
will happen. See jmorecfg.h for the parameters.
Hi Thomas,
Have you actually tried what you said ?
I'm not an IJG support person. If you want support from IJG, please contact IJG.
If you need a 12bpp code with support, buy the support. After all "you get what you
pay for". (-;
Quote: If so you will have surely
noticed that djpeg (compiled with 8bpp) will quickly returns with a
message:
Unsupported JPEG data precision 12
and a return value 1.
Nope:
thor@latraviata:~/src/jpeg6b-12> hexdump -C /store/pics/3d/lung_sample/001.raw.pgm | less
00000000 50 35 0a 35 31 32 20 35 31 32 0a 34 30 39 35 0a |P5.512 512.4095.|
00000010 00 19 00 67 00 48 00 2a 00 0c 00 00 00 19 00 4d |...g.H.*.......M|
thor@latraviata:~/src/jpeg6b-12> cjpeg /store/pics/3d/lung_sample/001.raw.pgm >out.jpg
thor@latraviata:~/src/jpeg6b-12>
Works. The image is nevertheless corrupt, likely the PPM saved or interpreted
by cjpeg or djpeg is little-endian, not big-endian - but I don't know. The output is
12bpp, and reconstructed with djpeg in this directory, the 8bpp code refuses to read
exactly with the mentioned error message. The 12bpp code reconstructs the image
(to nonsense, though).
Quote: Please take me seriously, I did do my homework, I am not simply
whinning in some random newsgroup. I have written the proper
cmakelist.txt file for ijg, wich allows compilation of executables for
both 8bpp and 12bpp, see:
Apparently, not. I'm *not* your support person. All I did was the above modification,
and yes, it did what it should do. There's some other bug lurking in the code, though:
If you look into jinclude.h, you find that JFREAD() is a simple fread, which of course
gets the endianness wrong on a little endian machine like this one. It also performs
a rescale on reading - not sure whether you want or need this.
Well, good luck fixing the code - if you need support, again, it would cost some
money, sorry, but not everything's for free in this universe. (-;
So long,
Thomas |
|
|
| Back to top |
|
| mathieu |
| Posted: Mon Mar 17, 2008 1:41 am |
|
|
|
Guest
|
On Mar 13, 2:52 pm, mathieu <mathieu.malate...@gmail.com> wrote:
Quote: On Mar 13, 2:34 pm, Thomas Richter <t...@math.tu-berlin.de> wrote:
mathieu schrieb:
Hi there,
I have an issue using the IJG on a 12bits JPEG file. The original
file is:
http://jpeg.sourceforge.net/ljpeg12/D_CLUNIE_RG3_JPLY.jpg
and the decompress file as given by djpeg:
http://jpeg.sourceforge.net/ljpeg12/D_CLUNIE_RG3_JPLY.pgm.gz
What I do not understand is that the library is giving me value that
are greater than 12bits data. I can see that right after the call to
jpeg_read_scanlines.
Which code do you use? The IJG code makes this a compile time decision whether 8bpp or
12bpp data is supported. If you decode 12bpp with the code compiled for 8bpp, strange things
will happen. See jmorecfg.h for the parameters.
Hi Thomas,
Have you actually tried what you said ? If so you will have surely
noticed that djpeg (compiled with 8bpp) will quickly returns with a
message:
Unsupported JPEG data precision 12
and a return value 1.
Please take me seriously, I did do my homework, I am not simply
whinning in some random newsgroup. I have written the proper
cmakelist.txt file for ijg, wich allows compilation of executables for
both 8bpp and 12bpp, see:
http://jpeg.svn.sourceforge.net/viewvc/jpeg/jpeg-6b/
And because I am paranoid, I also rerun the same experiment using
IJG + lossless patch from Ken Murchison. I even tried decompressing
the JPEG data using the 16bpp decompressor (yes you can have 16bpp in
lossless mode), see:
http://jpeg.svn.sourceforge.net/viewvc/jpeg/ljpeg-6b/
Just for record, I did step through the IJG library...to find out
there was nothing wrong 
The issue only appear later on, when doing the monochrome inversion
(the JPEG stream was stored in a DICOM file). The file is incorrectly
reported as being 10bits data while the max value stored in JPEG
stream is 1024.
Thanks to Tom Lane for his help
-Mathieu |
|
|
| Back to top |
|
| Thomas Richter |
| Posted: Mon Mar 17, 2008 4:46 pm |
|
|
|
Guest
|
mathieu wrote:
Quote: Just for record, I did step through the IJG library...to find out
there was nothing wrong
The issue only appear later on, when doing the monochrome inversion
(the JPEG stream was stored in a DICOM file). The file is incorrectly
reported as being 10bits data while the max value stored in JPEG
stream is 1024.
Hmm. Probably not quite. Why haven't you said this is DICOM?
DICOM uses 12bpp JPEG to store a variable bit depth signal > 8bpp
(actually, there is no other way to do this since lossy JPEG only
understands 12bpp or 8bpp). JPEG also defines a clamping algorithm
(implemented in djpeg) that removes "out of range" pixels and fixes them
to the maximum or minimum value. Those pixel values can appear by
the Gibbs phenomenon at edges - it goes for all lossy transforms that
in one way or another operate in frequency space.
What is now to be done is to clamp the values in the stream back to the
range where they belong, i.e. a value of 1024 is also invalid for a
10bpp DICOM image, but rather should be 1023. But as djpeg doesn't know
that this is a 10bpp image, it clamps for 12bpp and not for 10bpp.
So long,
Thomas |
|
|
| Back to top |
|
| |
|
Page 1 of 1
All times are GMT - 5 Hours
The time now is Sun Oct 12, 2008 4:05 pm
|
|