atom feed15 messages in net.java.dev.jai-imageio.interestRe: [JAI-IMAGEIO] Question about read...
FromSent OnAttachments
GiliJun 6, 2005 9:56 pm 
James ChengJun 7, 2005 11:53 am 
GiliJun 7, 2005 12:33 pm 
James ChengJun 7, 2005 1:23 pm 
James ChengJun 8, 2005 1:35 pm 
Fabrizio GiudiciJun 11, 2005 8:48 am 
Brian BurkhalterJun 13, 2005 4:44 pm 
Fabrizio GiudiciJun 17, 2005 2:51 pm 
Brian BurkhalterJun 17, 2005 4:51 pm 
Fabrizio GiudiciJun 18, 2005 7:49 am 
Ron ChambersJun 18, 2005 2:21 pm 
James ChengJun 19, 2005 3:53 pm 
Fabrizio GiudiciJun 20, 2005 1:34 am 
James ChengJun 20, 2005 8:54 am 
Brian BurkhalterJun 20, 2005 10:48 am 
Subject:Re: [JAI-IMAGEIO] Question about reading lossless JPEG
From:Fabrizio Giudici (Fabr@tidalwave.it)
Date:Jun 20, 2005 1:34:01 am
List:net.java.dev.jai-imageio.interest

On Sun, 19 Jun 2005 15:53:17 -0700, James Cheng <Jame@Sun.COM> wrote:

Hi Fabrizio,

I don't think we had ever considered that deviation in the clib JPEG decoder. If you could provide a self-contained test case, or at least the image file made from the tile in question, it'd be very helpful for us to debug and probably add a support for the deviation.

Sure I can. Should I send it to this list? Being just a tile of a larger image, is small (about 50k). Let me know.

Fabrizio Giudici wrote:

On Fri, 17 Jun 2005 16:51:32 -0700 (PDT), Brian Burkhalter <Bria@Sun.COM> wrote:

If you're on a Unix system you need the .so files on your LD_LIBRARY_PATH, if on Windows the .dll files on your PATH.

I was using java.library.path, but with a silly silly mistake of mine. Now it's ok. But I have a new problem, with the plugin that can't read the file. I get a: javax.imageio.IIOException: Decoder cannot decode input. at com.sun.media.imageioimpl.plugins.jpeg.CLibJPEGImageReader.decode(CLibJPEGImageReader.java:79) at com.sun.media.imageioimpl.plugins.clib.CLibImageReader.getImage(CLibImageReader.java:320) at com.sun.media.imageioimpl.plugins.clib.CLibImageReader.read(CLibImageReader.java:384) at javax.imageio.ImageIO.read(ImageIO.java:1400) at javax.imageio.ImageIO.read(ImageIO.java:1322) As I said in my first post in the thread, the input is a tile from an Adobe DNG file. It looks like the tile is extracted correctly: if I copy it to a file and try to open with Photoshop Elements I get Could not compete your request because reading spatial/lossless JPEG files is not implemented. but not having a "unknown format" error or such I'd say that the tile is correctly extracted. I'm puzzled about the error since the imageio plugin diagnostic is too generic. Any clue? PS Reading Adobe DNG specs there's a warning on page 49 about "Compatibility Issue 2: 16-bit Lossless JPEG Encoding". I'm quoting the specs in order to find out if this is related to my issue: The Lossless JPEG encoder/decoder used by Adobe applications to read and write DNG files before version 1.1.0.0 incorrectly deviated from the JPEG specification when dealing with 16- bit data. Since both the encoder and decoder deviated in the same way, no data was lost; however the data stream did not exactly match the data stream specified in the Lossless JPEG specification. Because the vast majority of DNG 1.0.0.0 files using 16-bit Lossless JPEG encoding were created by Adobe applications, it is strongly recommended that software that reads or writes DNG files with version numbers less than 1.1.0.0 incorporate this deviation. Software that reads or writes DNG files with version 1.1.0.0 or later can safely assume that the Lossless JPEG stream is fully compliant with the Lossless JPEG specification. Description of deviation Lossless JPEG encodes the difference between a predicted value and the actual value for each pixel. With 16-bit data, these differences are computed modulo 16-bits, so the range of possible differences is -32768 to + 32767. Two values are stored for the difference. First the number of bits required to store the difference (encoded via a Huffman code), and then the actual difference. Using the difference encoding scheme in the Lossless JPEG specification, only one difference value would take 16-bits to store: -32768. The Lossless JPEG specification special cases this difference bit length, and since there is only one possible difference value it does not bother to use any bits to store the actual difference. In earlier versions of DNG the special case logic is not present, and the difference value for - 32768 is stored in the compressed data stream as with all other difference bit lengths.