Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

High quality GIF with FFmpeg

blog.pkh.me

Post reply on HN
Print view View original

111–120 of 131 posts

Re: High quality GIF with FFmpeg

#111

Post by bbllee »

ChrisLomont wrote: post #93
1ris wrote: post #38

Earlier quoted context omitted.

None that works with current browsers implantations, because they erroneous ignore no delay between frames and wait anyway. But that's a bug in the gif decoder, not a limitation of gif. OK, this is hairsplitting, but it illustrates how borken the state of gif is.

Actually, regarding the delay, the spec reads "vii) Delay Time - If not 0, this field specifies the number of hundredths (1/100) of a second to wait before continuing with the processing of the Data Stream. " A zero delay is most certainly not covered by the spec, and anyone using one is creating GIFs that do not meet the spec. [0] http://www.w3.org/Graphics/GIF/spec-gif89a.txt

You can achieve no delay without using a zero delay. Graphic Control Extension blocks may be omitted between images and so multiple images can come in a row without anything defining a delay between them.

See the last instance of the phrase "graphic control" in the document to see that multiple images can come with no intervening GCE blocks and see the paragraph containing the 5th instance of that phrase to observe that a GCE block only affects the first image following the GCE.

Re: High quality GIF with FFmpeg

#112

Post by [deleted] »

astrange wrote: post #78
dangerlibrary wrote: post #37

Earlier quoted context omitted.

That's a good option if the official binaries support all the codecs you need and have all the correct hardware acceleration flags set for your particular CPU/GPU. That's ... theoretically possible, I suppose.

ffmpeg binaries come with all possible codecs and all possible CPU features. The first is actually bad, because it will do far more things than you've actually tested and can secure. (In fact, nobody on earth has tested most possible ffmpeg command lines.) The second is the way almost all sensible x86 software should behave.

[deleted]

Re: High quality GIF with FFmpeg

#113

Post by chanux »

dangerlibrary wrote: post #66
amelius wrote: post #64

Earlier quoted context omitted.

> ffmpeg is downright magical Actually, in my experience, ffmpeg is the linux-program that by far outshines any other program in... failing or crashing :/ I'm sorry to say this. And, unfortunately, there isn't any other open source program doing a better job in terms of file format support.

I would agree that ffmpeg has warts. It is pretty poorly documented. Also, filter pipelines are finicky and not commutative, which can be super confusing, but most of the time you don't need them. Aspect ratio syntax is a disaster, but aspect ratio specifications are a little bit of a disaster, so I don't know how much to blame ffmpeg. But simply failing or crashing? I can't say I've ever had a crash that wasn't the…

I think ffmpeg deserves my support on this as well. I maintain a video system at work and using ffmpeg for conversions. ffmpeg has never given me troubles (we compile our own ffmpeg).

Re: High quality GIF with FFmpeg

#115

Post by nitrogen »

pornel wrote: post #97
quotedmycode wrote: post #12

So it's using a simple Median Cut quantization... which is okay, but you can get great results using an octree quantizer, and without dithering. Dithering kills your compression savings in GIF so you'd want to avoid it if possible. In any case, you can see the difference a better quantizer makes here: http://www.leptonica.com/color-quantization.html

If you want high-quality palette try libimagequant: http://pngquant.org/lib pngquant's method is superior to octtree: • it uses Voronoi iteration to get local minimum and minimize effects of axis-aligned subdivisions • it uses sort-of gradient descent to optimize subdivisions • to some degree edges and noise are included in histogram weights • does not need to throw away any bits of precision (most implementations ju…

(most implementations just naively discard 2-3 bits, because of RAM limits in '80-'90s)

Might it also have something to do with earlier VGA DACs having 6 bits per color channel? I seem to remember that newer video cards required setting a separate register to enable eight-bit-per-channel palette entries.

Edit: never mind, the discussion of Wu's algorithm in another thread, specifically https://news.ycombinator.com/item?id=9216252, makes the RAM limitation clear.

