Option to not convert GIFs to videos.

[ryliejamesthomas]

I would really appreciate an option to be able to keep some GIFs as GIFs, instead of converting them to video. Videos really make a mess of nice pixel art :(
So, I disagree with #431 that that are 'higher quality', though I agree they're better in some cases.

I suggest a toggle, whose default is video.

(Also currently these converted GIFs are labelled as 'GIF' in their preview in the web client, which is misleading! Different clients seem to handle this differently though.)

---

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.

[Gargron]

We could maybe adjust the conversion params to improve quality of pixel art. However, the conversion is not done for you as author, it's done for a) your admin's hosting bill b) your followers' bandwidth, so it's a strong "no" from me on making this a user option.

[ryliejamesthomas]

I am the admin :)

I agree it's good to save bandwidth, and a lot of people use GIFs for things they really shouldn't, but perhaps a file size check would be good? 100-200kb is plenty generous and useful enough for GIFs, and converting files at that level really isn't saving much.

I also think bandwidth considerations are the domain of mobile clients and user perferences, but that's for people more knowledgeable than me to discuss I guess..

[SoniEx2]

Archival can just use a stronger compression even if slower. As for bandwidth, client-side options would be nice.

A cache can be used to retrieve from archive.

It's a win-win for everyone.

[SoniEx2]

And don't forget the times mastodon makes GIFs BIGGER.

[shmibs]

agreement on this; until such time as a suitable alternative is well-supported, there are certain things which should remain in gif format.

limitations of the current video conversion are:

• h.264 cannot handle transparency (problematic for pixel art)
• video conversion blurs high-contrast (problematic for pixel art)
• video decoders tend to frame-interpolate for low frame rates (also problematic for pixel art)

it is reasonable to allow non-conversion when:

• the video resulting from a conversion is larger than the original (rarely, but sometimes true of pixel art)
• the original file is very small to begin with (nearly always true of pixel art)

abuse of this feature could be prevented by setting an upper limit for the size of gifs received from other instances, so that even if one admin removes the restrictions the others will not be harmed.

[yaomtc]

For example, look at this GIF animation. Now try uploading it to Mastodon and see what happens.

Notice how on Chrome it moves at the speed of light (too fast) while on Firefox, frame rate stutters between too fast and 0.

[nightpool]

to be fair, i think you're referencing a specific bug in imagemagick that mangles 2 frame gifs. Try adding an empty 1ms frame in the middle

…

On Fri, Mar 23, 2018 at 9:07 PM yaomtc ***@***.***> wrote: For example, look at this GIF animation. Now try uploading it to Mastodon and see what happens. [image: twinkmoving] <https://user-images.githubusercontent.com/5534045/37858643-1fc8bf8e-2ede-11e8-993a-a97a7e914f2a.gif> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6403 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAORVxLpNF8zVwaYUGN9xVQzHgs0wFGpks5thZw3gaJpZM4R1FUi> .

[yaomtc]

GIMP doesn't seem to let you add an empty 1ms frame, it converts it to a 10ms frame. Here's the updated file, and the resulting video still stutters on Firefox.

[SoniEx2]

http://nullsleep.tumblr.com/post/16524517190/animated-gif-minimum-frame-delay-browser

(that is probably no longer completely accurate but I knew there was something like this somewhere and that seemed like a reasonable source)

[unascribed]

What I usually do to work around this is convert the GIF to a lossless VP9 WebM - it still does chroma subsampling and converts to YUV, but it's still crispy. (VP8 does not have a lossless mode.)

ffmpeg -i <anim>.gif -vcodec libvpx-vp9 -lossless 1 -deadline realtime -pix_fmt yuv420p <anim>.webm

The animation loop thing is just an unfortunate fact about browsers - video and audio elements can't do gapless playback, even if looping. A kinda sucky workaround is to just pre-loop it, which FFmpeg can do but I'm currently too asleep to figure out how.

(Also note that I say there's still chroma subsampling, and am explicitly specifying 4:2:0 subsampling in the command - you can do 4:4:4, i.e., no loss, but very few clients support 4:4:4 video. VP9 is already setting the bar quite high, 4:4:4 is impossibly high. And while FFmpeg supports lossless H.264, i.e. MP4, it's an unofficial extension only supported by FFmpeg and other programs based on libavcodec, like VLC.)

