True-Color GIF

[usr11]

It won't stay still at XNview and always repeats. It must be still, you can see it here:

[eL_PuSHeR]

According to Irfanview it's a 8bpp paletted animated gif with 173 images.

[XnTriq]

Related topics:

• Bad GIF implementation
• { Lacuna } Animation number of loops is ignored…

[Drahken]

True-color GIFs are an old hack. It uses the animated GIF format, puts a 256 color square in each frame, offset from all previous frames, makes each frame not disappear when the next frame appears, and loops only once. Few programs other than web browsers display such images correctly.
While certainly an interesting proof of concept, the concept is extremely pointless. The images wind up being absolutely massive (even more so, since the few programs capable of making such images don't compress the GIF at all, in order to get around the (now expired) GIF patents. If this had caught on a very long time ago, it would have had a place for compatability if nothing else. Now however, PNG is almost universally compatible (which is about 10,000 times more compatible than this hackish GIF concept), can produce lossless true-color images, and makes them much smaller than this hack (even if someone did make a compressed GIF of it, it still wouldn't compress as well as making the same image as a true-color PNG).
(This GIF is 180k. The same image as a PNG is only 13k. Hell, even if you save it as a conventional GIF at only 256 colors, it's still between 11k (adaptive color, looks terrible) to 23k (floyd-steinberg color, looks almost like it should). What's really sad is that even as a BMP (which is about the single most bloated image format in common use) is only 138k for this image.)

While this does highlight what is technically a flaw in xnview, and thus something which should ideally be fixed, it really isn't worth any time, just to make one demo pic work.

[MaxSt]

Yeah, those GIFs rely on zero delay between frames, assuming GIF viewer will combine them into one big frame instantly.

In practice, viewers and browsers do not respect zero delay, because running such GIFs as fast as possible means using 100% CPU.

And about loops number: browsers still can't agree: is it number of loops or number of repetitions?

[eL_PuSHeR]

What a waste of space. Using PNG would be advisable. After PNGOptimizing it, it takes up 11,5 KB.

Thanks for the information Drakhen. Anyway the OP has a good point in that it seems only web browsers are aware of this gif hack.

[Drahken]

What makes this hack even more ineffective is the difficulty in creating such images in the first place. Doing so requires a program which can assign seperate color tables to each frame. However, the vast majority of GIF creation software (even commercial software like jasc's animation shop, and freeware powerhouses like the gimp) do not include such capability, they only have the ability to assign a single global palette to the entire image. I believe the only way to create such images is to either pay hundreds of dollars for commercial grade imaging software, or to program such a piece of software yourself (as the person who generated the demo pic did). Contrast that against the fact that even the most basic of free imaging software can easily create the same image in PNG format.

[eL_PuSHeR]

Agreed. And in the case you need animation you could use APNG format.

PS. To loop the loop, I used Google's WEBP lossless codec and it compressed to 10,7 KB.

[XnTriq]

The creator of that true-color GIF example makes it unmistakably clear that he does not recommend the use of this kind of animated GIF for the purpose of producing lossless true-color images, nor does he claim that this is a viable alternative to formats like PNG.
It's a proof concept — nothing more and nothing less.

There are more than enough free or affordable programs which can be used to create animated GIFs with local palettes:

• Adobe/Macromedia: ImageReady/Fireworks
  (I bought my old versions in used condition legally for a few bucks on eBay years ago)
• CursorArts: ImageForge
• Gamani: GIF Movie Gear
• Humanbalance: GraphicsGale
• Anders Melander: TGIFImage
• Microsoft: GIF Animator/Image Composer
• Ulead: GIF Animator/Animation SmartSaver
• WSoft Lab: Active GIF Creator
• Zoner: GIF Animator

In addition to the software mentioned above, all other programs I've tested were perfectly capable of importing or (dis)playing tc217.gif:

• Faststone Image Viewer
• Greenfish Icon Editor Pro
• IcoFX
• IrfanView
• Jasc Animation Shop
• PhotoScape

The starter of this hijacked thread has a valid point: If the GIF conforms to the official format specs, XnView should be able to display the animation. (There's absolutely nothing “hackish” at all about frames with local palettes.)
Even if we all were to abandon the GIF format tomorrow, there would still be a gazillion such files “in circulation”, making it one of the most popular and widely used formats ever.

• Crash with animated gif image + ico suggestion
• B1: Animated gif read as a multipage file
• Playback of optimized GIF animations
• Corrupted playback of animated GIF (FIXED)
• Problème gif animé
• AGIF with local palettes & interframe transparency
• some animated gifs look ugly
• 'White Artifatcs' in page viewing of Animated GIF files

I support the pending request for a setting to control XnView's behavior with regard to the loop count of animations.

• Loop Video Preview
• { Lacuna } Animation number of loops is ignored…
• APNG continuously loop even when they're not supposed to!
• Option to loop videos so they continuously play

• Images & Videos thumbnails: Visual differentiator
• Multipage information text

[Drahken]

The gimp can also open the file without difficulty, display it in it's full color glory, and re-save it as a PNG, BMP, JPG, or any other format.
Oddly though, it can't actually re-save it as a GIF, due to a lack of local palette support. It can resave it as an animated GIF, but it does so as a GIF with 256 TOTAL colors instead of 256 per frame/chunk.

[DOS386]

It won't stay still at XNview and always repeats. It must be still, you can see it here

> Anyway the OP has a good point in that it seems only web browsers are aware of this gif hack.

BTW, I can see an animation too, using Opera, nothing "still".

Conclusion: don't use "true-color-GIF-miracles", use PNG format.

PS: the GIF spec is flawed in many ways, ZERO-delay-dilemma is only one of them-

This is not a bug, more likely a suggestion: <<allow "true-color-GIF-miracles">>. Don't make this hack always on, you will get "animation doesn't play" or "missing frames in animation" BUG reports.