Optional image optimization before upload の議論に続きます：
この機能は、今すぐ Meta でテスト利用可能です。ここで画像をアップロードすると、サーバーに送信される前にユーザーのブラウザでリサイズ/エンコードが実行されます。
ぜひ試してみてください。このトピックで、または「composer media optimization image enabled」サイト設定を有効にすることで、ご自身のコミュニティでもお試しください。テスト中は、デフォルトでは無効のままにしています。
違いを視覚的に示すため、以下に「前/後」の画像を示します：
この写真はスマホで撮影したばかりのもので、デフォルト設定により 3.7MB から 416KB に削減されました。
この機能の目的は、@sam がここで説明した通りです：
Discourse は標準でユーザーアップロードの上限を 4MB に設定しています。しかし今では、58MB の JPEG をドラッグ＆ドロップすることも可能です：
問題なくアップロードされます。
お疲れ様です！
一つ小さな点についてご報告します。この 6.1MB の HEIC 画像をアップロードした際、進捗バーが比較的すぐに 100% に達しましたが、完了するまで約 50 秒間その状態のままになりました。これにより、混乱を招いたり、アップロードをキャンセルしてしまう可能性があります。
問題の動画はこちら: Image optimization loading percentage | Loom
素晴らしいですね。一つ簡単な質問、もしかしたら当たり前のことかもしれませんが、サイト制限を超える画像のみ有効にするのは可能でしょうか？つまり、制限以下の画像は処理されず、制限を超えようとした場合のみ、一見して縮小されるようにするのです。
これは私がずっと待ち望んでいたものです 
Falco さん、ありがとうございます。
一つ質問があります。再ビルドされた投稿で古い画像も最適化されるのか、それとも新規アップロードの画像のみが対象になるのでしょうか？改めてありがとうございます 
この新機能は、取り込まれた HEIF 画像では動作しないため、テストされていません。HEIF で作業したかったのですが、ブラウザでのデコードサポートが存在しません（https://caniuse.com/heif）。そのため、あなたがテストしたのは、すでに長らく動作しているサーバーサイドの HEIF 変換機能です。
WebAssembly デコーダーを同梱すれば動作させることも可能ですが、そのような画像は極めて稀であるため、@pmusaraj 氏が取り組んだサーバーサイドの変換機能ですでに十分であると考え、実装する必要はないと判断しました。
現時点では、この機能は JPG、PNG、GIF の取り込みが可能です。AVIF、JPEGXL、TIFF へのサポートも容易に追加でき、近々実装する予定です。
はい可能です！composer media optimization image kilobytes optimization threshold を希望の値に調整してください。
いいえ、行われません。この処理はユーザーのブラウザ側で、アップロードの直前に行われます。Rebake はサーバーサイドのプロセスであるため、両者は大きく異なります。
（2020 年の最初のロックダウン中に都心から撮影した 28 MB の写真）
1 Gbps から 1 Mbps まで、さまざまな接続速度でアップロードをテストしました。1 Mbps の帯域幅を除いて、すべて正常に動作しました。1 Mbps の場合のアップロード動作は少し奇妙でした。
長い間 0% で止まった後、1 Mbps の接続速度ではあり得ないほど急速にパーセンテージが増加し、その後、長い間 100% で止まった後にこのメッセージが表示されました：
元の画像形式は PNG ではなく JPG であることに注意してください… 
[Uploading: 20200328_141218.jpg...]() が画像の代わりに投稿に残ってしまいました。
2つの問題があります：
画像をアップロードしている最中にメッセージをキャンセルして下書きを破棄し、その後新しい返信を投稿しようとすると、コンポーザーに読み込みの進行状況が表示されたままになります：
これを消去するには、ページを再読み込みする必要があります。
サイトが50 MBの画像の送信と表示を許可しているのに、21600×21600ピクセル、108 MBの画像（こちらから）を送信しようとすると、以下のメッセージが表示されるため、ユーザーにとって少し混乱を招きます：
ここで混乱するのは、「4 MB超は禁止だが、50 MB超の画像はなぜか許可されている」という点です。
この画像をアップロードできない本当の理由は何でしょうか？
とても素敵な写真ですね！28 MB から 113 KB への圧縮は、かなり良い比率です！
つまり、この新機能は「アップロード前」のフェーズのみを変更するものです。アップロードしようとするファイルをインターセプトし、変換を適用してから、より小さな新しいファイルに置き換え、既存のアップロード処理を再開します。
アップロード前のフェーズでは 0% のまま「処理中…」と表示されるため、これは想定通りの動作です。下部の「アップロード中…」という文字列も置き換えるようにしてみます。
4 MB 超は依然として禁止されています。工夫しているのは、可能な限り画像を最適化して 4 MB 超にならないようにし、ファイルサイズ制限をクリアできるようにしている点です。
あのサイトからいくつかの画像を試してみましたが、すべて PNG の透明度（アルファチャンネル）を使用しているため、安全に JPG に変換できず、最適化処理が中断してしまいました。
今回は 60 MB の PNG をテストしたところ、最適化処理で対応できましたが、その過程で 4 GB 以上の RAM を消費し、最終的に 360 KB の JPG になりました。
このテストで使用していたデバイス、ブラウザ、OS のバージョンを教えていただけますか？
「アップロード処理中」という新しい作曲ステータスメッセージを追加しました。これで、現在何が起こっているかが正確に把握できるようになりました。
この機能は現在、安全にテスト可能です。コミュニティでの結果をお知らせください。
こんにちは、Falco さん。
Composer の画像最適化機能を使い始めました。複数の写真をアップロードしようとすると、最初の画像がアップロードされた後に「返信」ボタンが有効になり、次の画像の最適化が完了するまで無効にならないことに気づきました。この間に「返信」ボタンをクリックすると、他の画像のアップロードがフリーズし、テキストのみが構成されてしまう（処理中）状態になります。Meta 側ではボタンが素早く切り替わるため再現できませんが、私のサイトではアップロード間の待ち時間が約 10 秒以上と、ほとんどの場合フリーズしてしまいます。デフォルト設定を使用しており、3 枚の画像（それぞれ約 3〜4MB）をアップロードしています。
Huawei P20 Pro（Android 10、Chrome 91.0.4472.120）の Web アプリで試しました。
動画をご覧いただくと、アップロード（Feltöltés）後に「返信」ボタンが有効になっていることがわかります。各画像は約 2.3MB です。
画像アップロード中は「返信」ボタンを常时无効にすることは可能でしょうか？
この設定について混乱しています。「kilobytes」は正しい単位でしょうか？
ご回答よろしくお願いいたします！
ご報告ありがとうございます！ボタンの無効化ステータスを計算する際にバグがありました。
はい、正しいです https://en.wikipedia.org/wiki/Kilobyte。デフォルトは半メガバイトですが、必要に応じて調整できます。最もスペースを節約したい場合は、約 300 キロバイトまで下げることをお勧めします。
修正ありがとうございます。
なるほどです。単に「バイト」の表記ミスかと思っていたんです。変換ツールに 524288kb と入力すると 512mb と表示されるので、そこで混乱してしまいました。でも、今では理解できました。ありがとうございます。
ああ、今わかりました。私の間違いです！
こんにちは、
修正ありがとうございます 今では完璧に動作しています！
モバイルでの画像アップロードについて質問があります。モバイルから画像をアップロードすると、目標ピクセル幅にリサイズされず、画質のみが変更されているようです。デスクトップ PC で試すとリサイズは正常に機能します。何か見落としているでしょうか？よろしくお願いします
モバイルとデスクトップの両方でリサイズを試みますが、デバイスのハードウェアが弱すぎるとリサイズ処理に失敗する場合があります。その場合は処理をスキップします。
