Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash with certain LZW files #3

Open
Photosounder opened this issue Apr 15, 2019 · 2 comments
Open

Crash with certain LZW files #3

Photosounder opened this issue Apr 15, 2019 · 2 comments

Comments

@Photosounder
Copy link

Photosounder commented Apr 15, 2019

I tested your library because in my own TIFF decoder I have a problem with ImageMagick's LZW files and I wanted to see how yours handles the problem, and it crashed in the function bitstreamtorgba() while attempting to write to rgba[0].

Here's the file I used: https://www.mediafire.com/view/b39ooh9qemnqafl/imagemagick_lzw_8.tif/file

The file was created with the command convert.exe %1 -set colorspace RGB -resize 2000x -colorspace sRGB -depth 8 -compress lzw "imagemagick lzw 8.tif" (I used a 32-bit linear image as input, hence the colourspace stuff, other than that it's just really the standard way to create a LZW-compressed TIFF with ImageMagick). The problem with such files is that the bit stream can sometimes contain codes that aren't yet in the dictionary, for instance the first such problematic code is a 12-bit code at bit 18751 from the beginning of the LZW strip #381 (also the one where your code crashes), the code is 3073 when the highest entry in my dictionary (and presumably yours as well) is code 2051, which shouldn't be possible. In another file I've even seen a code 364 right after the 256 clear code! (see https://stackoverflow.com/questions/55674925/decoding-tiff-lzw-codes-not-yet-in-the-dictionary)

So it appears that we both have the same problem, and apparently that would be only with files created by ImageMagick (which is kind of a big deal so I feel like I can't just ignore the problem), but the real mystery is that everybody else seems to handle the problem well, MS Paint loads the file perfectly fine for instance. How, I have no idea.

@Photosounder
Copy link
Author

Photosounder commented Apr 16, 2019

I've figured it out, turns out that the TIFF specification left out a crucial detail which is that some strips don't end with a 257 (EOI) code, so just like libTIFF does we need to stop decoding our strip after a number of decoded bytes have been outputted, and the number of bytes per strip is determined by ROWSPERSTRIP * IMAGEWIDTH * BITSPERSAMPLE / 8, and if PLANARCONFIG is 1 (which means interleaved as opposed to planar), multiply it by SAMPLESPERPIXEL.

@MalcolmMcLean
Copy link
Owner

Thanks for telling me this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants