I moved the libnsgif source into the tree and removed the old giflib code, so we now have no external dependencies for GIF load.

I added a --without-nsgif flag to configure to disable GIF load.

Unfortunately it seems libnsgif has non-functioning DISPOSE_PREVIOUS handling again, I'll investigate.

@jcupitt Thanks for the patch, I have appied it upstream.

http://git.netsurf-browser.org/libnsgif.git/commit/?id=3665353c4da1dfb7b4a1d9fa412f0dec2cb673d2

Hi @tlsa, thanks for applying the patch! Hopefully I didn't break some other case :( GIF has to be the worst image format ever :(

Apologies for not being able to test this earlier, before merging.

Using rotating-squares.gif as sample input shows a difference in the reported metadata.

Before:

$ vipsheader -a rotating-squares.gif 
...
n-pages: 30
loop: 0
delay: 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 

After:

$ vipsheader -a rotating-squares.gif 
...
n-pages: 30
delay: 30

The missing loop property can be fixed with the following diff, but I'm less sure about the right approach for delay:

--- a/libvips/foreign/nsgifload.c
+++ b/libvips/foreign/nsgifload.c
@@ -285,6 +285,7 @@ vips_foreign_load_nsgif_set_header( VipsForeignLoadNsgif *gif,
        vips_image_set_int( image, VIPS_META_N_PAGES, 
                gif->frame_count_displayable );
        vips_image_set_int( image, "gif-loop", gif->anim->loop_count );
+       vips_image_set_int( image, "loop", gif->anim->loop_count );
 
        vips_image_set_array_int( image, "delay", gif->delay, gif->n );

Drat, sorry Lovell, I should have tested more carefully.

I think it's all fixed with 89c12b0 if you have time to test.

@jcupitt Your fix looks good, thank you.

@jcupitt Is it possible to recover from GIF_INSUFFICIENT_FRAME_DATA? There are ~25 places in libnsgif.c that can return this status, which makes it feel more like something that should always fail fast.

Oh interesting, I'm not sure. Do you have an example gif which behaves badly?

https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=32607 is a 23 byte GIF file that claims to be 16448x73536.

Oh wow OK that's bad.

I'm planning to work on jp2k compression in tiff today, so if anyone else has time to fix this, please go ahead!