德尔福TGIFImage动画的问题与一些G​​IF观众 [英] Delphi TGIFImage animation issue with some GIF viewers

查看:357
本文介绍了德尔福TGIFImage动画的问题与一些G​​IF观众的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我发现,GIF动画使用创建德尔福2009年的 TGIFImage 有时不正确的部分的GIF观众播放。问题是,在动画pmaturely重启$ P $

I have discovered that animated GIFs created using Delphi 2009's TGIFImage sometimes doesn't play correctly in some GIF viewers. The problem is that the animation is restarted prematurely.

请看下面的例子:

program GIFAnomaly;

{$APPTYPE CONSOLE}

uses
  Windows, Types, Classes, SysUtils, Graphics, GIFImg;

var
  g: TGIFImage;
  bm: TBitmap;

procedure MakeFrame(n: integer);
var
  x: Integer;
  y: Integer;
begin
  for x := 0 to 256 - 1 do
    for y := 0 to 256 - 1 do
      bm.Canvas.Pixels[x, y] := RGB((x + n) mod 255,
        (x + y - 2*n) mod 255, (x*y*n div 500) mod 255);
end;

var
  i: integer;

begin

  bm := TBitmap.Create;
  bm.SetSize(256, 256);

  g := TGIFImage.Create;
  g.Animate := true;
  for i := 0 to 499 do
  begin
    MakeFrame(i);
    TGIFGraphicControlExtension.Create(g.Add(bm)).Delay := 3;
    Writeln('Creating frame ', i+1, ' of 500.');
  end;
  TGIFAppExtNSLoop.Create(g.Images.Frames[0]).Loops := 0;

  g.SaveToFile('C:\Users\Andreas Rejbrand\Desktop\test.gif');


end.

(这是我能找到表现出这个问题最简单的例子。)

(This is the simplest example I could find that exhibits the problem.)

的输出是一个相当大的GIF动画。在Internet Explorer 11,整个15秒的电影正常发挥,但在谷歌浏览器的'电影'是$ P $只有大约四秒钟后重新启动pmaturely

The output is a rather large animated GIF. In Internet Explorer 11, the entire 15-second 'movie' is played properly, but in Google Chrome the 'movie' is prematurely restarted after only about four seconds.

这是为什么?


  1. 有什么问题与输出GIF文件?

  2. 如果是这样,有什么错我的code以上,或有与 GIFImg
  3. 问题
  4. 如果没有,什么是观众的问题的性质?哪些部分可用观众有这样的问题?有没有一种方法,以避免'这个问题GIF创建过程中?

有关的SO用户的利益,上述code是一个最小的工作示例。当然,当我发现这个问题我没有创造这些迷幻图案。相反,我是在一个Lorenz系统模拟器的工作,并制作这个GIF动画它确实在IE浏览器中玩,但不是:

For the benefit of the SO user, the above code is a minimal working example. Of course, I wasn't creating these psychedelic patterns when I discovered the issue. Instead, I was working on a Lorenz system simulator, and produced this GIF animation which does play in IE but not in Chrome:

在Internet Explorer中11,模型被旋转360度重新启动动画之前。在谷歌浏览器,动漫是只有20度后重新启动的pmaturely $ P $。

In Internet Explorer 11, the model is rotated 360 degrees before the animation is restarted. In Google Chrome, the animation is restarted prematurely after only some 20 degrees.


  • 洛伦兹的图像在IE 11.0.9600.17239和GIMP 2.8.0 ,歌剧12.16

  • 洛伦兹图像的不会在谷歌浏览36.0.1985.143男,火狐26.0,27.0.1,31.0合作

  • The Lorenz image works in Internet Explorer 11.0.9600.17239, The GIMP 2.8.0, Opera 12.16
  • The Lorenz image does not work in Google Chrome 36.0.1985.143 m, Firefox 26.0, 27.0.1, 31.0.

如果我打开GIMP之类的'问题'GIF,让GIMP(RE)将其保存为GIF动画,结果在每一位观众的作品。以下是洛伦茨动画的,不论是否供版本

If I open a 'problematic' GIF in The GIMP and let GIMP (re)save it as an animated GIF, the result works in every viewer. The following is the GIMPed version of the Lorenz animation:

使用十六进制编辑器的两个文件进行比较,并使用维基百科的文章作为参考,现在看来,例如,像Netscape的字符串是在原来的(unGIMPed)版本错误的地方。这是有点怪,即使我设置GIF图像的宽度高度,在相应的值逻辑屏幕描述符不存在。

Comparing the two files using a hex editor, and using the Wikipedia article as a reference, it seems, for instance, like the 'NETSCAPE' string is at the wrong place in the original (unGIMPed) version. It is somewhat strange, that even if I set the width and height of the GIF image, the corresponding values in the Logical Screen Descriptor are not there.

推荐答案

这是在TGIFImage的LZW EN codeR的错误。

It's a bug in TGIFImage's LZW encoder.

在一些非常罕见的情况下,LZW EN codeR将输出的LZW蒸汽的末尾一个额外零字节。由于LZW结束块标志也是一个零字节,严格GIF读者可能呛在这个或跨preT它作为GIF年底(尽管文件标记到底是3B $)。

In some very rare circumstances the LZW encoder will output an extra zero byte at the end of the LZW steam. Since the LZW end block marker is also a zero byte, a strict GIF reader might choke on this or interpret it as the end of the GIF (although the end of file marker is $3B).

一些GIF读者可以处理这种情况的原因可能是GIF格式这个问题很多年前很常见。显然TGIFImage是不是让特定错误的唯一库。

The reason some GIF readers can handle this is probably that GIFs with this problem was common many years ago. Apparently TGIFImage wasn't the only library to make that particular mistake.

要解决这个问题做如下修改 gifimg.pas (标有变化的 * 的):

To fix the problem make the following modification to gifimg.pas (change marked with *):

procedure TGIFWriter.FlushBuffer;
begin
  if (FNeedsFlush) then
  begin
    FBuffer[0] := Byte(FBufferCount-1); // Block size excluding the count
    Stream.WriteBuffer(FBuffer, FBufferCount);
    FBufferCount := 1; // Reserve first byte of buffer for length
    FNeedsFlush := False; // *** Add this ***
  end;
end;

这篇关于德尔福TGIFImage动画的问题与一些G​​IF观众的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