Re: High quality GIF with FFmpeg

#116

Post by nitrogen »

leeoniya wrote: post #17
quotedmycode wrote: post #12

So it's using a simple Median Cut quantization... which is okay, but you can get great results using an octree quantizer, and without dithering. Dithering kills your compression savings in GIF so you'd want to avoid it if possible. In any case, you can see the difference a better quantizer makes here: http://www.leptonica.com/color-quantization.html

here's how my quantizer does: full-color, undithered, floyed-dithered: http://imgur.com/a/lrLTd#0 repo: https://github.com/leeoniya/RgbQuant.js demos: http://o-0.me/RgbQuant/ this image is actually a pretty poor example of quantization, it's too easy. full color gradients give a much better indicator of behavior, quality and performance. if you really are interested in different algorithms, check this out: http://www…

Interestingly, both of the quantized versions appear slightly brighter in all colors than the original. It's easier to see in the dithered image, but also visible in the undithered image.

Re: High quality GIF with FFmpeg

#117

Post by gbog »

dangerlibrary wrote: post #66
amelius wrote: post #64

Earlier quoted context omitted.

> ffmpeg is downright magical Actually, in my experience, ffmpeg is the linux-program that by far outshines any other program in... failing or crashing :/ I'm sorry to say this. And, unfortunately, there isn't any other open source program doing a better job in terms of file format support.

I would agree that ffmpeg has warts. It is pretty poorly documented. Also, filter pipelines are finicky and not commutative, which can be super confusing, but most of the time you don't need them. Aspect ratio syntax is a disaster, but aspect ratio specifications are a little bit of a disaster, so I don't know how much to blame ffmpeg. But simply failing or crashing? I can't say I've ever had a crash that wasn't the…

The video play "mpv" is also almost a wrapper around ffmpeg, it seems.

Re: High quality GIF with FFmpeg

#118

Post by erikano »

1ris wrote: post #32

>As you probably know, GIF is limited to a palette of 256 colors. No, it's not. OK, the current, wrong, implementations do limit it to 256 colors, but that's not a limitation of gif. Mulitple frames without a delay allow multiple pallets and multiple times 265 colors. But this limitation is just another reason not to use it. Can I use Webm? http://caniuse.com/#feat=webm Yes, you can, and you should. Or h.264: http://…

Don't forget Ogg/Theora.

http://caniuse.com/#feat=ogv

Re: High quality GIF with FFmpeg

#119

Post by keeperofdakeys »

dangerlibrary wrote: post #37
Thaxll wrote: post #31

Earlier quoted context omitted.

Don't compile it just use the official binaries!

That's a good option if the official binaries support all the codecs you need and have all the correct hardware acceleration flags set for your particular CPU/GPU. That's ... theoretically possible, I suppose.

Programs like ffmpeg compile in code paths for all hardware acceleration flags (mmx, sse, avx), then use runtime detection to use the right code for your cpu.

Re: High quality GIF with FFmpeg

#120

Post by vanderZwan »

derf_ wrote: post #72
quotedmycode wrote: post #12

So it's using a simple Median Cut quantization... which is okay, but you can get great results using an octree quantizer, and without dithering. Dithering kills your compression savings in GIF so you'd want to avoid it if possible. In any case, you can see the difference a better quantizer makes here: http://www.leptonica.com/color-quantization.html

Any method that makes axis-aligned subdivisions (which includes both standard median cut and octree), even in a space like HSV, is going to be pretty suboptimal. There's probably been more sophisticated things done since I looked at this in the 1990's, but Xiaolin Wu's 1992 approach [1] works quite a bit better than both (including the 1991 Wu v2 implementation of an octree method linked elsewhere in this thread). It…

Ironically, that ACM paper is a scan of a printed out paper, with half-toned images, ruining the comparison images. Is there a purely digital version of that paper out there?

EDIT: Is it this color quantization algorithm that is linked on Wu's own webpage? http://www.ece.mcmaster.ca/~xwu/cq.c

Post reply on HN