しばらく前から、画像表示が自動で最適化される仕様になっているのは知っていますが、
そのせいで、223KBのpng画像がjpgと同様の品質で表示されるようになってしまい、
画質劣化を避けるためpngでアップした意味がなくなってしまっているのが引っかかっています。
念のため、ロスレス圧縮のwebp画像(176KB)でも試しましたがダメでした。
些細なことかもしれませんが、
512MBを超過しない限り最適化されないように設定変更していただくか、
あるいは指定画像のみ最適化されない表示オプションを追加していただくことは可能でしょうか。
ご不便をおかけして申し訳ございません。
転送量削減のため、表示画像の最適化を行っております。
実際の画像サイズ(容量)と画像サイズ(ピクセル)、圧縮フォーマットをもとにして、
表示させる画像サイズ(ピクセル)に合わせて最適化しています。
極端な例ですが、実際の画像サイズ(100px,100px)なのに、アイコンとして画像サイズ(25px,25px)で表示させようとすると画像サイズ(25px,25px)より、ちょっと大きめで最適化されます。
表示させたい画像サイズ(ピクセル)に合わせた画像を用意していただくことで劣化を防ぐことができます。
このような抜け道を追加することは難しいです。
現在でも抜け道はありますが、対応する予定です。
良いアイディアがあれば、引き続きこちらで議論していただけると幸いです。
例えば… 以下の条件で画像を最適化しない
など…
返答ありがとうございます。
具体例として挙げた画像(png, webp)は640x540pxで、
縮小・拡大表示はしていないのですが、
webpでもロスレス圧縮だとこれ以上ファイルサイズが小さくならないようなので、
対応できないということであれば一先ず諦めるしかなさそうですね…
どういう意味でしょうか?
上記のように、640x540pxのwebp画像を640x540で表示していますが、劣化して表示されます。
それとも解像度に見合った最適解のファイルサイズがあるということでしょうか。
上記画像の添付ページは、添付枚数が3枚(jpg,webp,png各1枚)、容量は合計674KBですが、
「ページあたりの上限設定を超えない限り、そのページの画像最適化は行わない」とした場合、
ページ上限は、どの程度が想定されるでしょうか。
あります。
よろしければ掲載しているURLをここで共有していただくことは可能でしょうか？
今後の最適化の調整の参考とさせていただきます。
申し訳ございません。
逆に質問になってしまうのですが、ページの最大添付画像数はどのくらいなら許容できるでしょうか？
例えば、計算しやすいように1ページあたり最大4枚とします。
容量は1ページあたり最大2MB、1日1000人がそのページを閲覧すると、転送量が1日およそ2GBになります。
（そのくらい訪問数があるページが多数あります）
実際は「Lagy load」や「ブラウザキャッシュ」でそこまで転送量が発生しません。
でも、最大4枚は少なすぎなのに転送量がそこそこあります。
新しい機能を実装すると全てのWIKIに適用されることになります。
個別のWIKIだけに適用することはできません。
アクセス数があるWIKIに適用されることも想定しているのでシビアになってしまいます。
また、アクセス数で調整する方法もありますが、アクセスがあるページほど、画像の圧縮率が高くなるようなことは避けたいと考えております。アクセス数で画像の解像度が動的に変わると気持ち悪いですし、CDNのキャシュ効率も悪くなります。
今後の開発の参考にさせていただきますので、
引き続き、他のユーザーの意見も交えて議論いただけたら幸いです。
こちらのページになります。
問題の画像は中央のインベントリー画像(640x540px)で、以前はpngでしたが、
現在はロスレスのwebp(176MB)に差し替えて、以前のpngは削除済みです。
敢えてnolink指定していないので、クリックで実際の添付画像と容易に比較できます。
比較すると、特にカラー文字（ブルー、オレンジ、グリーン）が劣化しているのが一目瞭然かと思います。
画像最適化が導入されて以降、こうなっているのですが、
その下のpng画像(640x360px, 28KB)は現在でも問題ありません。
「総容量」ではなく「総枚数」なのですね…
咄嗟には見当がつかないので、自分も皆さんの意見を伺ってみたいです。
小さい画像を沢山貼っていると不利になると思うので、
（当wikiだと各種所持品一覧とかが該当するんですよね…）
可能なら「総枚数」でなく「総容量」にしていただけるとありがたいです。
（枚数は減らせなくても、ファイルサイズならある程度の調整が可能です）
同意致します。
運営側から見れば、アクセス数の多いページ程データ転送量が増えるので、
シビアな調整をお願いしたい…となるのでしょうが、
アクセス数の多いwikiとそうでないwikiとの処遇格差につながりかねないので、
それはやめた方がいいと思います。
共有ありがとうございます。
許容範囲かどうか、みなさんのご意見を聞かせていただけたらと思います。
画像直リンク
もとの画像がwebpでアップされています。
webp の 181kb はサイズが大きいと判断して再圧縮されている可能性があります。
webp からの webp は劣化が激しいと思います。
他のフォーマットでも妥当な画像サイズなら最適化なしでそのまま表示されますので、
お試しいただけたら幸いです。
640x540 ですと 89kb 以下の画像サイズにするとパスするかも知れません。
下の ds_command panel.png 640x360 29kb はパスしてますね。
一個人の意見でありますが文字認識及び、グラフィックがぼやける等で利用者が認識困難でなければ、許容範囲内ではないかと思います。
この画像（940x540pxの24bit画像）を89KB以下にロスレス圧縮する方法※を、
どなたかご教授頂けないでしょうか。
（※webで扱える画像形式で）
ちなみにpngでも8bitだとファイルサイズは46KBまで落ちるのですが、
gif同様256色表示になる（中間色の色が変わってしまう）ので論外です。
ダメもとでsvg(309KB)を試してみたところ、最適化されないことが分かりました。
対応予定の抜け道とはベクター画像のことでしょうか?
ベクター画像のsvgはctrl + マウスホイールで拡大しても劣化しない特徴があり、
仰っている抜け道でないのであれば、
この画像を含め、3枚程差し替えたいと思いますが、OKでしょうか。
webpからwebpの再圧縮だから劣化が激しいのではなく、
最適化の際に非可逆圧縮されてしまうために劣化するのだと思われます。
最初からjpgや非可逆圧縮モードのwebpでアップしたのと同じことになってしまう訳です。
jpgや非可逆圧縮モードのwebpでも劣化が気にならないケースは多いですが、
この画像の場合、非可逆圧縮ではどうしても劣化が目立ってしまうので、
ロスレス圧縮のwebp（あるいはpng）でアップしているのです。
ええ、そうなんです。本当に些細なことなんですが、
画像最適化導入以降ずっと引っかかっているのも事実なので、
なんとか改善されないものかと思い、リクエストしてみた次第です。
色の劣化に限っては、非可逆圧縮時に-sharp_yuvオプション（より正確にRGBからYUVへの変換を行う）をつけることでかなりマシになるようです。
https://squoosh.app/ では「Sharp RGB→YUV conversion」にチェックを入れることで使えます。
ただ、圧縮に掛かる時間が少し長くなり、ファイルサイズも通常より少し増えます。
参考までにSquooshでEffort=6、Quality=70、Sharp RGB→YUV conversionにチェックして圧縮した画像です (約59KB)。パッと見で違いが分からないくらいにはなったかと思います。
スレ主さんはおそらく色の劣化が気になっていらっしゃると思うので、自前で前述の非可逆圧縮をするか、WIKIWIKI側の自動圧縮で前述のオプションを使うのはどうでしょうか？
個人的には文字色が明らかに薄くなっている以外では、他の劣化はほぼ気にならないレベルですし。
こちらでlibwebp 1.3.0を使って最大のロスレス圧縮をしてみましたが、157.382KBでした。
画像の可逆圧縮ではwebpが最強だと思うので、これ以上小さくしたいなら非可逆圧縮するしかなさそうですね。
ファイルサイズの大きいsvgでは画像圧縮の本来の目的である「転送量の削減」を悪化させてしまうので、やめておいた方が良いでしょう……。
最後にWIKIWIKI運営さんにおききしたいのですが、
ということですが、具体的にはどの解像度でどのくらいのサイズが理想なのでしょうか？
今後も同じように画像を圧縮してほしくない際の参考にもなると思うので、共有いただければ幸いです。
そのようなオプションがあったのですね。
自分が使用しているフリーの画像コンバーター(Converseen)には無かったので盲点でした。
88KBで試したところ、無事最適化をパス致しました。
なので、一先ずこのトピックは解決済みとさせていただきます。
るーさん、運営の方、ご協力いただいた皆様ありがとうございました。
仰る通りです。勿論止めにします。
賛成です。使えるなら是非お願い致します。
申し訳ございません。
写真のような解像度のSVGは非推奨とさせていただきます。
パスする基準について、参考にしてください。
インライン表示の解像度とそのリミットサイズです。
32x32 6.87KB
50x50 8.35KB
200x200 25.29KB
400x400 54.97KB
500x500 71.79KB
800x600 107.06KB
800x800 128.00KB
sharp_yuv オプションは検討いたします。
ご回答ありがとうございます。参考にさせていただきます。
運営の方に質問があるのですが、ディスコードなど外部に添付した画像をWikiに表示させたページがたくさん閲覧された場合は負担をかけることになるのでしょうか？
なるべく高画質なものを添付したい考えがありますので、Wikiのサイズ制限を回避するような形をとっておりました。
もし負担になるようでしたら、半年ごとで1日あたり10000~30000閲覧くらいあるページがいくつかあるので今まで結構な負担をかけてしまってたかなと懸念しております。
もし回避できる方法があればご教示いただければ対応いたします。
具体的にどの画像でしょうか？
掲載しているページのURLと表示させている画像を教えてください。
例えばこのページの上部に設置している画像になります。
現在は閲覧数は落ち着いてますが、6月～8月くらいになると閲覧数が爆上がりします。
https://wikiwiki.jp/eft/CUSTOMS
共有ありがとうございます。
結論から申し上げますと、負荷は問題ないと思われます。
外部画像も最適化を行っています。
実際にインラインで表示されている画像は最適化済みです。(413KB)
もとの画像サイズと比較して十分最適化されています。
相手側(cdn.discordap)へのアクセスはインライン表示では、ほぼゼロです。
クリック時に拡大表示させた時だけ相手側のCDNから直接読み込みます。(6.6MB)
ここだけ相手側とユーザー側に負荷(転送量含む)が発生します。
相手側の画像は、閉じられた空間でのアクセスを想定されていると思いますので、一度ご確認いただけたらと思います。
参考: 「外部サービスの画像コンテンツの貼り付けについて」