Open PennyBlake1827 opened 1 year ago
On the roadmap, will be a bit as we have a lot of other work to finish first
Oh fab I'm so glad to hear it, thankyou! We can wait! :)
On Mon, Jul 24, 2023 at 3:43 PM Paul Frazee @.***> wrote:
On the roadmap, will be a bit as we have a lot of other work to finish first
— Reply to this email directly, view it on GitHub https://github.com/bluesky-social/social-app/issues/1047#issuecomment-1648052028, or unsubscribe https://github.com/notifications/unsubscribe-auth/BBPKHLPM6KAEDPV3DJ26KD3XR2CZXANCNFSM6AAAAAA2VWGBCI . You are receiving this because you authored the thread.Message ID: @.***>
Just want to take the opportunity to mention support for GIF-adjacent formats as well, eg: animated WEBP, or WEBMs and MP4s with zero audio tracks (different to videos with muted audio). Doubly-so if GIFs end up being transcoded into any of these formats, as it seems to be the norm for GIFs nowadays - I'd rather upload a WEBM or MP4 directly in this case.
On the roadmap, will be a bit as we have a lot of other work to finish first
Unless someone makes a Pull Request to the proper repository to add it.
Unless someone makes a Pull Request to the proper repository to add it.
It's not a purely frontend task. The backend needs processing behaviors and the moderation system needs automated and manual review tooling.
Those could still be added/changed by Pull Requests.
Embedding linked-to gifs could be a good intermediary step! It could even help to make moderation easier
Deck.blue now supports uploadable gifs.
Third party apps are demonstrating that it's possible. Graysky supporting a gif keyboard is another example of this.
Because of this, I think the bluesky team should reconsider the priority of this feature, and shift focus to it ASAP. Uploading gifs/video is a required capability of micro-blogging platforms in today's ecosystem, and its absence is preventing many people from being able to use bluesky. It's not a preference to those people -- it's a requirement. They can't switch over to bluesky even if they wanted.
At this point, more and more third party apps are adding gifs/videos in some form. However, they're unable to do this in a fully supported way because the first party bluesky app is incompatible with them. Instead, they have to go through various workarounds and provide a limited version.
I think this makes it even more important for the first party client to support gifs and videos - so that it allows these party developers to build these kinds of features freely.
I would like to add a request that gifs should not autoplay, or there should be an option to stop them from autoplaying. Animation clutter is a serious problem with a lot of websites which want to show off all this moving stuff without realizing that they're making their own site illegible in the process. The eye is drawn to movement and that's very frustrating when you're trying to read text.
I would imagine the app would respect the system "reduce motion" setting that the user can enable, which would be a good start
think this should be closed?
Not yet - We're still waiting for native GIF support. As in, the ability to upload GIFs directly to Bluesky via the official clients.
How much longer until GIF support is added?
Any updates on the inclusion of native GIF support? I ask that since a lot of animators prefer them since the quality loss is less noticeable, specially for niche stuff like pixel art.
I know this may sound superficial but it is pretty important for artists, animators and game developers using the platform to show their work
Just adding this as a note here since many other places get this wrong:
Animated image formats like GIF and JPEG-XL generally use frame durations, while most video formats seem to use frame timestamps. This means that, when converting animated images into videos frame-by-frame with common libraries, the last frame must be duplicated to display it for the intended duration.
On Mastodon, this manifests itself as irregular GIF timing: https://github.com/mastodon/mastodon/issues/5646
Note that the then second-to-last frame likely must be shortened by one framerate frame accordingly to ensure a smooth loop. Twitter appears to get that part wrong, which is why the advice there appears to be to duplicate all frames at half the duration, then delete the last one.
It would also be really nice if the native storage format for GIFs was still GIF and the CDN took care of converting them, since the conversion to video is so prone to quality loss. Maybe it will be possible to retroactively upgrade to JXL delivery on supporting devices, then. (It would be really nice to have JXL (JPEG-XL) as supported upload and storage format too, but it doesn't seem like imageproxy supports that yet, which according to this comment is the CDN used by Bluesky.)
Is your feature request related to a problem? Please describe. We need GIFs to communicate effectively in an engaging and vibrant way - they are the linguistic currency of this generation and a platform that doesn't support them is never going to gain as much fluid and vibrant engagement as one that does.
Describe the solution you'd like Enable the use of GIFs in posts and replies the same way that twitter does.
Describe alternatives you've considered
Additional context