The Persistence of Vision Raytracer (POV-Ray).
This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.
Opened by Grimbert Jérôme - 2013-12-02
Last edited by William F Pokorny - 2016-10-11
FS#314 - reading Gif is bugged in 3.7
In gif.cpp (source/base/image), circa line 150:
case ',': /* Start of image object. Get description. */
for (int i = 0; i < 9; i++)
{
if ((data = file->Read_Byte()) == EOF)
throw POV_EXCEPTION(kFileDataErr, "Unexpected EOF reading GIF file");
buffer[i] = (unsigned char) data;
}
/* Check "interlaced" bit. */
if ((buffer[9] & 0x40) != 0)
throw POV_EXCEPTION(kFileDataErr, "Interlacing in GIF image unsupported");
The loop reads the 9 bytes of the Image Block, but is testing the tenth byte for interlacing.
Reference for image format: http://www.onicos.com/staff/iz/formats/gif.html#ib
When the gif is generated by Gimp, the Image block is preceded by the comment block which default to “Created with GIMP”... the comment is read in the buffer, and the “i” will be in buffer[9], any letter after @ will indeed block povray.
This bug was not present in 3.1g nor in 3.6.1 (due to different source to handle gif).
If not created by Gimp, or with shorter comment, the content of buffer[9] is more random, yet it might trigger the bug depending on the previous blocks and their handling.
Tuesday, 11 October 2016, 16:38 GMT
Reason for closing: Fixed
Additional comments about closing:
Have no test case to verify, but the change there as git commit a21c6e8 was Jerome Grimbert, 2 years, 10 months ago, message: Proposal to fix fs#314 (perforce #6159)
The test should be on buffer[7] (as interlace is at offset 8 of the block, but the 0 (the comma) is not part of buffer)
And it seems indeed, that even 3.1g was bugged too: it tested the 9th byte after the comma (,) tag for the image block, which is either the first byte of the local palette (unlikely, but might happened on composed images), or the LZW minimal code side. (which we gladly ignore, reading only the block size and each block until a block size of 0 is found.
Gah! Are they denoting the MSBit as "bit 0" there?
Seems so (about MSBit as 0).
And they can't count either: (my comment inside {})
Image Block Offset Length Contents 0 1 byte Image Separator (0x2c) { that one is not in buffer[], so should be off by 1 from offset } 1 2 bytes Image Left Position { buffer 0 & 1 } 3 2 bytes Image Top Position { buffer 2 & 3 , we ignore both position, assuming 0,0 } 5 2 bytes Image Width { buffer 4 & 5, that one we had right } 7 2 bytes Image Height { buffer 6 & 7, that one we had also } 8 1 byte bit 0: Local Color Table Flag (LCTF) { wtf, it's buffer 8, the offset is bogus } bit 1: Interlace Flag bit 2: Sort Flag bit 2..3: Reserved bit 4..7: Size of Local Color Table: 2^(1+n) ? bytes Local Color Table(0..255 x 3 bytes) if LCTF is one { if there is a local color table, we are doomed too} 1 byte LZW Minimum Code Size { That part is handled by Decode() function of gifdecod.cpp } [ // Blocks 1 byte Block Size (s) (s)bytes Image Data ]* 1 byte Block Terminator(0x00)A second source of reference http://www.matthewflickinger.com/lab/whatsinagif/bits_and_bytes.asp
should now be fixed with change #6159
I retract my comment about 3.1g & 3.6.1 being bugged (relative to that subject): they are fine. But they would get perturbed by a local palette in the Image block.