Posted by
ctrueden on
Sep 14, 2005; 10:06pm
URL: http://imagej.273.s1.nabble.com/LZW-compressed-tiffs-tp3704864p3704868.html
Hi Jon,
I am not sure what's going on here, but I doubt your fix completely
solves the problem (capping off j, while avoiding exceptions, means that
many RGB triples being read in are being thrown away). But I suppose if
you're seeing what looks like the correct picture, it's a step forward.
Also, ImageJ has a restriction with the ordering of the strips within
the TIFF file (LZW or not), and I recently found out that the libtiff
library does not always write LZW-compressed TIFFs conforming to this
assumption. ImageJ uses InputStream, not RandomAccessFile, so if the
image strips are out of order, ImageJ displays an error message (see
TiffDecoder.OpenIFD() in the STRIP_OFFSETS case). ImageJ could probably
be made to read in TIFFs with out-of-order strip offsets by sorting the
strip offsets and then populating the pixels array in that order (since
Java arrays are obviously random access).
Anyway, if you send me a sample image that is causing you difficulties,
I can look into it.
-Curtis
Jon Harman wrote:
> Hi
>
> In looking for lossless compression for my large image files, I
> started using LZW tiffs. (are there better formats?) I found that
> different programs produce very different output files using this and
> sometimes ImageJ would fail to read the output. For instance
> paintshop pro sometimes produces a file that can't be read. Photoshop
> seems much better. Irfanview produces files that sometimes can't be
> read, and additionally aren't much compressed. So this format seems
> to be a can of worms.
>
> At any rate the other programs did not have the problem that ImageJ
> did in opening the files, they all could read the files wrote by the
> others, unlike ImageJ. I looked into this and found that making the
> following modification to readCompressesChunkyRGB in ImageReader.java
> fixed the problem. Just add a test that j is < nPixels before writing
> to pixels:
>
> if(j < nPixels){
> if (bgr)
> pixels[j] = 0xff000000 | (blue<<16) |
> (green<<8) | red;
> else
> pixels[j] = 0xff000000 | (red<<16) | (green<<8)
> | blue;
> }
>
> I have no clue as to why j is getting too big, but adding the test
> seems to work just fine.
>
> Jon
>