bug#7799: 24.0.50; Animated images display strangely

bug#7799: 24.0.50; Animated images display strangely

[Lars Magne Ingebrigtsen]

When displaying some animated images, they look somewhat broken.  Here's
a test case:

(url-retrieve
 "http://icanhascheezburger.files.wordpress.com/2010/12/funny-pictures-gifs-standing-cat.gif?w=215&h=205"
 (lambda (status)
   (goto-char (point-min))
   (search-forward "\n\n")
   (let ((data (buffer-substring (point) (point-max))))
     (pop-to-buffer "*animate*")
     (insert-image
      (create-animated-image data 'gif t)))))

Apparently these are GIF images that have a background images, and the
rest of the frames are of the "combine" type.  Emacs doesn't seem to do
the right thing in that case, although other animated GIFs look fine.



In GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.1)
 of 2011-01-07 on quimbies
Windowing system distributor `The X.Org Foundation', version 11.0.10707000
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US
  value of $XMODIFIERS: nil
  locale-coding-system: iso-latin-1-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent input:
C-y C-x C-e C-x s C-x o C-x 1 M-x r e p o r t - e m 
<tab> <return>

Recent messages:
Ido mode enabled
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark set
Contacting host: icanhascheezburger.files.wordpress.com:80
#<buffer  *http icanhascheezburger.files.wordpress.com:80*>
Reading [image/gif]... 1.47M of 1.47M (100%) [2 times]
Reading... done.
(No files need saving)

Load-path shadows:
~/pgnus/contrib/vcard hides /home/larsi/lisp/vcard
~/lisp/zenirc-2.112/src/zenirc-example hides /home/larsi/lisp/zenirc-example
~/jukebox/lisp/captitle hides /home/larsi/lisp/captitle
~/jukebox/lisp/expect hides /home/larsi/lisp/expect
/home/larsi/lisp/footnote hides /home/larsi/src/emacs/trunk/lisp/mail/footnote
~/pgnus/contrib/compface hides /home/larsi/src/emacs/trunk/lisp/gnus/compface
~/jukebox/lisp/time-date hides /home/larsi/src/emacs/trunk/lisp/calendar/time-date

Features:
(shadow sort hashcash message sendmail rfc822 mml easymenu mml-sec
mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader emacsbug
mail-utils url-cache url-http tls mail-parse rfc2231 rfc2047 rfc2045
ietf-drums url-gw url-auth url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-util url-parse auth-source netrc
gnus-util url-vars mm-util mail-prsvr mailcap ido flyspell ispell dired
regexp-opt add-log mail-extr jka-compr cl tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image fringe
lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
loaddefs button minibuffer faces cus-face files text-properties overlay
md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
dynamic-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty emacs)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

bug#7799: 24.0.50; Animated images display strangely

[Chong Yidong]

> When displaying some animated images, they look somewhat broken.
>
> Apparently these are GIF images that have a background images, and the
> rest of the frames are of the "combine" type.  Emacs doesn't seem to
> do the right thing in that case, although other animated GIFs look
> fine.

This was fixed a while ago, so I'm closing the bug.

bug#7799: 24.0.50; Animated images display strangely

[Lars Magne Ingebrigtsen]

Chong Yidong <cyd@stupidchicken.com> writes:

> This was fixed a while ago, so I'm closing the bug.

It's much better than it used to be, but I'm still seeing some glitches.

With emacs -Q and the latest bzr, eval the following:

(url-retrieve
 "http://icanhascheezburger.files.wordpress.com/2011/08/0848b876-a808-4614-ac26-9285d46cc5f7.gif"
 (lambda (status)
   (goto-char (point-min))
   (search-forward "\n\n")
   (let ((data (buffer-substring (point) (point-max))))
     (pop-to-buffer "*animate*")
     (let ((image (create-image data 'gif t)))
       (insert-image image)
       (image-animate image nil 60)))))

One single frame in the animation looks broken.  That seems to be the
case with all my test cases where the image displays buggily.  (But most
animated gifs display properly now.)  Could it be a off-by-one error of
some kind?
       
-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#7799: 24.0.50; Animated images display strangely

[Andy Moreton]

On Tue 09 Aug 2011, Lars Magne Ingebrigtsen wrote:

> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> This was fixed a while ago, so I'm closing the bug.
>
> It's much better than it used to be, but I'm still seeing some glitches.
>
> With emacs -Q and the latest bzr, eval the following:
>
> (url-retrieve
>  "http://icanhascheezburger.files.wordpress.com/2011/08/0848b876-a808-4614-ac26-9285d46cc5f7.gif"
>  (lambda (status)
>    (goto-char (point-min))
>    (search-forward "\n\n")
>    (let ((data (buffer-substring (point) (point-max))))
>      (pop-to-buffer "*animate*")
>      (let ((image (create-image data 'gif t)))
>        (insert-image image)
>        (image-animate image nil 60)))))
>
> One single frame in the animation looks broken.  That seems to be the
> case with all my test cases where the image displays buggily.  (But most
> animated gifs display properly now.)  Could it be a off-by-one error of
> some kind?

I see the same glitchy behaviour in a win32 build of today's trunk,
using the GnuWin32 build of libungif4.dll (v4.1.4.2616).

With http://upload.wikimedia.org/wikipedia/commons/3/37/Clock.gif
(580×580 pixels, 143 frames) I get a segfault.

I'm happy to help debug if somebody more familar with GIFs and image
display can make suggestions as to where to look next:

Program received signal SIGSEGV, Segmentation fault.
0x01295e7c in gif_load (f=0x3703000, img=0x479d480) at image.c:7360
7360                    int c = raster[y * image_width + x];
(gdb) info locals
c = 0xfe
subimage = 0xa496f8
raster = 0x724537d8 "\002\002\002\002"
transparency_color_index = 0x2
disposal = 0x0
file = 0x103928d
rc = 0x1
width = 0x244
height = 0x244
x = 0x9c
y = 0xb7
i = 0x4
j = 0x1
ximg = 0x362bdc0
gif_color_map = 0xa47960
pixel_colors = {0x2ffffff, 0x2000000, 0x2d9d9d9, 0x2000000, 0x0 <repeats 252 times>}
gif = 0xa47908
image_height = 0xc9
image_width = 0xd4
memsrc = {
  bytes = 0x47a300c "GIF89aD\002D\002\221",
  len = 0x27d93,
  index = 0x27d93
}
specified_bg = 0x341c81a
specified_file = 0x341c81a
specified_data = 0x47a2e61
bgcolor = 0x0
idx = 0x5
(gdb) bt
#0  0x01295e7c in gif_load (f=0x3703000, img=0x479d480) at image.c:7360
#1  0x0128d5f5 in lookup_image (f=0x3703000, spec=0x47948fe) at image.c:1741
#2  0x0128be90 in Fimage_metadata (spec=0x47948fe, frame=0x341c81a) at image.c:975
#3  0x010368af in Ffuncall (nargs=0x2, args=0x82e780) at eval.c:3012
#4  0x010ddcbc in exec_byte_code (bytestr=0x13ec8f9, vector=0x13ec945, maxdepth=0xc, args_template=0x341c81a, nargs=0x0, args=0x0) at bytecode.c:785
#5  0x0103779c in funcall_lambda (fun=0x13ec8d5, nargs=0x1, arg_vector=0x341c81a) at eval.c:3240
#6  0x01036c48 in Ffuncall (nargs=0x2, args=0x82ea80) at eval.c:3058
#7  0x010ddcbc in exec_byte_code (bytestr=0x13ecb51, vector=0x13ecbc5, maxdepth=0x24, args_template=0x341c81a, nargs=0x0, args=0x0) at bytecode.c:785
#8  0x0103779c in funcall_lambda (fun=0x13ecb15, nargs=0x5, arg_vector=0x341c81a) at eval.c:3240
#9  0x01036c48 in Ffuncall (nargs=0x6, args=0x82eda0) at eval.c:3058
#10 0x010357e3 in Fapply (nargs=0x2, args=0x82eed4) at eval.c:2514
#11 0x010365d5 in Ffuncall (nargs=0x3, args=0x82eed0) at eval.c:2991
#12 0x010ddcbc in exec_byte_code (bytestr=0x13cc269, vector=0x13cc29d, maxdepth=0x10, args_template=0x341c81a, nargs=0x0, args=0x0) at bytecode.c:785
#13 0x010dd278 in Fbyte_code (bytestr=0x13cc269, vector=0x13cc29d, maxdepth=0x10) at bytecode.c:423
#14 0x01034a82 in eval_sub (form=0x13cc25e) at eval.c:2363
#15 0x010327c0 in internal_lisp_condition_case (var=0x341c81a, bodyform=0x13cc25e, handlers=0x1311746) at eval.c:1440
#16 0x010de6dc in exec_byte_code (bytestr=0x13cc169, vector=0x13cc1ed, maxdepth=0x14, args_template=0x341c81a, nargs=0x0, args=0x0) at bytecode.c:981
#17 0x0103779c in funcall_lambda (fun=0x13cc14d, nargs=0x1, arg_vector=0x341c81a) at eval.c:3240
#18 0x01036c48 in Ffuncall (nargs=0x2, args=0x82f5a8) at eval.c:3058
#19 0x01035d89 in call1 (fn=0x342790a, arg1=0x362be85) at eval.c:2778
#20 0x0100e1f8 in timer_check_2 () at keyboard.c:4428
#21 0x0100e272 in timer_check () at keyboard.c:4474
#22 0x0104a966 in wait_reading_process_output (time_limit=0x43, microsecs=0x0, read_kbd=0xffffffff, do_display=0x1, wait_for_cell=0x341c81a, wait_proc=0x0, just_wait_proc=0x0) at process.c:4308
#23 0x010f75da in sit_for (timeout=0x10c, reading=0x1, do_display=0x1) at dispnew.c:5958
#24 0x010091bf in read_char (commandflag=0x1, nmaps=0x2, maps=0x82f9a0, prev_event=0x341c81a, used_mouse_menu=0x82fa68, end_time=0x0) at keyboard.c:2688
#25 0x0101bf4d in read_key_sequence (keybuf=0x82fbec, bufsize=0x1e, prompt=0x341c81a, dont_downcase_last=0x0, can_return_switch_frame=0x1, fix_current_buffer=0x1) at keyboard.c:9283
#26 0x01005bb1 in command_loop_1 () at keyboard.c:1445
#27 0x010328a2 in internal_condition_case (bfun=0x10055b6 <command_loop_1>, handlers=0x342a99a, hfun=0x1004dda <cmd_error>) at eval.c:1493
#28 0x01005212 in command_loop_2 (ignore=0x341c81a) at keyboard.c:1156
#29 0x010322c5 in internal_catch (tag=0x342a1e2, func=0x10051ee <command_loop_2>, arg=0x341c81a) at eval.c:1247
#30 0x010051ce in command_loop () at keyboard.c:1135
#31 0x010047af in recursive_edit_1 () at keyboard.c:756
#32 0x01004aca in Frecursive_edit () at keyboard.c:820
#33 0x010028c5 in main (argc=0x1, argv=0xa44480) at emacs.c:1705

Lisp Backtrace:
"image-metadata" (0x82e784)
"image-animated-p" (0x82ea84)
"image-animate-timeout" (0x82eda4)
"apply" (0x82eed4)
"byte-code" (0x82f120)
"timer-event-handler" (0x82f5ac)
(gdb)

bug#7799: 24.0.50; Animated images display strangely

[Chong Yidong]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> It's much better than it used to be, but I'm still seeing some glitches.
>
>  http://icanhascheezburger.files.wordpress.com/2011/08/0848b876-a808-4614-ac26-9285d46cc5f7.gif
>
> One single frame in the animation looks broken.  That seems to be the
> case with all my test cases where the image displays buggily.  (But
> most animated gifs display properly now.)  Could it be a off-by-one
> error of some kind?

Looks like there is off-spec behavior going on---not that the gif89a is
very descriptive in the first place.  The "buggy" frame is one which has
disposal method 2, defined in the gif89a spec as

 2 -   Restore to background color. The area used by the
       graphic must be restored to the background color.

And that's exactly what Emacs does, but it looks like web browsers are
rendering the background frame instead, under some circumstances.  I'll
take a look when I have the time.