>>408
ロスレスAVIFは圧縮ゴミでロスレスjxlはエンコが遅え
ロスレスwebpはバランスがいいんだ!
問題はロスレス圧縮需要がいうほどないってことなんだ!

>>4を見てもまだwebpを推せるか？

>>412
分かる
でもjxlは可逆も透過もアニメーションも対応してるからバリエーション作るの大変そう

>>413
推せるよ。だってあの表、現時点では嘘だし
可逆jxlのエンコード・デコードは糞遅い
特にデコードが遅いってのは連続して画像を見るときかなりのストレスになる

>>420
webpはappleが対応してから割とすぐデフォルトで使えるようになったし
avifはedge待ちかな、wordpressに限った話じゃないかもだけど

エンコード速度じゃなくてデコード速度を比較してほしいよね
>>423

>>4を見るとAVIFは8193x4320までしか対応してないように見えるけど普通にそれ以上のサイズも作れるね
実際に作った画像のURLを貼りたいけどNG食らった

元々>>4のようにコーデックの中で最速クラスみたいな宣伝してたけど別にそんなことはないというだけの話

>>17と比べてお友達増えたな

>>445
nightlyがちゃっかり旗持ってるのウケる

>>451
画像によってはavifに勝ってるし結構いい方だと思うけど

>>450
これって実際どれくらい本気度あるんすかね?
イシューを再オープンしたがいつ実装するとは言ってない、その気になればウン十年後も可能
みたいな

>>458
HNで騒いでるひと
ぬか喜びにならんきゃいいけど、、、

>>463
mozjpeg

>>474
何も知らないなら何も言わないほうが良いぞ
馬鹿がバレるから

>>482
pngはdeflate圧縮だけ

>>494
JPEG 2000はPDFをOSレベルでサポートする為だろう

>>500
黎明期or過渡期においては、バリエーションが増えるだけで置き換わるわけではないよ（jxl非対応クライアントでは従来のフォーマットにフォールバック）

>>504
JPEG-HDRとはまた別の形式か？どれのことか知りたい

>>504
これ >>274 （Ultra HDR）のことなら、つい最近下記記事が出てた

Googleフォトに画期的アップデートか、いよいよUltra HDRをサポート | Forbes JAPAN 公式サイト（フォーブス ジャパン）
https://forbesjapan.com/articles/detail/65705

>>511
iPhoneでHDR画像が普通なのは何年も前から常識なんだが
HEIC形式で

>>520
不具合があることと、不具合が発覚することは別の概念

>>523
WebPのゼロデイ脆弱性は「Teams」や「Skype」にも 〜Microsoftが影響製品を公表
https://forest.watch.impress.co.jp/docs/news/1536304.html
昨日の更新で修正されたようだ

>>526
アドビのフェローを名乗ってる怪しいやつがアドビの主要アプリでも対応する予定だって書いてる

>>526
JPEG-XLの半分を開発した有名な研究者がこんな感じのこと書いてるね
この人、Google所属なんだから社内のChromeチームと調整してくれよ

> 高品質なRustデコーダの実装が、JPEG XLをinterop 2024に選択する唯一の決め手となるのであれば、Google ResearchのJPEG XL開発チームは、2024年第2四半期末までにそれを提供することができます。

>>532
avifチームがね

>>540
jxlは最近Safariが対応した

>>545
最近こういう技術解説のほとんどが機械翻訳だからなあ
MSのドキュメントでもコードの中まで翻訳しちゃってることがあった
まあ開発系は英語で読むのが普通だけど

>>556
一番新しいバージョンのiOS以外対応してないから

>>563
そもそもjxlに対応してないし

>>562
HWデコード対応かどうかは使用ソフトによって変わるので
具体的に名前書くか開発元に問い合わせるべし
まぁ現状だと大抵は未対応かと

>>563
Termuxはリファレンス実装の最新版を公式サポートしてる

>>526
残念ながら今年も採択されなかった

>>592
ジジイの主観を一般化するのは無理がある

>>599
マイルストーンのページを見れば分かる

1.0 version

78% complete
24 open
90 closed

>>620
多分そう
あんま使わんけどEPUBとかも新しいの対応してほしいなあ

>>636
絵の女の子の太ももなんかは光らせてる箇所が斑点でグラデーション表示されてるんだけど元画像とwebp比較してみると薄くなって消されてる箇所があるのよ
劣化が不安やから高画質の画像で比較した
blob:https://imgur.com/39ada4a2-6425-482b-9bbe-e1fc8fc484cf

>>641
そうなんだ？
昔のエロＣＧ集20万点の解像度850×とかだからそれなら問題ないってことか
>>635
jxlは自分の環境ではサムネ表示されないから使いたくないな
コーデック入れたらええのかもしれんが

>>643
さすがに解凍しないと見れないのは嫌やな
動画化はちょっと…写真じゃなくなるのは後悔しそう
そこまでするなら動画何個か消すわｗｗ

>>391にあるやつか

>>621とか

>>669
libjxlが一向に完成しないから無理

>>683
遅いね>>621

>>684
雇用コストや肝心の寿司の品質低下を伴わない前提なら、そうかもね

>>690
いや使わなくてもjxlのが早いよ
まあ画像のためのフォーマットなんだからwebp.avifみたいな派生より性能いいのは当たり前だけど

>>706
DCTが不可逆と思ってる時点で信憑性がな…

>>721
へえ、こんな風にできるのか

>>725
グロ死ね

>>231
ファンなら絶対見逃せないです」

>>731
死ね
>>735
グロ

