| [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
STR #914
Application: | FLTK Library |
Status: | 1 - Closed w/Resolution |
Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
Scope: | 3 - Applies to all machines and operating systems |
Subsystem: | Image Support |
Summary: | Fl_GIF_Image can't find colormap in an image |
Version: | 1.1-current |
Created By: | Natevw |
Assigned To: | mike |
Fix Version: | 1.1-current (SVN: v4480) |
Update Notification: | |
Trouble Report Files:
Trouble Report Comments:
|
#1 | Natevw 12:20 Jun 18, 2005 |
| Attached is an example of a GIF image that is not properly read in the FLTK library. When this image is opened, ".../image005.gif does not have a colormap" is spit onto the console, and the image does not seem to be initialized.
This image is opened fine in other applications.
thanks, -nate | |
|
#2 | matt 05:57 Jul 20, 2005 |
| The warning message is not the reason for not reading the GIF. The image in question is missing the global colormap which is optional AFAIK, but does contain a local (4 bit) colormap. I did not dive any deeper into the decompression logic, but I assume that the bug is somewhere in there. | |
|
#3 | mike 19:36 Aug 07, 2005 |
| Hmm, FLTK is reading the local colormap properly, and the colormap is getting read properly, however the image itself is not getting read properly.
After further investigation, the image in question is incorrectly formatted - the global header specifies 8-bits per pixel, the local image header specifies 4-bits per pixel, but the initial code size is only 4-bits (3 bits for image data and 1 additional bit to hold the clear code, free code, and initial repeat strings).
In short, the file is bogus, but I was able to come up with a short patch which checks for this condition and adjusts the BitsPerPixel and ColorMapSize values to correspond to N-1 bits when the initial code size is too small. | |
[ Return to Bugs & Features ]
|
| |