ご対応ありがとうござます。Headerが意図したとおり表示されることを確認しました。
この不具合の対応で上記の現象が発生しました。🙇♂️
大変遅くなり申し訳ございません。 :Header でも flexbox が動作するように対応いたしました。
実は :Header や MenuBar はスタイルに「特別ルール」が実装されています。 例えば、:Header は表組の枠線が表示されません。
昔からレイアウトを組む方法として表がよく使われてきました。 :Header では 表組にデータを入れる用途で使われないため、レイアウト専用として枠線を消していました。
このガラケー時代の名残が原因で flexbox が動作しておりませんでした。 今は flexbox があるので、不具合の原因になりやすい :Header の「特別ルール」を無くすことを検討しております。 もし、:Header で表組でレイアウトを組んでおられる方は flexbox でレイアウトを組むようにしてください。
対応いたしました。 大変ご迷惑をおかけいたしました。🙇♂️
【不具合解消のお知らせ】不具合の原因となっている箇所を修正し、2023年4月19日(水)20時43分に不具合が解消されました。大変ご迷惑をおかけしました。— WIKIWIKI【公式】 (@WIKIWIKI_Japan) April 19, 2023
【不具合解消のお知らせ】不具合の原因となっている箇所を修正し、2023年4月19日(水)20時43分に不具合が解消されました。大変ご迷惑をおかけしました。
時間を置いて元の内容を記述したところ、直りました。 一時的に発生した不具合の模様です。
ご不便をおかけして申し訳ございません。 対応しておりますので、今しばらくお待ちください。
【不具合のお知らせ】2023年4月19日(水)20時20分頃から、レイアウトが一部崩れる現象が発生しております。現在、調査しております。ご不便をおかけして申し訳ございません。今しばらくお待ちください。— WIKIWIKI【公式】 (@WIKIWIKI_Japan) April 19, 2023
【不具合のお知らせ】2023年4月19日(水)20時20分頃から、レイアウトが一部崩れる現象が発生しております。現在、調査しております。ご不便をおかけして申し訳ございません。今しばらくお待ちください。
ChromeとFirefoxで瞬時に表示されることを確認しました。 ご対応ありがとうございました。
申し訳ございません。 アイコンが常時表示される不具合が発生しておりました。 修正し、正常に動作するようにいたしました。
特定の文字列の「表記ゆれ文字の対応処理」でブラウザに負荷がかかっていたようです。 この機能を無効化して対処いたしました。
共有ありがとうございます。 結論から申し上げますと、負荷は問題ないと思われます。
外部画像も最適化を行っています。 実際にインラインで表示されている画像は最適化済みです。(413KB) もとの画像サイズと比較して十分最適化されています。
相手側(cdn.discordap)へのアクセスはインライン表示では、ほぼゼロです。 クリック時に拡大表示させた時だけ相手側のCDNから直接読み込みます。(6.6MB) ここだけ相手側とユーザー側に負荷(転送量含む)が発生します。
相手側の画像は、閉じられた空間でのアクセスを想定されていると思いますので、一度ご確認いただけたらと思います。
参考: 「外部サービスの画像コンテンツの貼り付けについて」
もし回避できる方法があればご教示いただければ対応いたします。
例えばこのページの上部に設置している画像になります。 現在は閲覧数は落ち着いてますが、6月～8月くらいになると閲覧数が爆上がりします。 https://wikiwiki.jp/eft/CUSTOMS
別の機能で提供できることもあるので、 その機能がどのような目的で必要なのかを教えていただければと思います。
上記の現象を確認しました。 調査いたしますので、今しばらくお待ちください。 ご不便をおかけして申し訳ございません。
具体的にどの画像でしょうか？ 掲載しているページのURLと表示させている画像を教えてください。
同感です。 フラッシュ機能は、使い方によっては、かつてのポケモンショック同様、 閲覧者に対し光過敏性発作を引き起こしかねません。 チカチカ鬱陶しいだけですし、個人的にも要りません。
点滅文字は設定次第で目にダメージが入ります。 そもそもスクロール文字を実装しているのは昔からの名残であると認識しており、その観点からも新たな追加は不要であると思っています。
どうしてもというのであれば、フェードイン/フェードアウトかつ、フェードインからフェードアウトまで3秒以上など、目に優しい形で制限するならば構いません。
応答不能になる例のリンク先は、ほんらいハイライトされるべきURLの文字列がハイライトされませんね。 タスクマネージャを見ていると表示が完了するまでブラウザーのCPU使用率が高いままです。 HTML Convert timeは短いことから、クライアント側の処理が上手く行ってないように見えます。 ただ普通にブラウザー側の機能の文字列検索を使えば一瞬で対象がハイライトされます。wikiwikiがhtmlに仕込ませてるscript処理になにか問題があるのだと思います。
詳しく検証してみました。
応答不能になる条件 同じページに後半(末尾)が異なる文字列がある 文字列にアルファベットが多い場合(数字のみでは起こらない)
ページの例
HHHHHGGGGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0 (全41文字) HHHHHGGGGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA1 (全41文字)
HHHHHGGGGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0 (全41文字)
HHHHHGGGGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA1 (全41文字)
Chromeで「これらのキーワードがハイライトされています」が表示されるまでの時間は ”FFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(31文字)の場合6秒 ”GFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(32文字)の場合13秒 ”GGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(33文字)の場合32秒 ”GGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(34文字)の場合1分39秒 ”GGGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(35文字)の場合2分15秒 と1文字増えるごとにかなり時間が伸びました。 (途中で「ページが応答しません」となっても放置した場合)
なお、どちらの行にも共通する ”HHHHHGGGGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA”(40文字)の場合は瞬時に表示されます。
運営の方に質問があるのですが、ディスコードなど外部に添付した画像をWikiに表示させたページがたくさん閲覧された場合は負担をかけることになるのでしょうか？ なるべく高画質なものを添付したい考えがありますので、Wikiのサイズ制限を回避するような形をとっておりました。
もし負担になるようでしたら、半年ごとで1日あたり10000~30000閲覧くらいあるページがいくつかあるので今まで結構な負担をかけてしまってたかなと懸念しております。 もし回避できる方法があればご教示いただければ対応いたします。
ご返信ありがとうございます。 再現性のある現象のようで安心しました。修正を期待しております。
ご回答ありがとうございます。参考にさせていただきます。
ダメもとでsvg(309KB)を試してみたところ、最適化されないことが分かりました。
申し訳ございません。 写真のような解像度のSVGは非推奨とさせていただきます。
ということですが、具体的にはどの解像度でどのくらいのサイズが理想なのでしょうか？ 今後も同じように画像を圧縮してほしくない際の参考にもなると思うので、共有いただければ幸いです。
パスする基準について、参考にしてください。 インライン表示の解像度とそのリミットサイズです。
32x32 6.87KB 50x50 8.35KB 200x200 25.29KB 400x400 54.97KB 500x500 71.79KB 800x600 107.06KB 800x800 128.00KB
sharp_yuv オプションは検討いたします。
色の劣化に限っては、非可逆圧縮時に-sharp_yuvオプション（より正確にRGBからYUVへの変換を行う）をつけることでかなりマシになるようです。
そのようなオプションがあったのですね。 自分が使用しているフリーの画像コンバーター(Converseen)には無かったので盲点でした。 88KBで試したところ、無事最適化をパス致しました。
なので、一先ずこのトピックは解決済みとさせていただきます。 るーさん、運営の方、ご協力いただいた皆様ありがとうございました。
ファイルサイズの大きいsvgでは画像圧縮の本来の目的である「転送量の削減」を悪化させてしまうので、やめておいた方が良いでしょう……。
仰る通りです。勿論止めにします。
WIKIWIKI側の自動圧縮でsharp_yuvオプションを使うのはどうでしょうか？
賛成です。使えるなら是非お願い致します。
色の劣化に限っては、非可逆圧縮時に-sharp_yuvオプション（より正確にRGBからYUVへの変換を行う）をつけることでかなりマシになるようです。 https://squoosh.app/ では「Sharp RGB→YUV conversion」にチェックを入れることで使えます。 ただ、圧縮に掛かる時間が少し長くなり、ファイルサイズも通常より少し増えます。
参考までにSquooshでEffort=6、Quality=70、Sharp RGB→YUV conversionにチェックして圧縮した画像です (約59KB)。パッと見で違いが分からないくらいにはなったかと思います。
スレ主さんはおそらく色の劣化が気になっていらっしゃると思うので、自前で前述の非可逆圧縮をするか、WIKIWIKI側の自動圧縮で前述のオプションを使うのはどうでしょうか？
個人的には文字色が明らかに薄くなっている以外では、他の劣化はほぼ気にならないレベルですし。
この画像（940x540pxの24bit画像）を89KB以下にロスレス圧縮する方法
こちらでlibwebp 1.3.0を使って最大のロスレス圧縮をしてみましたが、157.382KBでした。 画像の可逆圧縮ではwebpが最強だと思うので、これ以上小さくしたいなら非可逆圧縮するしかなさそうですね。
svg(309KB)を試してみたところ、最適化されないことが分かりました
最後にWIKIWIKI運営さんにおききしたいのですが、
解像度に見合った最適解のファイルサイズがある
89kb 以下の画像サイズにするとパスするかも知れません。
この画像（940x540pxの24bit画像）を89KB以下にロスレス圧縮する方法※を、 どなたかご教授頂けないでしょうか。 （※webで扱える画像形式で）
ちなみにpngでも8bitだとファイルサイズは46KBまで落ちるのですが、 gif同様256色表示になる（中間色の色が変わってしまう）ので論外です。
現在でも抜け道はありますが、対応する予定です。
ダメもとでsvg(309KB)を試してみたところ、最適化されないことが分かりました。 対応予定の抜け道とはベクター画像のことでしょうか? ベクター画像のsvgはctrl + マウスホイールで拡大しても劣化しない特徴があり、 仰っている抜け道でないのであれば、 この画像を含め、3枚程差し替えたいと思いますが、OKでしょうか。
webp からの webp は劣化が激しいと思います。
webpからwebpの再圧縮だから劣化が激しいのではなく、 最適化の際に非可逆圧縮されてしまうために劣化するのだと思われます。 最初からjpgや非可逆圧縮モードのwebpでアップしたのと同じことになってしまう訳です。
jpgや非可逆圧縮モードのwebpでも劣化が気にならないケースは多いですが、 この画像の場合、非可逆圧縮ではどうしても劣化が目立ってしまうので、 ロスレス圧縮のwebp（あるいはpng）でアップしているのです。
利用者が認識困難でなければ、許容範囲内ではないかと思います。
ええ、そうなんです。本当に些細なことなんですが、 画像最適化導入以降ずっと引っかかっているのも事実なので、 なんとか改善されないものかと思い、リクエストしてみた次第です。
一個人の意見でありますが文字認識及び、グラフィックがぼやける等で利用者が認識困難でなければ、許容範囲内ではないかと思います。
640x540 ですと 89kb 以下の画像サイズにするとパスするかも知れません。 下の ds_command panel.png 640x360 29kb はパスしてますね。
共有ありがとうございます。 許容範囲かどうか、みなさんのご意見を聞かせていただけたらと思います。
画像直リンク
もとの画像がwebpでアップされています。 webp の 181kb はサイズが大きいと判断して再圧縮されている可能性があります。 webp からの webp は劣化が激しいと思います。
他のフォーマットでも妥当な画像サイズなら最適化なしでそのまま表示されますので、 お試しいただけたら幸いです。
こちらのページになります。 問題の画像は中央のインベントリー画像(640x540px)で、以前はpngでしたが、 現在はロスレスのwebp(176MB)に差し替えて、以前のpngは削除済みです。
敢えてnolink指定していないので、クリックで実際の添付画像と容易に比較できます。 比較すると、特にカラー文字（ブルー、オレンジ、グリーン）が劣化しているのが一目瞭然かと思います。 画像最適化が導入されて以降、こうなっているのですが、 その下のpng画像(640x360px, 28KB)は現在でも問題ありません。
ページの最大添付画像数はどのくらいなら許容できるでしょうか？
「総容量」ではなく「総枚数」なのですね… 咄嗟には見当がつかないので、自分も皆さんの意見を伺ってみたいです。 小さい画像を沢山貼っていると不利になると思うので、 （当wikiだと各種所持品一覧とかが該当するんですよね…） 可能なら「総枚数」でなく「総容量」にしていただけるとありがたいです。 （枚数は減らせなくても、ファイルサイズならある程度の調整が可能です）
アクセスがあるページほど、画像の圧縮率が高くなるようなことは避けたいと考えております
同意致します。 運営側から見れば、アクセス数の多いページ程データ転送量が増えるので、 シビアな調整をお願いしたい…となるのでしょうが、 アクセス数の多いwikiとそうでないwikiとの処遇格差につながりかねないので、 それはやめた方がいいと思います。
上記のように、640x540pxのwebp画像を640x540で表示していますが、劣化して表示されます。 それとも解像度に見合った最適解のファイルサイズがあるということでしょうか。
あります。 よろしければ掲載しているURLをここで共有していただくことは可能でしょうか？ 今後の最適化の調整の参考とさせていただきます。
上記画像の添付ページは、添付枚数が3枚(jpg,webp,png各1枚)、容量は合計674KBですが、 「ページあたりの上限設定を超えない限り、そのページの画像最適化は行わない」とした場合、 ページ上限は、どの程度が想定されるでしょうか。
申し訳ございません。 逆に質問になってしまうのですが、ページの最大添付画像数はどのくらいなら許容できるでしょうか？
例えば、計算しやすいように1ページあたり最大4枚とします。 容量は1ページあたり最大2MB、1日1000人がそのページを閲覧すると、転送量が1日およそ2GBになります。 （そのくらい訪問数があるページが多数あります）
実際は「Lagy load」や「ブラウザキャッシュ」でそこまで転送量が発生しません。 でも、最大4枚は少なすぎなのに転送量がそこそこあります。
新しい機能を実装すると全てのWIKIに適用されることになります。 個別のWIKIだけに適用することはできません。 アクセス数があるWIKIに適用されることも想定しているのでシビアになってしまいます。
また、アクセス数で調整する方法もありますが、アクセスがあるページほど、画像の圧縮率が高くなるようなことは避けたいと考えております。アクセス数で画像の解像度が動的に変わると気持ち悪いですし、CDNのキャシュ効率も悪くなります。
今後の開発の参考にさせていただきますので、 引き続き、他のユーザーの意見も交えて議論いただけたら幸いです。
返答ありがとうございます。
具体例として挙げた画像(png, webp)は640x540pxで、 縮小・拡大表示はしていないのですが、 webpでもロスレス圧縮だとこれ以上ファイルサイズが小さくならないようなので、 対応できないということであれば一先ず諦めるしかなさそうですね…
表示させたい画像サイズ(ピクセル)に合わせた画像を用意していただくことで劣化を防ぐことができます。
どういう意味でしょうか? 上記のように、640x540pxのwebp画像を640x540で表示していますが、劣化して表示されます。 それとも解像度に見合った最適解のファイルサイズがあるということでしょうか。
1ページあたりの使える画像数の制限を入れる(実装は容易)
ご不便をおかけして申し訳ございません。 転送量削減のため、表示画像の最適化を行っております。
実際の画像サイズ(容量)と画像サイズ(ピクセル)、圧縮フォーマットをもとにして、 表示させる画像サイズ(ピクセル)に合わせて最適化しています。
極端な例ですが、実際の画像サイズ(100px,100px)なのに、アイコンとして画像サイズ(25px,25px)で表示させようとすると画像サイズ(25px,25px)より、ちょっと大きめで最適化されます。
512MBを超過しない限り最適化されないように設定変更していただくか、 あるいは指定画像のみ最適化されない表示オプションを追加していただくことは可能でしょうか。
このような抜け道を追加することは難しいです。 現在でも抜け道はありますが、対応する予定です。
良いアイディアがあれば、引き続きこちらで議論していただけると幸いです。
例えば… 以下の条件で画像を最適化しない
など…
同事象でお困りの管理者やWiki関係者にも当トピックがお役に立つよう、願っております。
また、このSMS認証は制限に巻き込まれた場合の救済措置機能です。
「投稿するにはSMS認証が必要です」とでた場合 https://wikiwiki.jp/pp/sms
かしこまりました。運営としてできる限りの対処を行っていただき、ありがとうございます。 規制対象者が立ち去るまでは、その他多くの利用者にも不便を強いられることになるのは致し方ないですね。
既にご存知の通り、SMS認証のCookieを削除することで未認証端末になります。 永続的に特定のユーザーをマーキングすることができません。 ご理解いただきますようお願い申し上げます。
追記: つまり、SMSトークン単体の規制だけでは、クッキーでの規制と同じことになります。
上記は「その他/旧WIKI/*」についてです。 SMS認証の必要のあるページにしか効力が発生せず、通常ユーザーにもSMS認証を求められます。 通常ユーザーにはSMS認証が心理的負担が大きく、情報提供される機会を阻害されてしまいます。 すでに当Wikiにも過去に検証しており、Wikiの改善や情報提供などの編集される日が激減して、規制ルールを取りやめております。
要望としてSMSトークンの規制対象者のみ、ワイルドカードを使用している対象ページまたは、全ページに効果があるように仕様の変更を希望いたします。 多くの利用者は、SMS認証をしてまでWikiの編集をしてくれません。他のWikiでは、SMS認証せずに編集できるからと思う人もいるからです。電話番号を伝えることに抵抗を感じる人は少なくありません。少なくとも通常の利用者には、これまで通りにSMS認証なく編集ができる上で、SMSトークンの規制が働くことが望ましいです。
修正のご対応を行っていただき、ありがとうございます。 当方でも規制されて編集できないことを確認いたしました。
ご不便をおかけして申し訳ございません。 半角のスラッシュ/がワイルドカードでマッチできていませんでした。 修正しましたので再度お試し下さい。
/
承知しました。 ご検討よろしくお願いします。
ご対応ありがとうござます。Headerが意図したとおり表示されることを確認しました。
この不具合の対応で上記の現象が発生しました。🙇♂️
大変遅くなり申し訳ございません。
:Header でも flexbox が動作するように対応いたしました。
実は :Header や MenuBar はスタイルに「特別ルール」が実装されています。
例えば、:Header は表組の枠線が表示されません。
昔からレイアウトを組む方法として表がよく使われてきました。
:Header では 表組にデータを入れる用途で使われないため、レイアウト専用として枠線を消していました。
このガラケー時代の名残が原因で flexbox が動作しておりませんでした。
今は flexbox があるので、不具合の原因になりやすい :Header の「特別ルール」を無くすことを検討しております。
もし、:Header で表組でレイアウトを組んでおられる方は flexbox でレイアウトを組むようにしてください。
対応いたしました。
大変ご迷惑をおかけいたしました。🙇♂️
時間を置いて元の内容を記述したところ、直りました。
一時的に発生した不具合の模様です。
ご不便をおかけして申し訳ございません。
対応しておりますので、今しばらくお待ちください。
ChromeとFirefoxで瞬時に表示されることを確認しました。
ご対応ありがとうございました。
申し訳ございません。
アイコンが常時表示される不具合が発生しておりました。
修正し、正常に動作するようにいたしました。
特定の文字列の「表記ゆれ文字の対応処理」でブラウザに負荷がかかっていたようです。
この機能を無効化して対処いたしました。
共有ありがとうございます。
結論から申し上げますと、負荷は問題ないと思われます。
外部画像も最適化を行っています。
実際にインラインで表示されている画像は最適化済みです。(413KB)
もとの画像サイズと比較して十分最適化されています。
相手側(cdn.discordap)へのアクセスはインライン表示では、ほぼゼロです。
クリック時に拡大表示させた時だけ相手側のCDNから直接読み込みます。(6.6MB)
ここだけ相手側とユーザー側に負荷(転送量含む)が発生します。
相手側の画像は、閉じられた空間でのアクセスを想定されていると思いますので、一度ご確認いただけたらと思います。
参考: 「外部サービスの画像コンテンツの貼り付けについて」
例えばこのページの上部に設置している画像になります。
現在は閲覧数は落ち着いてますが、6月～8月くらいになると閲覧数が爆上がりします。
https://wikiwiki.jp/eft/CUSTOMS
別の機能で提供できることもあるので、
その機能がどのような目的で必要なのかを教えていただければと思います。
上記の現象を確認しました。
調査いたしますので、今しばらくお待ちください。
ご不便をおかけして申し訳ございません。
具体的にどの画像でしょうか？
掲載しているページのURLと表示させている画像を教えてください。
同感です。
フラッシュ機能は、使い方によっては、かつてのポケモンショック同様、
閲覧者に対し光過敏性発作を引き起こしかねません。
チカチカ鬱陶しいだけですし、個人的にも要りません。
点滅文字は設定次第で目にダメージが入ります。
そもそもスクロール文字を実装しているのは昔からの名残であると認識しており、その観点からも新たな追加は不要であると思っています。
どうしてもというのであれば、フェードイン/フェードアウトかつ、フェードインからフェードアウトまで3秒以上など、目に優しい形で制限するならば構いません。
応答不能になる例のリンク先は、ほんらいハイライトされるべきURLの文字列がハイライトされませんね。
タスクマネージャを見ていると表示が完了するまでブラウザーのCPU使用率が高いままです。
HTML Convert timeは短いことから、クライアント側の処理が上手く行ってないように見えます。
ただ普通にブラウザー側の機能の文字列検索を使えば一瞬で対象がハイライトされます。wikiwikiがhtmlに仕込ませてるscript処理になにか問題があるのだと思います。
詳しく検証してみました。
応答不能になる条件
同じページに後半(末尾)が異なる文字列がある
文字列にアルファベットが多い場合(数字のみでは起こらない)
ページの例
Chromeで「これらのキーワードがハイライトされています」が表示されるまでの時間は
”FFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(31文字)の場合6秒
”GFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(32文字)の場合13秒
”GGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(33文字)の場合32秒
”GGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(34文字)の場合1分39秒
”GGGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(35文字)の場合2分15秒
と1文字増えるごとにかなり時間が伸びました。
(途中で「ページが応答しません」となっても放置した場合)
なお、どちらの行にも共通する
”HHHHHGGGGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA”(40文字)の場合は瞬時に表示されます。
運営の方に質問があるのですが、ディスコードなど外部に添付した画像をWikiに表示させたページがたくさん閲覧された場合は負担をかけることになるのでしょうか？
なるべく高画質なものを添付したい考えがありますので、Wikiのサイズ制限を回避するような形をとっておりました。
もし負担になるようでしたら、半年ごとで1日あたり10000~30000閲覧くらいあるページがいくつかあるので今まで結構な負担をかけてしまってたかなと懸念しております。
もし回避できる方法があればご教示いただければ対応いたします。
ご返信ありがとうございます。
再現性のある現象のようで安心しました。修正を期待しております。
ご回答ありがとうございます。参考にさせていただきます。
申し訳ございません。
写真のような解像度のSVGは非推奨とさせていただきます。
パスする基準について、参考にしてください。
インライン表示の解像度とそのリミットサイズです。
32x32 6.87KB
50x50 8.35KB
200x200 25.29KB
400x400 54.97KB
500x500 71.79KB
800x600 107.06KB
800x800 128.00KB
sharp_yuv オプションは検討いたします。
そのようなオプションがあったのですね。
自分が使用しているフリーの画像コンバーター(Converseen)には無かったので盲点でした。
88KBで試したところ、無事最適化をパス致しました。
なので、一先ずこのトピックは解決済みとさせていただきます。
るーさん、運営の方、ご協力いただいた皆様ありがとうございました。
仰る通りです。勿論止めにします。
賛成です。使えるなら是非お願い致します。
色の劣化に限っては、非可逆圧縮時に-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運営さんにおききしたいのですが、
ということですが、具体的にはどの解像度でどのくらいのサイズが理想なのでしょうか？
今後も同じように画像を圧縮してほしくない際の参考にもなると思うので、共有いただければ幸いです。
この画像（940x540pxの24bit画像）を89KB以下にロスレス圧縮する方法※を、
どなたかご教授頂けないでしょうか。
（※webで扱える画像形式で）
ちなみにpngでも8bitだとファイルサイズは46KBまで落ちるのですが、
gif同様256色表示になる（中間色の色が変わってしまう）ので論外です。
ダメもとでsvg(309KB)を試してみたところ、最適化されないことが分かりました。
対応予定の抜け道とはベクター画像のことでしょうか?
ベクター画像のsvgはctrl + マウスホイールで拡大しても劣化しない特徴があり、
仰っている抜け道でないのであれば、
この画像を含め、3枚程差し替えたいと思いますが、OKでしょうか。
webpからwebpの再圧縮だから劣化が激しいのではなく、
最適化の際に非可逆圧縮されてしまうために劣化するのだと思われます。
最初からjpgや非可逆圧縮モードのwebpでアップしたのと同じことになってしまう訳です。
jpgや非可逆圧縮モードのwebpでも劣化が気にならないケースは多いですが、
この画像の場合、非可逆圧縮ではどうしても劣化が目立ってしまうので、
ロスレス圧縮のwebp（あるいはpng）でアップしているのです。
ええ、そうなんです。本当に些細なことなんですが、
画像最適化導入以降ずっと引っかかっているのも事実なので、
なんとか改善されないものかと思い、リクエストしてみた次第です。
一個人の意見でありますが文字認識及び、グラフィックがぼやける等で利用者が認識困難でなければ、許容範囲内ではないかと思います。
640x540 ですと 89kb 以下の画像サイズにするとパスするかも知れません。
下の ds_command panel.png 640x360 29kb はパスしてますね。
共有ありがとうございます。
許容範囲かどうか、みなさんのご意見を聞かせていただけたらと思います。
画像直リンク
もとの画像がwebpでアップされています。
webp の 181kb はサイズが大きいと判断して再圧縮されている可能性があります。
webp からの webp は劣化が激しいと思います。
他のフォーマットでも妥当な画像サイズなら最適化なしでそのまま表示されますので、
お試しいただけたら幸いです。
こちらのページになります。
問題の画像は中央のインベントリー画像(640x540px)で、以前はpngでしたが、
現在はロスレスのwebp(176MB)に差し替えて、以前のpngは削除済みです。
敢えてnolink指定していないので、クリックで実際の添付画像と容易に比較できます。
比較すると、特にカラー文字（ブルー、オレンジ、グリーン）が劣化しているのが一目瞭然かと思います。
画像最適化が導入されて以降、こうなっているのですが、
その下のpng画像(640x360px, 28KB)は現在でも問題ありません。
「総容量」ではなく「総枚数」なのですね…
咄嗟には見当がつかないので、自分も皆さんの意見を伺ってみたいです。
小さい画像を沢山貼っていると不利になると思うので、
（当wikiだと各種所持品一覧とかが該当するんですよね…）
可能なら「総枚数」でなく「総容量」にしていただけるとありがたいです。
（枚数は減らせなくても、ファイルサイズならある程度の調整が可能です）
同意致します。
運営側から見れば、アクセス数の多いページ程データ転送量が増えるので、
シビアな調整をお願いしたい…となるのでしょうが、
アクセス数の多いwikiとそうでないwikiとの処遇格差につながりかねないので、
それはやめた方がいいと思います。
あります。
よろしければ掲載しているURLをここで共有していただくことは可能でしょうか？
今後の最適化の調整の参考とさせていただきます。
申し訳ございません。
逆に質問になってしまうのですが、ページの最大添付画像数はどのくらいなら許容できるでしょうか？
例えば、計算しやすいように1ページあたり最大4枚とします。
容量は1ページあたり最大2MB、1日1000人がそのページを閲覧すると、転送量が1日およそ2GBになります。
（そのくらい訪問数があるページが多数あります）
実際は「Lagy load」や「ブラウザキャッシュ」でそこまで転送量が発生しません。
でも、最大4枚は少なすぎなのに転送量がそこそこあります。
新しい機能を実装すると全てのWIKIに適用されることになります。
個別のWIKIだけに適用することはできません。
アクセス数があるWIKIに適用されることも想定しているのでシビアになってしまいます。
また、アクセス数で調整する方法もありますが、アクセスがあるページほど、画像の圧縮率が高くなるようなことは避けたいと考えております。アクセス数で画像の解像度が動的に変わると気持ち悪いですし、CDNのキャシュ効率も悪くなります。
今後の開発の参考にさせていただきますので、
引き続き、他のユーザーの意見も交えて議論いただけたら幸いです。
返答ありがとうございます。
具体例として挙げた画像(png, webp)は640x540pxで、
縮小・拡大表示はしていないのですが、
webpでもロスレス圧縮だとこれ以上ファイルサイズが小さくならないようなので、
対応できないということであれば一先ず諦めるしかなさそうですね…
どういう意味でしょうか?
上記のように、640x540pxのwebp画像を640x540で表示していますが、劣化して表示されます。
それとも解像度に見合った最適解のファイルサイズがあるということでしょうか。
上記画像の添付ページは、添付枚数が3枚(jpg,webp,png各1枚)、容量は合計674KBですが、
「ページあたりの上限設定を超えない限り、そのページの画像最適化は行わない」とした場合、
ページ上限は、どの程度が想定されるでしょうか。
ご不便をおかけして申し訳ございません。
転送量削減のため、表示画像の最適化を行っております。
実際の画像サイズ(容量)と画像サイズ(ピクセル)、圧縮フォーマットをもとにして、
表示させる画像サイズ(ピクセル)に合わせて最適化しています。
極端な例ですが、実際の画像サイズ(100px,100px)なのに、アイコンとして画像サイズ(25px,25px)で表示させようとすると画像サイズ(25px,25px)より、ちょっと大きめで最適化されます。
表示させたい画像サイズ(ピクセル)に合わせた画像を用意していただくことで劣化を防ぐことができます。
このような抜け道を追加することは難しいです。
現在でも抜け道はありますが、対応する予定です。
良いアイディアがあれば、引き続きこちらで議論していただけると幸いです。
例えば… 以下の条件で画像を最適化しない
など…
同事象でお困りの管理者やWiki関係者にも当トピックがお役に立つよう、願っております。
また、このSMS認証は制限に巻き込まれた場合の救済措置機能です。
「投稿するにはSMS認証が必要です」とでた場合
https://wikiwiki.jp/pp/sms
かしこまりました。運営としてできる限りの対処を行っていただき、ありがとうございます。
規制対象者が立ち去るまでは、その他多くの利用者にも不便を強いられることになるのは致し方ないですね。
既にご存知の通り、SMS認証のCookieを削除することで未認証端末になります。
永続的に特定のユーザーをマーキングすることができません。
ご理解いただきますようお願い申し上げます。
追記:
つまり、SMSトークン単体の規制だけでは、クッキーでの規制と同じことになります。
上記は「その他/旧WIKI/*」についてです。
SMS認証の必要のあるページにしか効力が発生せず、通常ユーザーにもSMS認証を求められます。
通常ユーザーにはSMS認証が心理的負担が大きく、情報提供される機会を阻害されてしまいます。
すでに当Wikiにも過去に検証しており、Wikiの改善や情報提供などの編集される日が激減して、規制ルールを取りやめております。
要望としてSMSトークンの規制対象者のみ、ワイルドカードを使用している対象ページまたは、全ページに効果があるように仕様の変更を希望いたします。
多くの利用者は、SMS認証をしてまでWikiの編集をしてくれません。他のWikiでは、SMS認証せずに編集できるからと思う人もいるからです。電話番号を伝えることに抵抗を感じる人は少なくありません。少なくとも通常の利用者には、これまで通りにSMS認証なく編集ができる上で、SMSトークンの規制が働くことが望ましいです。
修正のご対応を行っていただき、ありがとうございます。
当方でも規制されて編集できないことを確認いたしました。
ご不便をおかけして申し訳ございません。
半角のスラッシュ
/がワイルドカードでマッチできていませんでした。修正しましたので再度お試し下さい。
承知しました。
ご検討よろしくお願いします。