>>736
グロ

>>743
グロ

>>746
死ね

>>752
グロ死ね
お前を殺してやろうか？

>>754
死ね

まとりあえず脳死でJPEGで圧縮しても
後からJXL可逆再圧縮で新フォーマットの恩恵を受けられるしな

>>773
編集用のソースとしては非可逆圧縮はやめといたほうがいいね
まぁ別に画像に限った話ではないけれど

>>776
いいえ

>>782
いいね
heifとか使われても困るしな

>>790
v1.0 ラベルの付いたチケットはあと20個あるね
中には2年間手つかずのものもあったり

webpも解像度最大16383 x 16383なのね
AVIFは>>768の通り更に小さい
pngは仕様よく知らんがとりあえず2万くらいでは特に問題起きてない

新しいフォーマットであるほど制限が厳しいってどういうことだよ

>>808
pngはただのdaflateだし
zipはサイズ制限無いだろ？

>>811 ごめん2^31-1だ

>>819
既存のライブラリと新規に追加するライブラリでは評価基準が違うの当たり前だろ

>>822
jxlの場合3割くらい

>>840
macOSやiOSのアイコンで一時期デフォルトになってた
PNGよりサイズ小さくなって透過使えるからね

>>847
手順ミスってるだろｗ
cjxl test.jpg test.jxl -q 100
djxl test.jxl test2.jpg
でtest.jpgとtest2.jpgは同一ファイルになる
差分が出るのはjxlをデコードするのとjpgに戻してからデコードするのじゃ結果が違うからとしか言いようがない
jxlをそのまま表示する方が画質は良いはず

>>858
まさかのノーガードw
悪いことは言わない、FWでホワイトリスト管理しなさい

>>863
Proの設定画面を見た感じ、JPEG XLがHEIFより優れていると Appleも認めたようなので
そこはまぁ重要な第一歩かなと

>>865
いいけど有料ライセンスなんで広まることはないです

>>874
AVIFはWebPより良いという通説なんで、今のところJPEGの代わりにはAVIFが一番良いということになってる
JPEG-XLがどうなるか分からんが、少なくともChromeでサポートされないんじゃ絶望的だろう

>>881
こういうの見方分からん

>>886
これってエンコード速度の比較だろう？
画像のエンコード速度ってそんなに重要かね

>>893
いや、jxlは全然違う色空間を使ってるでしょ
それが高圧縮の理由だ
何も知らないんだなw
やっぱり良いことばかりじゃないんだな

>>896
そのサイトの注意書き
「JPEG XLの結果は複雑です。品質設定が実際には通常モードとモジュラーモードの間で動的に選択するため、品質レベルに応じて2つの異なる動作モードが表示されることになります。
この動作は単調ではない可能性がありますが、高品質レベルでは問題なく、代替手段 (以前は通常モードのみを使用していたもの)よりも優れています」
「AVIF画像はビット深度10で生成されています。報告によると、AV1は量子化に問題があり、ビット深度8でバンディングが発生します」

どちらも信頼性が高い技術なるまで時間がかかるから、今のところ参考程度の比較になる。

>>903
普及させたがっていることを前提とした認識そのものを含めてキミの感覚はズレてるぞw

普及率向上を狙うなら、知らぬ間に「生成してた（カメラ、スクショ、エディタ）」「閲覧してた（ブラウザ、ビューア）」、といった状況を作り出すことこそが肝心
個別のGUIアプリの利用者は当該フォーマットが完全に普及しきった段階で初めて出現するのであって、現段階で公開したところで事実上誰にも使われず、普及率向上に寄与することはない

>>903
Crusheeでよくない？avifなら

>>909-910
ごめん勝手にJPEGだと思い込んでたけど、例え画像が無圧縮であれ圧縮データであれdeflateじゃそのまま画像を圧縮するのに比べてBASE64化のデータ量4/3倍のペナルティを上回るような圧縮は行えないと思う。
文字数のパターンが減ればハフマン符号最適化なんかの恩恵も減るし。

>>922は2週間前に修正された脆弱性だね
修正と同時に報告したように見える
修正前のライブラリを使ってるアプリはアップデートしないと悪意あるJXLファイルを開いたときにアプリがクラッシュする危険性がある
もしOSやブラウザがこのライブラリを使ってたら緊急アップデートを配布することになってたかも
こういうことがあるとやっぱJXLはChromeから切り離して正解だったなって思う
JXLは基本設計が悪意に対して無防備すぎる
高画質高圧縮なんだから多少ブラクラに悪用されてもしょうがないよねとか言ってたらそりゃChromeだってサポートしないよ

>>896はまだしも>>657は割と致命的じゃね？

>>945
デコード速いから可逆webp好きだけどさすがにavifの方が圧縮率高いわ

>>948
XnConvert使っててavifロスレス速度4の設定で圧縮してるけど、webpロスレス圧縮方法6より大抵縮むけどな
低解像度のアイコンみたいなサンプルならまた違うんだろうけど

>>955
AVIFのロスレスは現状縮まないよ
あなたみたいにwebpより縮むと言ってる人は
-q 100だけ付けて-l付けてなくてロスレスにならない状態でエンコードして勘違いしてるんだと思うよ
コマンドラインには警告出るんだけどね

>>959-960
https://newsgroup.xnview.com/viewtopic.php?f=79&t=48215
↑そういうことなのね、すまんかった

本人は納得してくれたみたいで良いとして
>>956みたいな勝ち馬に乗ったつもりの知ったかくんが一番痛々しい

webp2ってどうなった？