You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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].
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.
The text was updated successfully, but these errors were encountered:
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.
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 torgba[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.
The text was updated successfully, but these errors were encountered: