FLTK logo

STR #914

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

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:

Receive EMails Don't Receive EMails

Trouble Report Files:


Name/Time/Date Filename/Size  
 
#1 Natevw
12:20 Jun 18, 2005
image005.gif
0k
 
 
#2 mike
19:36 Aug 07, 2005
str914.patch
1k
 
     

Trouble Report Comments:


Name/Time/Date Text  
 
#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 ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.