Re: Looking for a JPEG guru

mathieu schrieb:
On Mar 13, 2:34 pm, Thomas Richter <t...@xxxxxxxxxxxxxxxxx> 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". (-;

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).

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

.

Relevant Pages

  • Re: Looking for a JPEG guru
    ... The IJG code makes this a compile time decision whether 8bpp or ... IJG + lossless patch from Ken Murchison. ... I even tried decompressing ...
    (comp.compression)
  • Re: Looking for a JPEG guru
    ... I have an issue using the IJG on a 12bits JPEG file. ... and the decompress file as given by djpeg: ... The IJG code makes this a compile time decision whether 8bpp or ...
    (comp.compression)
  • Looking for a JPEG guru
    ... I have an issue using the IJG on a 12bits JPEG file. ... and the decompress file as given by djpeg: ...
    (comp.compression)
  • Re: Help compiling NASM source for a x86 SIMD optimized Jpeg unit
    ... can you ASAP send me converted source (to compile with bc++). ... I think error is in calling conventions (I have fixed this with version ... of IJG). ...
    (borland.public.delphi.language.basm)