[ThisIsMissEm]

I don't fully understand this topic, but I know Giphy and others have written about using WebM or switching to it for bandwidth reasons: https://engineering.giphy.com/how-video-formats-work/

[SoniEx2]

and giphy only has gifs of videos.

your point is biased at best.

[shmibs]

@SoniEx2 that reads as a little aggressive, particularly to someone admitting to being fully aware of the situation

as for this topic in general, i guess it's just not going to go anywhere, a niche use-case that looks unnecessary from outside the minority who are invested

[ryliejamesthomas]

'Yeah' to both shmib's points.

I think MissEm's link has some interesting stuff :)

I wouldn't complain if someone stuck a 'wont fix' on here and closed the issue.

[unascribed]

The common case by far is videos that got turned into GIFs for use before HTML5 video was well-supported, or for use on platforms that don't support video. I don't see this being fixed.

I did just put up a web page that basically runs the ffmpeg command I posted above, but more conveniently since you don't have to run ffmpeg yourself. I hope this is an acceptable solution for now. https://unascribed.com/gif2vp9

[SoniEx2]

the easiest way to get what you want is to put a magnet link to a GIF on your post. or use your own hosting, as many currently do.

[unascribed]

A magnet link is far from "the easiest way", and using your own hosting loses you the integration with the UI.

(N.B: I'm not speaking in anything resembling an official capacity, I have a "Contributor" badge because I replaced a 15k 1x1 empty PNG with an 81 byte 1x1 empty PNG.)

[SoniEx2]

hmm... I mean vgy.me supports APNG.

You could add vgy.me integration with the UI. Don't store it on the instance ofc - just fetch from vgy.me, client-side.

Y'know like we have youtube integration?

[unascribed]

Mastodon doesn't have YouTube integration - it has OEmbed integration. It's on vgy.me to add OEmbed support.

OEmbeds only show up in the expanded view of a status, though, not in the main timeline.

(This is kinda spammy at this point, so I'm not going to be making further replies.)

[SoniEx2]

Hmm.

Well, it's a tradeoff I guess: is that good enough for your use-cases?

vgy.me also has the option to keep EXIF data and stuff if you feel like it.

[SoniEx2]

It would still be nice if mastodon automatically chose whatever file was smaller, tho. with some tolerance so e.g. a 400B gif would still be preferred over a 398B video. (also attempting APNG conversion would be neat.)

[shmibs]

or the easiest solution would really just be a hard upper-limit for size, so like "convert anything over 400kb"

have like thousands of gifs from decades of internet, and the only things under that size in this collection are pixel-art things

[alexopus]

Can't this be a configurable setting for a server? Server owner should choose if he wants to to show gifs or mp4s. Or am I missing something on how Mastodon works? If this cannot be an option, can server owner patch the code of his instance?

[trwnh]

Did the conversion change at some point in time? I just uploaded a GIF and it wasn't converted to a video -- it was converted to a PNG of the first frame.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[yaomtc]

I would recommend changing the name of this issue to "Option to not convert sufficiently small GIFs to videos", in reference to the file size.

Related issue: #4581

[joyeusenoelle]

Yikes, this is an ancient issue. But the image-upload interface has improved since it was last really discussed, so I'd like to suggest a hybrid solution.

As currently, convert GIF to video on upload, but maintain a copy of both files. In the Edit Image modal (where you set the focus and the alt text), add a checkbox for GIFs below a certain size: "Keep this image as a GIF (e.g. for pixel art)". Above the designated size, change that to "This GIF is large and will be converted to video to save space and bandwidth."

Essentially, we are creating Schrödinger's GIF, and the waveform should be collapsed when the user posts the status. If the user does not select the checkbox, or if the GIF is too large, then when the toot is posted, delete the GIF and attach the video to the toot. If the user selects the checkbox, delete the video and attach the GIF to the toot.

The maximum size for GIFs could be hardcoded (like toot length, display name length, etc.) or admin-definable.

Does this make sense?

[leo60228]

I'd be fine with an instance-level toggle. I have a single-user instance and I frequently post GIFs that shouldn't be videos while I pretty much never post GIFs that should be videos.

[vmstan]

'Yeah' to both shmib's points.

I think MissEm's link has some interesting stuff :)

I wouldn't complain if someone stuck a 'wont fix' on here and closed the issue.

Done