search

FLIF-hub / FLIF

Free Lossless Image Format
Other
3.72k stars 229 forks source link

Animation format change since 2.0? #390

Closed saschanaz closed 7 years ago

saschanaz commented 7 years ago

The same GIF generates different sized files on 2.0 and today's 3.0, and each can only exclusively be decoded on their matching decoder. Resulting file size also got much larger (3,788 KiB -> 4,957 KiB).

I thought the output format was finalized, what caused this size change?

jonsneyers commented 7 years ago

It is probably related to this: https://github.com/FLIF-hub/FLIF/commit/33122c6f93421dc0bc450a947888103c88ce072b

There was a bug before this commit when you had an animation with ColorBuckets, so the implementation before this commit didn't implement the bitstream format properly. Sadly this means that animations that use ColorBuckets in combination with any of the animation-specific transformations (in particular FrameLookback and FrameShape) cannot be encoded or decoded properly with those older versions.

However this change shouldn't result in larger files, in fact if there is any difference they should be slightly smaller. Can you send me the GIF that causes a different size? Or just show the verbose encoder output (use -vvvvv or more) in both versions. They might be using different encode settings.

saschanaz commented 7 years ago

eufo

Attaching the GIF here. (4,311,022 bytes)

saschanaz commented 7 years ago

I'm not sure what happened but today I retried this and got 3,691 KiB result. No idea why I got larger one last time. If I see this issue again I will reopen this.

saschanaz commented 7 years ago

Downgrading to 6738ea99dc2bf32ffd4e3d085a344cf42c0c6eae reproduces this issue, probably fixed later? I thought I was running the latest bit, it seems I was wrong.