こんにちは！GIF をアップロードすると、サイズを 100% に設定してもなぜこんなに小さくなるのか気になりました。例えば：
これは、具体的にあなたがアップロードしようとしているものに関するエラーのようですが、正確に、手順を一つずつ、例を挙げて説明していただけますか？
この GIF が問題を引き起こします。私のコンピュータでプロパティを確認すると、タイプは「image/gif」に設定されており、サイズは 10.4MB です。Discourse が画像をリサイズしているようです。同じ方法で作成したより小さな GIF は、表示上の問題なくアップロードできます。
これは通常、アップロード制限に収まらないほど大きな GIF に関するものですが、何らかの理由で自動的にリサイズされているのでしょうか？その結果の画像は非常に小さくなっています：
50 x 29、32kb
これは @sam への回帰（バグ）かもしれませんね：thinking:
おそらく回帰現象です。アニメーションのない GIF でも同様の現象が発生しますか？
皆さん、ありがとう！GIFを作成するために http://giffox.com/ を使っています。
時々うまくいき、時々うまくいかないことがあります……サイズの問題かもしれないですね。ちょうどテストをしていたところです。
非常に短い動画なら作れます。
これは 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 への変換）という別の問題に自らを追い込むのではなく、真っ向から却下すべきだと考えます。
はい、それは単純な修正のようです。現在の機能を修正します。
とにかく、過去 5 年間、GIF 画像のサイズ変更は「gifsicle」を使用して行われており、それに関するパフォーマンスの問題は報告されていませんでした。@zogstrip 氏により詳しい情報があるかもしれません。
この場合、非常に特定の GIF を拒否すると、リポジトリにさらにコードが追加されることになると思います。
現状では、すべての GIF が「アニメーション付き」であると仮定しています（以下を参照）：
一部の GIF を拒否するように変更する場合、アニメーション GIF の形式検出を行い、特別な拒否ロジックを実装する必要があります。これは、サイズ最適化が必要な画像（寸法による）の場合、特に複雑になります。なぜなら、アニメーション GIF の最適化が不再可能になるためです。
一方で、gifsicle 依存関係を除去できるという利点があります。一方、アップロードパイプラインがより複雑になるという欠点もあります。
個人的には、@vinothkannan の修正は問題なく、リスクも低いと思います。これは 5 年間使用されてきたコードであり、既知の大きなパフォーマンス問題はありません。
とはいえ、@codinghorror さん、アニメーション GIF のリサイズサポートを完全に削除したい場合は、ここで格闘する必要はありません。ただし、これはかなり複雑な変更です。検出は比較的簡単ですが、エラーメッセージ付きで拒否を実装するのは少し難しいかもしれません。
アニメーション GIF のサイズが 10MB を超えているため、アップロードできません
アニメーション GIF のサイズが 600x400 を超えているため、アップロードできません
いずれにせよ、これはあなたの判断です。私の提案は、この修正をそのままにして先に進むことですが、サポートを削除したい場合はお知らせください。
なお、この削除により、アニメーションアバター（オプション機能）のサポートも削除する必要があります。正直なところ、これを維持しなければならないことはあまり嬉しくありません。
ふむ、つまり、アニメーション GIF が合計アップロードサイズ制限（??）内に収まっていれば、実質的にその「動画」の品質が何らかの基準に合わせて低下するということでしょうか？
ここで実際に何が起きているのか、私は非常に混乱しています。
明らかに、GIF に対して幅と高さをリサイズするのは全く不適切です。それが上記の元のバグの原因だったのでしょうか？
過去の経緯としては、最適化時にアニメーション GIF を「破壊」してしまっていたため、ライブラクセーション対象としてアップロードされた画像が台無しになっていました。
コード内部には、GIF がアニメーションしているかどうかを判断する「検出」ロジックがありませんでした。ライブラクセーションは、投稿がデータベースにコミットされた後に実行されます。
修正策としては、リサイズ処理がアニメーション GIF を台無しにせず、適切に処理できるようにすることでした。
問題は、GIF のサポートを削除する場合、アニメーション GIF に対して「特別な処理」を行うために、アップロードパイプラインの大部分を再構築する必要があることです。
- GIF がアップロードされる
- アニメーション GIF か？
- プリプロセッサがリサイズを必要とするか？
- アニメーション GIF を拒否
- ポストプロセッサが最適化を必要とするか？
- アニメーション GIF を拒否
- プリプロセッサがリサイズを必要とするか？
- アニメーション GIF ではないか？
- 通常のパイプラインで通過させる
- アニメーション GIF か？
また、パラメータが変更された場合の Markdown の長期的な再レンダリングや、ホットリンク画像の取得といった副作用も考慮する必要があります。
単にリサイズ処理を修正するだけであれば、こうした問題について気にする必要はありませんでした。
私は、アニメーション GIF に対して「最適化」を行うこと自体に賛成できないため、コードがこれを検知できるようにする必要があると思います。そのパスを追加すれば、将来的には GIF から MP4 動画への変換が可能になり、それは私たちが望んでいる方向性でもあります。したがって、これは必要な作業だと考えます。
確認のため申し上げます。
お客様は以下の対応をご希望とのことです。
- Docker イメージから
gifsicleを完全に削除する - 以前の投稿でサイズ変更されたアニメーション GIF を再処理した際、投稿内に「画像破損」アイコンが表示されるようにする
- 外部リンク画像の取得タスクを修正し、サイズ変更が必要なアニメーション GIF の取得を回避し、代わりにリンクを表示するようにする
- 寸法またはサイズが过大で、かつアニメーションされている GIF を拒否する
- Discourse からのアニメーションアバターのサポートを廃止する
- アップロードテーブルで、アニメーション有無を記録・管理する
これらは細かな作業が約 1〜2 週間かかる見込みです。現状は問題なく動作しているため、本当にこの対応をご希望かどうか、改めて確認させていただいております。
もちろん、依存関係を減らす方が良いでしょう？
問題ないでしょう
リモートファイルのサイズをチェックするだけです。大きすぎれば取得しません。それ以外は気にしません。
はい、おそらくファイルサイズが問題になるでしょう。高さや幅の寸法が問題になるよりもずっと早く。（「ティムの次元… 時間の次元」という不思議な TWILIGHT ZONE のように）これは、画像を動画のように扱うのがなぜこんなに奇妙なのかという理由でもあります。これらは全く異なる存在です！
はい、正常な人なら誰もこれを望んでいません。
このコードパスが必要です。なぜなら、最終的には GIF を MP4 に自動変換するべきだからです。これによりその方向への一歩が踏み出され、世界にとってプラスになります。
gifsicle の依存関係を以下のプルリクエストで削除しました: