#2542 closed defect (fixed)
Opening large GIF files causes GDALOpen() to hang.
| Reported by: | warmerdam | Owned by: | warmerdam |
|---|---|---|---|
| Priority: | normal | Milestone: | 1.6.1 |
| Component: | GDAL_Raster | Version: | unspecified |
| Severity: | normal | Keywords: | gif biggif |
| Cc: | gaopeng |
Description
Attempting to open a large GIF file (24000x18000) results in GDALOpen() appearing to hang. While it does eventually succeed if sufficient memory is available it is very intrusive to the application.
Change History (7)
comment:1 by , 16 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:2 by , 16 years ago
Ok, I have applied this change in trunk (r15186).
I'm a bit hesitant to migrate this back into 1.5 branch for now.
comment:3 by , 16 years ago
| Cc: | added |
|---|
comment:4 by , 15 years ago
| Milestone: | → 1.6.0 |
|---|---|
| Resolution: | → fixed |
| Status: | assigned → closed |
Closing as completed. Reopen if there are problems.
comment:5 by , 15 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
The current fix by setting a hard limit doesn't work, sometimes it's too low, and other times, it's too high. Look at the possibility to restructure to avoid using DGifSlurp() (but this appears to be quite a substantial job).
comment:6 by , 15 years ago
| Keywords: | biggif added |
|---|---|
| Resolution: | → fixed |
| Status: | reopened → closed |
I have implemented a "BIGGIF" driver that reads scanline by scanline. It has a number of deficiencies (no support for nodata transparency blocks, and only supports one image-band even in multi-image files) so it is registered after the normal GIF driver and only used for really big files.
To support interlaced files effectively the BIGGIF driver will create a temporary TIFF file to hold the image data for random access if anything but a once-through sequential read is done.
This code is added in trunk (r16023,r16025) and a small test for this driver is added in trunk (r16024). The new driver has also been added in 1.6 branch (r16026).
The way the GIF driver is currently setup it reads the whole GIF file into memory in the open function. For the sample image this means using 400MB of RAM and having to do a substantial amount of decoding before processing can continue.
In theory it might be possible to restructure to avoid using DGifSlurp() but this appears to be quite a substantial job. Instead, I'm just modifying the slurp function to error out for files larger than 100 megapixels. This is very rare in GIF format.