大家好，我想知道为什么上传的 GIF 图片尺寸这么小——即使你选择了 100% 的尺寸，例如：
这看起来像是您选择上传的内容出现了特定错误？能否请您逐步详细描述具体情况，并提供示例？
这是一个会触发该问题的 GIF 文件。当我在电脑上查看其属性时，其类型被设置为 ‘image/gif’，大小为 10.4MB。看来 Discourse 正在调整图像的尺寸。我可以上传用同样方式创建的较小的 GIF 文件，而不会出现显示问题。
可能是回归问题，非动画 GIF 是否也会出现这种情况？
这是一个 2.06 MB 的 GIF
这是一个 3.47 MB 的 GIF
这是一个 9.06 MB 的 GIF
是的，看起来在 4 MB 限制处发生了非常严重的问题，@sam @eviltrout。我已编辑标题以反映该问题。我们必须修复这个问题，我们出现了倒退。
只是想确认一下，这个问题是否仅限于动态 GIF。
我想我们使用的是 Gifsicle: Command-Line Animated GIFs 来调整大小，所以我猜是参数发生了变化。
@vinothkannans 你今天能帮忙快速看一下吗？
自从我们更改了 图片缩小 的方式后，这个问题就出现了。上述提交将修复此问题，较大的 GIF 将能够正确缩小。
这个修复方案正确吗？我认为我们不应该对实际上是视频的文件进行“缩小尺寸”操作。这种做法似乎过于极端（并且可能非常消耗服务器 CPU），可能会破坏视频（GIF）的画质。
我对此持保留意见。我认为，对于过大的动画 GIF，我们应该直接拒绝，而不是勉强将其纳入视频调整尺寸的范畴（或者更好的是，转换为 MP4 格式）。那是另一个需要解决的问题。
是的，这看起来是一个直接的修复方案。我将更改当前的功能。
无论如何，看起来我们过去五年一直在使用 “gifsicle” 调整 GIF 图片的大小，并且没有收到任何性能问题。@zogstrip 可能知道更多细节。
https://github.com/discourse/discourse/commit/d456460d33859a3f6890062083ace6f64aa17266
我认为在这种情况下，拒绝非常具体的 GIF 会增加我们代码库的负担。
目前，我们只是假设所有 GIF 都是“动态的”，正如：
如果我们打算更改逻辑以拒绝部分 GIF，我们就必须实现动态 GIF 的格式检测，并编写专门的拒绝逻辑。这对于需要优化（由于尺寸限制）的图片来说尤其复杂，因为我们将无法再优化动态 GIF。
好处是可以移除 gifsicle 依赖项。坏处是上传流程会变得更加复杂。
就我个人而言，我认为 @vinothkannan 的修复方案是可行的且风险较低。这是我们已经使用了 5 年的代码，据我所知没有重大的性能问题。
话虽如此，@codinghorror，如果您想彻底移除对动态 GIF 调整大小的支持，我不建议在此纠缠。这是一个相当复杂的改动：识别动态 GIF 相对容易，但通过错误消息来实施拒绝可能会稍微棘手一些。
您的动态 GIF 大于 10MB，因此无法上传
您的动态 GIF 大于 600x400 像素，因此无法上传
总之，由您决定。我的建议是保持当前的修复方案不变并继续推进，但如果您想彻底移除支持，请告知我们。
注意，移除该功能还将要求我们移除对动态头像（一项可选功能）的支持。老实说，我并不太乐意必须这样做。
嗯，所以只要动画 GIF 的总上传大小在限制范围内（？？），它实际上就会被“降低”视频质量以匹配……什么呢？
我完全不清楚这里到底发生了什么。
显然，调整高度和宽度对 GIF 来说是完全不合适的……这是否就是导致上述原始错误的原因？
之前的情况是，我们在优化过程中会“破坏”GIF 动图，因此如果您上传了需要灯箱展示的图片，我们就会将其弄坏。
我们代码的内部逻辑中没有“检测”机制来判断 GIF 是否为动图。灯箱功能是在帖子提交到数据库之后才触发的。
解决方案是让我们的“调整大小”代码不再破坏动图，并能正确处理它们。
问题在于，如果我们打算停止支持动图，就需要重新调整上传流程的多个部分，以便对动图进行“特殊处理”。
- 上传 GIF
- 是否为动图？
- 预处理器是否需要对其调整大小？
- 拒绝动图
- 后处理器是否需要对其进行优化？
- 拒绝动图
- 预处理器是否需要对其调整大小？
- 是否不是动图？
- 按正常流程处理
- 是否为动图？
此外，还需要考虑一些长期副作用，例如当参数发生变化时重新生成 Markdown 内容，以及处理热链接图片的问题。
而仅仅修复调整大小功能，就意味着我们无需再担心这些复杂情况。
我认为我们根本不应该对动态 GIF 进行“优化”，因此代码需要检测这种情况。添加该路径将为将来把 GIF 转换为 MP4 视频打开大门，而这正是我们最终想要的。所以我认为这是必要的工作。
仅做澄清。
您希望我们：
- 从我们的 Docker 镜像中彻底移除
gifsicle。 - 当您重新处理包含已调整大小的动态 GIF 的旧帖子时，这些帖子中应显示为损坏的图片图标。
- 修复我们抓取外链图片的任务，跳过需要调整大小的动态 GIF，改为显示链接。
- 拒绝尺寸过大（维度或文件大小）且为动态的 GIF。
- 移除 Discourse 对动态头像的支持。
- 在 uploads 表中记录图片是否为动态。
我们预计这需要大约 1 到 2 周的琐碎工作。在此确认您是否希望我们执行这些操作，尤其是因为目前一切运行正常。
没问题，依赖项越少越好，不是吗？
应该没问题。
只需检查远程文件大小。如果太大，就不要抓取。除此之外我不在乎。
是的，我预计主要问题会是文件大小，远在高度和宽度尺寸变得重要之前就会出现问题。（就像《阴阳魔界》里那句滑稽的台词：“另一个维度……时间的维度”）这也解释了为什么把图片当作视频来处理是如此怪异。它们本质上是截然不同的东西！
是的，正常人都不会想要这个功能。
我们需要这段代码路径，因为我们最终应该会自动将 GIF 转换为 MP4。这让我们朝着目标迈进了一步，对世界来说绝对是件好事。
我已在以下地址移除了对 gifsicle 的依赖：