JPEGの後継画像フォーマットについて議論するスレ 2
自分で試せば戻るって分かるだろ
そもそもprogressiveはDCT係数をピクセルごとに並べる代わりに低周波数から順に並べてるだけなんだから
ロスレスで変換できるのは当たり前 探してみたらJpegcropってフリーソフトで
プログレッシブJPEGを開いて保存するだけで外せるんだなw
てか自分なりに最適化してみたけど
プログレッシブJPEGのほうが低容量でむしろ良いのか…?
場合によるのかな
プログレッシブJPEG
(18,818 Byte) http://i.ibb.co/KzCpVTp/20230416_002.jpg
通常
(19,078 Byte) http://i.ibb.co/1vmJZ3x/20230416_003.jpg AVIFって要らないとおもんだけど…。
素直にJPEGで良い。
変なファイル形式は増やすのを止めて欲しい。
ゴミ規格を作りたいクソ会社、クソ団体は潰れろ。 HDR画像がいいからAVIFかできればJXLがいい 90KB
ttp://light.dotup.org/uploda/light.dotup.org50744.webp
298KB
ttp://i.ibb.co/h1C0fdL/20230504_001.jpg
上のwebpをjpgに変換したのが下なんだけど
これってやっぱ追加で劣化してんのかな? それともしてない?
容量が3倍になっちゃうのもさすがにどうなんだって気がするんだけど
もっと容量を抑えつつ劣化無しでwebpをjpg変換する方法ってないんかな? グーグルも開発に関わったjpeg xlがadobeのソフトに対応したのにChromeでのサポートは打ち切りって歪すぎないか 政治的な目的(対抗となるAV1の推進)があるんじゃないかと言われてる
Googleが挙げてる理由は正直納得いかないけど真意が出てくることはないだろうね Googleのせいで無駄なトラフィックが増えている GoogleがJPEGを10bitに拡張したUltra HDRをAndriod14でサポート予定 >>271
Ultra HDR は従来の JPEG に追加情報を付かする形で画像を生成するので、
JPEG との下位互換性を持っています。
つまり、Android 14 では Ultra HDR 写真として、
非サポートデバイスでは通常の JPEG 写真として利用できるということです。
非対応環境で使うときにいちいち変換しないで済むのはありがたいことだが
高速・高圧縮にならないんじゃ、あんまり面白みは感じないかな また、Googleが先日開催したGoogle I/O 2023では、Androidの新たな画像フォーマットとしてUltra HDRが発表された。
Ultra HDRで撮影された写真は、JPEGフォーマットと互換性があり、アプリケーション側がUltra HDRを正しく識別しない場合でも、JPEGファイルとして取扱できる。
Qualcomm TechnologiesのカメラISPチームは、Androidチームと協力してSnapdragonの18ビットISPをUltra HDRフォーマットで活用する取り組みを続けてきた。
https://k-tai.watch.impress.co.jp/docs/news/1501991.html QualcommはSONYやSAMSUNGともジョイントラボを立ち上げてて
SONYとはセンサーとSoCの処理分担を最適化させて4露光を合成するHDR撮影するQDOL4を実装してたし
QDOL4を活かすのにUltra HDRを推すんだろうな 何が変わるって
JPEGの色域とダイナミックレンジが拡張される
アドビの特許を使っててゲインマップをメタデータとして追加したJPEGがUltra HDR
今わかってるのはHDR対応ディスプレイ、SoC、Android14のスマホならHDRで表示されるし
どれかが非対応なスマホだと従来通りJPEGで表示されるってだけ
とりあえずGoogle製アプリは対応するみたいだがサードアプリはまだ知らん 色域増えようが人間の目には大して差異を感じられずファイルサイズ大きくなるだけじゃね? 非対応で従来表示時にきちんとネイティブSDRと同じように表示されるんかな?
HDRのjpegxlやavifみたいに浅い色表示される? >>279
あくまでもJPEGのメタデータフォーマットのひとつに過ぎず、下記3のパスに入らない限りメタデータは使われない(そのまんまのJPEGがデコードされる)
1) 従来のJPEGデコーダー
JPEGそのまま
2) Ultra HDRデコーダー(非HDR環境):
JPEGそのまま
3) Ultra HDRデコーダー(HDR環境):
JPEGに対してゲイン補正をかけてHDR画像を生成(ゲインマップをメタデータ領域から読み出す) ここにきてjpegを拡張させてくるとはね。
もう全部jpegでいいんじゃないか?w jpeg拡張って画像ファイルサイズを小さくしてトラフィックを軽減するのとは真逆の事やってるだけじゃん googleはjpegを生かしたいのかkrしたいのかどっちなんだよ?
hdrならwebp AVIfでいいnだから
jpeg拡張させんじゃなくwebpAVIfをアンドロイドで扱いやすくすべきじゃん このjpeg拡張でwebpがいらない子になってまうんやない?
jpegとAVIFだけあればいいじゃん AVIFは何に使う気なん?
新しいフォーマットなんかいらんって宣言に見えるけど avifはサーバー代払ってる奴は使うでしょ あるいはストレージ代と言ってもいい
サーバー代払う身分にない奴はjpegでいいな
webpはもういらんな
jxlは遅すぎた。死産だよ jxlはあと三年、開発がはやかったら違うポジションにいたかもね
なんかダラダラ開発やってたよな 0.8.1でやる気無くなってるな。
実写と3DCGはjpgか品質上げ上げavifしかない
XLには期待してるんだけど
avifで全部統一になるかもにゃー 動画に比べりゃ画像の容量なんてたかが知れてるからね
新フォーマットを開発するインセンティブが全然違うんだろう
これからも画像のフォーマットは動画のおこぼれを使うことになるんでしょう
なんかツマランわ 今開発しているh266も画像フォーマットがでてきたりするんすかねhiefみたいに 結局技術者がオナニーで規格つくっても意味ないんよね それを使ってくれるお客さんを調達してこなきゃさ
インスタグラムとか巻き込んで、
投稿された画像はすべてjxlで圧縮します!
とか宣言してくれりゃクロームも対応せざるを得ないんだろう
インスタグラムにも利益があると思うんだけどなー
やってくれませんかね なんでインスタグラムで採用されたらクロームも採用しないといけないのかと
規格の採用なんてそんな単純じゃねーから jxlはロスレス圧縮では他のフォーマットより優位性があるnじゃないの?
WEBでの出番がなかったとしても最後まで完成させてほしいけどね
ただ開発陣にモチベーションが残ってるんですかね?かつてあった幻のフォーマットとかになりそう マジでロスレス圧縮しか優位性ないわけ?
ロスレス圧縮の需要なんてどれほどあるんだよ?webで使えなきゃ意味ねーよ JXLは文字の入った画像のロス圧縮がファイルサイズに対して他フォーマットよりコスパよく綺麗に仕上がるってのが個人的に評価したところだったんだけどなあ
うーん惜しい Chrome(Google)「JEPG XLなんて誰も欲しがってない!AVIFだけでいい!AVIFサイコー!」
Safari(Apple)「JPEG XLサポートします」 Safari 17からサポートってことは、つまり何月から?
9月でいいのか? HEICのサポートと同時に来るのか
どういう位置づけなんだ?
https://developer.apple.com/documentation/safari-release-notes/safari-17-release-notes
> Images
> New Features
> Added support for HEIC/HEIF images. (99517108)
> Added support for JPEG XL. (100641584) JXLいじめ気持ち悪いな
何やってるのか知らんけどappleが一抜けかw iPhone勢のSafariアプリでも標準設定で見れるようになるんかね?だとしたら一気にwebでも採用価値があがっていくね 9月からwebでjxl見れんの?
jxl開発陣はそれまでになんらかのリリース出してほしいね
0.8.1から音沙汰ないし Safari公式blog見ると、JXLが主で、自分とこのHEICの方がおまけ扱いだな JXLのカラープロファイルとアニメーションは未サポートか
libjxl使わずにApple独自実装だったりする? >>313
ベータ版試した人が対応してないっぽいと書いていたので Safariのメディア再生はわざわさエンジン切ってOS側で実装してる
webkitの開発者の一部にも問題視されてる
avif追加するときもアニメーションは後から対応してたから
今回も機能追加するつもりだといいね おれはjxl用のQLプラグインを自作して使ってるが不要になるのか MacもiOSも、画像のエンコード/デコードをOSまかせ(Core Media framework)にしてるアプリは
全部JXL対応になるようだ AACやKHTMLのように取り込めると踏んだか
恐らくAppleからエンジニアも送り込まれるだろうし一気に進展しそうだな
しかし結局GoogleとMSは傍観と妨害しただけか
MozillaもAV1陣営に忖度した対応だったし情けねぇったらありゃしねぇ AV1に対抗できる規格で主導権を握りたいとか
Heicと比較して優秀だったから乗り換えを図りたいとか
いろいろ考えられることはあるけど
実際は途中まで実装してたのをポイするのはもったいないとかだったりしそう Mozillaがjxlに塩なのは何でなん?
こういう時こそのMozillaだろうに
なんにせよjxlは首の皮つながったんだから気合入れて開発しろーい! >>322
リンクするC++のライブラリ増やしたら脆弱性も一緒に増えるから
対応してほしけりゃRustでライブラリ書いてこいやって話 Mozillaの理念は「利益ではなくユーザーのためのインターネット」だし頑張ってほしいな
今の運営資金のほとんどがGoogleをデフォルト検索エンジンにした見返りの金だとしてもまったく関係ないもんね 今のMozillaはChromeではこれができるのにFirefoxではできないって案件じゃないと積極的にならない傾向がある Appleが写真のデフォルトをHeicからjxlに変えるとかってあり得るかな?
jxlとHeicってあんま比較されないyよね rav1eというav1のエンコーダ開発してる人の一人がmozillaが何年か前に行った
大規模レイオフのせいで開発者がいなくなってしまったとredditで嘆いていたこともあったし
人的リソースが足りてないのかもしれない 自社の版権フォーマットのheicは手放さない
heicでAppleにライセンス収入があるだろうし
Appleはheicのライバルフォーマットのavifへの当てつけにjxlを推してるんだと思う jxlより先にavifに対応してるのに何を言ってるんだ ここの人たちってやけにavifに憎悪してjxlに敬愛してるよね
AOMediaに親をやられたんか? >>330
高解像度になると突然激遅になるからこんなもんが何にでも通用する万能規格みたいな扱いになられると困るってだけ
ウェブ向けの低解像度特化規格なら別に文句はないのにGoogleを始めなんか扱いがおかしなことになってんなって HEICはカメラ画像を無変換でアプリ内のWKWebViewに表示できて、ハードウェアデコードできるから速いよ
って言ってるだけだけなので、Apple的にはHEICよりJXLを勧めてるようだ
https://developer.apple.com/videos/play/wwdc2023/10122/
カメラは連写を考えるとHEICから変わらんだろうと予測してる人もいた
JXLがハードウェアエンコーディングできるようになったら変わるかも jxlがハードウェアエンコードできるようになるにはどれくらいかかりそうですかねw heic使うとAppleが儲かるんです?聞いたことない heic画像を出力するプログラムを商用で扱うと特許使用料を求められる
heic画像を入力するだけなら商用でもlibde265ライブラリのLGPLライセンスの範疇におさまる 出力するのに特許使用料かかるんじゃこんな規格流行るわけねえわ
スマホで連射なんてしねえしjxlデフォルトにしてくれApple! heicはライセンス料が必要なこと以上に
ライセンス団体が分裂して、どこにどうやってどれだけ金払えば良いのかまじで分からんから
特許持ってる会社がクロスライセンスとしてタダで使うくらいしかできないのが問題 逆に言えばhiecが権利関係でぐしゃぐしゃになってくれたおかげ新規格はオープンにやろう!という気風がうまれた部分もある
そういう意味でHeicは必要性があった。
新規格の前座として
AVIFなんて、ほとんどHeicの反省だろう 動画ベースのほうが余計なエンコーダ/デコーダを実装せんでいいから都合がいい
ハードウェアアクセラレーションも期待できるし 静止画にハードウェアアクセラレーション効くのだろうか? ビットストリーム自体はIフレームと同じなので普通に効く
可逆以外は 2023年06月13日
次世代の画像ファイル形式「JPEG XL」は
AVIF形式よりもファイルサイズが11%小さく画質は13%高いことが報告される
https://gigazine.net/news/20230613-jxl-against-avif/
avifは得意不得意がハッキリあって使いにくいにゃー
jxlの方がjpgっぽく使えてイイ jxlが優れてるのはわかるけど、現状ver1.0に到達してないっていうデメリットがね…
ver1出るまで待機中 自分の思うようにいかないからって○○を採用しない☓☓はクソ理論でいじめだなんだど文句を言ってるの子供のまま大人になったみたいで気持ち悪いな
そんなにJPEG XLを普及させたいなら自分らでハードウェアなりソフトウェアを作ってやりゃいいだけの話なのに
そんなにグーグルに採用してほしいなら社員になって企画して実装でもすれば? 自己環境ではローカルな画像保存はjxlに移行してる 結局モジラの開発力が低いからwebの規格を決めれるのがSafariとchromeの匙加減次第になってるのよね
も少しプレイヤーがいないと競争がうまれねえよな?
GAFAのどっかっかブラウザに参入しねえかな? AVIFへの変換でRTX 40XXのAV1ハードウェアエンコードを使うようにできる画像変換ソフトってありますか? >>355
ありがとう
pngからavifに変換したいんだけど
ffmpeg -i "入力ファイル.png" -vcodec av1_nvenc "出力ファイル.avif"
とやってみたら、
[av1_nvenc @ 00000256b2f60f80] YUV444P not supported
[av1_nvenc @ 00000256b2f60f80] No capable devices found
[vost#0:0/av1_nvenc @ 00000256b3010bc0] Error while opening encoder - maybe incorrect parameters such as bit_rate, rate, width or height.
Conversion failed!
ってエラー出て失敗してしまう。何故だろう
普通の動画の変換(h264→av1)ならffmpeg・av1_nvencで問題なくできている
rigaya氏のNVEncCも試してみたけど、こちらはpng→avifの変換を問題なくできた FirefoxのJPEG XL実装に再び進展がある、…かもしれない
https://connect.mozilla.org/t5/ideas/support-jpeg-xl/idi-p/18433/page/9#comments
機械翻訳
> 06-12-2023 02:54 PM
>
SafariがJPEG XLをサポートするというAppleの発表以降の最近の活動も含め、ここでアイデアやフィードバックをいただいた皆さん、ありがとうございます。私たちは、この件についてもう一度検討する予定ですので、何か変化があれば、このスレッドを更新する予定です。 モジラxlやるんかね?
それとも建前的なポーズ?奥歯につまったような物言いだな そもそもlibavifだって1.0になってないしバージョン番号なんて関係ないわ >>361
libavifはlibaom、rav1e、dav1dとかのラッパーだからバージョンの段階は関係ない
Chromeはav1(avif)のデコードをffmpegでやってるからlibavifは関係ないし av1はエンコーダー、デコーダーの種類が豊富でいいなあ
一方、jxlは寂しいなあ… avifは
マンガならq30〜35で画質余裕、めっちゃ容量下がる
2DCGはq25〜30
実写、3DCGだとq10くらいにしないと
ノッペリで潰れちゃう、容量も全然下がらない
webpの方がイイ仕事する
こういうのが面倒くさい
jxlのq80〜90でまとめて一気にやれたらなぁ〜って思っちゃう 今の時代、ユーザーが品質だのコーデックだの可逆だのを選択すること自体に時代遅れ感がある
画像を渡したらAIが自動で最適な圧縮条件を割り出してくれるぐらいやるべき 攻守走どれにも最適でじゃんけんで言うなら グーチョキパーなjxlに育ってほしい >>365
それはラッパーの約割だろ…
libjxlみたいなシステムな画像ライブラリは指定したパラメータに対して「正確にバグ無く」画像をエンコード、デコードするのが仕事 JXLのエンコードは--effortで計算量を調整できるから、圧縮後のサイズの減量は時間とのトレードみたいなところもあるよね
--distanceや--qualityのが重要だけど C#でも簡単に使えたら良いのにな
なんで開発者ってラッパー用意してくれないんだろ >>370
C#ならFFmpegからやればいいんじゃない? JavaのラップはExampleでよくあるのにC#のラップは全くないよね
需要がないからなのかな C#でのJXLサポートには、Magick.NETがよく使われてる印象 Javaが多いのはサーバー用途の想定なのかな
最近はGolangとかKotlinに置き換わってるんだろうけど Wasmで個々のサイト内でJXL対応してるところとかあるしChromeに頼る必要は無い pixivとかって今だにjpeg pngなのかな? むしろその手のアマチュア投稿サイトでその二つ以外を対応する必要性あるのか?
仮にAVIFなりJXLなり対応したところで可逆と非可逆で普及率トップのPNG/JPEGの二強なのは変わらんと思うが サイトが対応したところでユーザーが対応してなきゃ意味ないんよ
確かtwitterもwebp対応したけど
どれほどの人がwebpで投稿すんだよって話 >>380
その言い分だとサーバー側が勝手に画像形式を変換してデータ保存すりゃいいだけ
Twitterだって投稿された画像をサーバー側でGuetzliなりで再エンコードしてるし 結局新規格ってユーザーにわ関係ないよね
現状で困ってないわけだし
サーバーサイドのテーゼだわな
mastodonはAVIF対応したんだっけ? まあユーザーは極論、画像は無圧縮で管理してストレージ容量が足りなくなってきたらハードディスクを買い足せばいいだけだもん 今はもうSSD/SDが主流の時代だし、
常識的な数のSSD/SDに画像を収めるためにも次世代画像圧縮はあった方がいい >>386
Safariに続いてFirefoxでのサポートが実現すれば、「自社製品(Google Chrome/Chromium)への導入を促すに足る市場圧力」が形成されると見込んでいるのだろう 雨降って地固まるだな
chromeに一回切られたおかげで逆に注目集まったんじゃね?
なんにせよ完成させてくれ 一応こういうのもあるんだけどね、jxlエクステンション
https://github.com/zamfofex/jxl-crx
静止画のハードウェアアクセラレーション、こんなのがあるんだね、採用例は知らないけど…
https://developer.nvidia.com/nvjpeg
Library 70Kib 720x1080 1.6Mib 3200x1800
NVJPG 2.036ms 15.997ms
libjpeg-turbo 6.127ms 66.341ms >>389
jpeg2000もあるのか…
その内nvjxlも出してみてほしいねえ stablediffusion webpかAVIFで吐けるようならんかな
二度手間なんよ stablediffusionってオープンソースじゃないの?自分でやれよ >>392
pngで出てくるからロスレスwebpで吐いてほしいわ >>392
>>394
PILがデフォルトでWebP対応してるから「image.save("output.webp", lossless=True)」みたいに拡張子とオプション指定するだけだし超簡単だろ
どっかのウェブサービス使ってるだけなら要望出せよ >>395
PIL?stablediffusionの話じゃないの? jxlやAVIFの次の規格って構想とかあるんすかね? jxlはもうchromeの開発者に手伝ってもらって完成させて、どうぞ google側にjxlを普及する利権的メリットがもはや無いのかね
最初からavifの普及に失敗したときの保険的立ち位置だったからしょうがないけど h266とAV2かな?
jxl2とかって構想ないのかな? 何かのプレゼンで次の30年(JPEGが30年だから)を担うとかなんとか言ってたから
当分ないんじゃね JPEG XLはみんなご存知の高速と名高いrANSを画像符号化に使いましたよっていうフォーマットで、理論的には完成してるのよねえ
あとは実装を突き詰めていくしかない XLの性能向上のキモは動画コーデックのような近隣ピクセルの予測符号化が入ったことじゃないかな
エントロピー符号化自体はLZ77+ハフマンでもできるようになってる ストレージの性能が上がり続けるから
次の次の規格なんて必要か?jxlで打ち止めだろう >>394
ロスレスwebpってpngの上位互換イマイチ流行んないっすね
png全部置き換えてもいいとおもーけどね 16 bppに対応してないし最大解像度もPNGより低いし全部置き換えなんて最初から無理な仕様なのだが 性能でwebp勧めるくらいならavifの方がって感じだしもう後継はavifかjxlの二択じゃないの >>408
ロスレスAVIFは圧縮ゴミでロスレスjxlはエンコが遅え
ロスレスwebpはバランスがいいんだ!
問題はロスレス圧縮需要がいうほどないってことなんだ! ファイル形式というか拡張子でロスレスかわからないのイヤッ
ロスレスの時はjxllみたいな拡張子にするとかの仕様になればいいのに >>411
別にバランス良く無いよ
8bitのロスレス画像って >>412
分かる
でもjxlは可逆も透過もアニメーションも対応してるからバリエーション作るの大変そう >>413
推せるでしょうね
なんてったってwebpはwebで使えますからね♪ >>413
推せるよ。だってあの表、現時点では嘘だし
可逆jxlのエンコード・デコードは糞遅い
特にデコードが遅いってのは連続して画像を見るときかなりのストレスになる jxlは今度のSafariの対応で何か変わるんかなあ avifってプラグインいれんとWordPressに投げれないんすね
こういうとこ対応してくれんと普及しねえよなああ >>420
webpはappleが対応してから割とすぐデフォルトで使えるようになったし
avifはedge待ちかな、wordpressに限った話じゃないかもだけど エンコード速度じゃなくてデコード速度を比較してほしいよね
>>423 世の中のサイトはほとんどwordpressで管理されてっからwpがバニラで対応しるかどうかって重要よね
AVIFもjxlもどうなることやら、、、
wpはwebpしてんのねん ぶっちゃけAVIFもjxlもただの画像ファイルだろ?wordpressが対応するのってそんな大変なんすかね?
メディアファイルにうpしてimg srcに指定すりゃ映るんじゃねえの? 画像形式なんも分からん人向けだから
ほとんどの環境で対応してるメディア形式じゃないものをデフォルトで許可すると混乱が起きる
フォーラムに「一部の顧客にAVIF画像が表示されない」とか書き込まれまくるのは嫌 jxlもどうせプラグイン作られるでぢょうしバニラで対応する必要あるかっていうと、まぁ無いでしょうね jxlはlibjxlのデコーダーにまだバグが残ってるから実装しないのが正解 結局wpもブラウザの対応待ちよ
WEBの規格はブラウザ様のお気持ち次第なんよ
そしてブラウザ開発してんのGoogleAppleなもんでここのお気持ち次第 2年ほど前から開発・公開されていたjxlのWICである「jxl-winthumb」が先日、jxlデコーダーをRust実装の「jxl-oxide」に移行して**完全なRust化のマイルストーンを達成**した模様
下記リンク先のリリースページからDLLをダウンロードして下記コマンドを実行すれば、インストールが完了する(アンインストールは -u オプションを付与して実行)
regsvr32 jxl_winthumb.dll
GitHub - saschanaz/jxl-winthumb: A JPEG XL (*.jxl) thumbnail handler for Windows File Explorer.
https://github.com/saschanaz/jxl-winthumb
GitHub - tirr-c/jxl-oxide: Pure Rust implementation of JPEG XL decoder
https://github.com/tirr-c/jxl-oxide Mozillaさんにもブラウザ界を牽引してほしいけど...
あんまプレイヤーとみなされてないよね
モブになりつつある 6割Chrome、2割Safariで残りはその他って感じだっけ 昔はfarefoxOSなんて作ってイキってた時代もあったが
今は随分小さくまとまっちまった
ぶっちゃけアンチgoogleとかでも無いとあえて使う理由もなくね? avifのがjxlよりデコード速度が早いのにavifを使わない理由がない >>4を見るとAVIFは8193x4320までしか対応してないように見えるけど普通にそれ以上のサイズも作れるね
実際に作った画像のURLを貼りたいけどNG食らった heicやavifなど動画ベースのコーデックって動画の基本ハードウェア回路とセットで
撮影最大解像度がハードウェアに依存しちゃうわけよ
それだとより大きな画像つくれなくなっちゃうから、グリッド機能で小さい画像を
複数並べることによってハードウェアを利用しながら
ハードウェアの最大解像度より大きな画像をつくれるようになってる 例えば、8Kの画像つくるときに1枚の大きな8K画像としてエンコードしてもいいが
それだとデコード時に8Kに対応したハードウェア回路持ってないと
ソフトウェア(CPU)デコードになっちゃう
でも、4枚の4K画像のグリッドとして8K画像作れば
8Kに対応したハードウェア回路持ってなくても4Kに対応してれば
ハードウェアデコードできるようになる 動画由来のフォーマットはハードウェア支援が得られるのが強みよね〜
今はソフトエンコからハードへの過渡期なのかもしれんね ブラウザとビューワでHWデコード採用することはあるのかな
chromeもlibavifだけでやってるように見えるからSWデコードだけっぽいけど >>437
JPEG XLまあまあ早い方だったのか 元々>>4のようにコーデックの中で最速クラスみたいな宣伝してたけど別にそんなことはないというだけの話 MicrosoftはまだJPEG XRを諦めてなかったのか……
https://forest.watch.impress.co.jp/docs/news/1521455.html
> JXRファイルをデスクトップの壁紙として指定し、HDR表示することができる。 >>445
nightlyがちゃっかり旗持ってるのウケる Chromiumで「クローズされたjxlのissueの再オープン」を求めるissueに事務的な応答があって大盛りあがり
https://news.ycombinator.com/item?id=37034912 >>451
画像によってはavifに勝ってるし結構いい方だと思うけど いうほどavif使われてないよな
何故かXに改名したTwitterはwebpになってるし そのサイト、異様にエンコード時間かかる設定で比較されてもな・・・あとエンコード/デコード時間も書いてほしい
つーか、1秒以内に終わる設定で比較してよ^^b AVIF派はボケボケな画像の方が高くなるような指標を使うよね >>450
これって実際どれくらい本気度あるんすかね?
イシューを再オープンしたがいつ実装するとは言ってない、その気になればウン十年後も可能
みたいな >>458
再オープンしてほしいっていう要望を出してるだけでまだ何も変わってない
「問題が発生している環境のOSを教えてください。ありがとう!」
「担当の者に連絡します。ありがとう!」
って言われただけ
何でニュースっぽくなってるのかも不思議なレベル >>458
HNで騒いでるひと
ぬか喜びにならんきゃいいけど、、、 最近のChromeがWeb Environment Integrityでめっちゃ反感かって
一緒にjxlも話題にされがちだから変に盛り上がってるかもしれない
https://news.ycombinator.com/item?id=36982507 chromeがやりたい放題しすぎなんよね
ただそれを止められる勢力があるかってったら、ないのよね〜
Googleの為にWEBがある訳じゃないけどwebに金配ってんのはGoogle様よ デコード速度、圧縮率、劣化具合
結局どの画像がいいんだ? デコード速度なら断トツでjpeg,pngだからそれ以外使ってない
ストレージは有り余るほどあるから Googleが作ったエンコードサービスではjxl使えるんだな。不安定なwebp2もw
社内政治ごっこのとばっちりで使えないのか? squooshの事なら現行のv2になったのが2020年なんで多分その頃まま更新されてないだけかと
squooshのgitみるとlibavifのバージョンは一応アップデートされてるようだけど
jxlも含めて他のコーデックは2年ぐらい前のバージョンで止まってるし squoosh直感的に使えて好きなんだけど、玄人はffmpeg使うし素人はわざわ圧縮しねええし
誰の為のサービス?とはなってるよね。最新のものに更新してほしーけど、付きっきりで管理してるひといんのか? squooshで自分の目で比較するくらいしかないんじゃね
webp2は正式に使えるようにはならないからみんなやる気ない
https://chromium.googlesource.com/codecs/libwebp2/
>WebP 2は、WebPをベースにした実験的な画像コーデックです。WebP 2は画像フォーマットとしてはリリースされませんが、画像圧縮実験のための遊び場として使用されます。 Safariがjxl対応したら最新のもの更新してほしいっすねsquoosh AVIFとかjxlとかデコード負荷高いのって論外でしょ jxlはJPGよりほんの少しだけ重いだけなので、webp、avifと間違えないように。 >>474
何も知らないなら何も言わないほうが良いぞ
馬鹿がバレるから MSのフォト アプリが刷新してwebpにようやく対応したわ
以前のフォトとデータベースの互換性がないようで
最初に古いものを削除するかどうか聞かれる Jpegとか92年に出てきた形式を未だにぶっ潰せないって
殆どの人間にとって画像のファイルサイズとかどうでもいいんだろうな jpegが初期の規格にしては完成度が高すぎた部分もあるmozjpegでまだまだ延命できる
アンドロイドならhdrにもなる
Googleちゃんjpegやめへんで〜 pngも96年だから相当、息の長い規格だわな
こちらもロスレスwebpとかに代替されるかといえばそんな雰囲気もない
動画は規格の入れ替わりが結構あるんすけどね jpegは未完機能不足感あるけど
pngは完成している感ある
実際足りない点ほぼ無いでしょ? 動画はまだまだ圧縮したいだろうし先は長そうよね
音声フォーマットは少ないようで地味に色々あって鬱陶しい pngって非可逆圧縮できた?
できなきゃ、png1本とはいかずそれできるフォーマットも必要やな 正確には色数を256色にするとか非可逆圧縮にはなる(定義には当てはまらないかもしれんが)
jxlは非可逆と可逆どちらもできて可逆はさらにvisually near-losslessができるっぽい。
でもこの複雑さがChromeの連中に嫌われてる原因なのかな・・・ 同一形式で可逆と非可逆両対応できるのは好かん
逆に非可逆で劣化しているpngやflacがいつの間にか混じってたりしたらめっちゃ嫌 世の中にはlossy pngなるものがあるんじゃよ
ただマイナーなだけなんじゃ mozjpegはwebpとあんま変わらないって記事読んで実験したけど
webpの方が全然性能良かったぞ
pngはTinyやOptiにしても流石にデカ過ぎるんじゃね?
(Tinyも非可逆だっけ?)
最近、AVIFもJPEG XLも結局流行んないんじゃないかな?って思う
WEBPをちょっとパワーアップさせるくらいが丁度いい気がする
(4:4:4対応させてJPGの20〜30%減くらいで良し)
エンコも普通のWEBPの2〜3倍程度、デコードはWindowsもちゃんと協力する
遅いなら専用チップ埋め込んでもらう
とにかく使い勝手が悪いといつまでもJPGのままやで HDR対応のための新規格なのに4:4:4は草しか生えない webpちょっとパワーアップさせたのがavifじゃないの ちょっとのパワーアップであの重さはコスパが釣り合ってない… 一般人には4Kも8Kも要らん、HDRも要らん
JPGで満足しきっちゃってる
AVIFもJPEG XLもマニア向けで終わって
人に渡すときはJPGに変換して渡す
そういう未来なんよ macOS/iOSはJPEG2000だってサポートしてるし別に特別なことは何もないだろう 規格が使われるかどうかはユーザー次第だが果たして、、、 新Safariはいつでてくるんすかね?ドキドキしてきた オラは「Edge 116でついにavifサポート!」って話が幻に終わってガッカリ
https://caniuse.com/avif
カナリア版に起動オプションつけると表示できるようになるのが唯一の根拠だから無理があるとは思ったけど
MSからは何にもアナウンスないしどうするつもりなんだろ >>494
JPEG 2000はPDFをOSレベルでサポートする為だろう Appleが自分とこのコンテンツjxlにしたりしますかね?
ないか、
客はSafariユーザだけじゃねーし >>500
黎明期or過渡期においては、バリエーションが増えるだけで置き換わるわけではないよ(jxl非対応クライアントでは従来のフォーマットにフォールバック) 撮った写真をHEICに置き換えるくらいの強引さで移行を施すんじゃね?
HEICは使い勝手悪すぎてJPEGに変換してるやつ多いけど なんか JPEG を無理やり HDR に対応させたようなフォーマットが出てくるんだっけ
キメラ感とか力技感がすごいから素直に jxl が席巻してくれたらいいのに >>504
JPEG-HDRとはまた別の形式か?どれのことか知りたい >>504
これ >>274 (Ultra HDR)のことなら、つい最近下記記事が出てた
Googleフォトに画期的アップデートか、いよいよUltra HDRをサポート | Forbes JAPAN 公式サイト(フォーブス ジャパン)
https://forbesjapan.com/articles/detail/65705 それの最大の問題は速度どうなってんの?
JPEGの軽さが変わらずHDRに対応ってならすごいけど
エンコードの速度どうなってるんやろうな jpegと互換性があるっていうのが最大の理由だろうな
ワンチャンiPhoneでHDR画像が普通になる可能性もある? >>511
iPhoneでHDR画像が普通なのは何年も前から常識なんだが
HEIC形式で 「既存フォーマットとの完全互換性」を持つフォーマットは導入の障壁が低い
Ultra HDR については、パネル側の表現力が低いケースでも破綻のない表示(従来のjpegそのまま)が保証されている点が強み libwebpのバグって結構大事になってるな
まあこのスレにはブラウザを古いまま使うようなやつはいないとは思うが iOS 17 Safariでjpegxl.infoのJPEG XL試してみた
静止画は表示できる
アニメーションは動かない、けど保存後に写真アプリで詳細を見ると動く、けどちょっと表示が変かも
カメラロールに保存したJPEG XLを非対応アプリで見るとJPEGに見えたり落ちたりするみたい あと、写真アプリで詳細を見たとき、普通は「カメラ情報がありません」の右端に
JPEG/HEIF/PNGのどれかを示す囲み文字が出てくるんだけど、JPEG XLだと何も出てこない
webpも同様に何も出てこない iPhone15、HEIFを捨ててJPEG XLで写真撮れればいいのに
モバイルで動かすには負荷が大きいと判断したのだろうか
そういえばFirefoxのAVIFアニメーション、何故かループ再生されない そういうとこだぞモジラ もともとiphoneの連写は強制でJPEGじゃなかったっけ webpバグまであんのかよ・・・jxlでいいだろもう >>520
不具合があることと、不具合が発覚することは別の概念 今度はlibvpxのVP8の脆弱性が修正されていたな
webpの元がVP8だから、さもありなんって感じだけど MSのwebpのWICの更新が今日来たけど
まさか脆弱性の修正が今頃? >>523
WebPのゼロデイ脆弱性は「Teams」や「Skype」にも 〜Microsoftが影響製品を公表
https://forest.watch.impress.co.jp/docs/news/1536304.html
昨日の更新で修正されたようだ なんでGoogleはAdobeが特許持ってるゲインマップHDRなんかに乗っかっちまったんだ >>527
1.0マイルストーンへの進捗が数か月の間71%で止まったままなんだよね
誰か理由知ってる? >>526
アドビのフェローを名乗ってる怪しいやつがアドビの主要アプリでも対応する予定だって書いてる >>529
調べてみたけど名前と肩書の関係は本物みたい(adobeのサイトに載ってる)
githubアカウント名も件のフェローがよそのサイトでよく使ってるもの
ただ、githubアカウントに殆ど使用歴がない理由は分からん >>526
JPEG-XLの半分を開発した有名な研究者がこんな感じのこと書いてるね
この人、Google所属なんだから社内のChromeチームと調整してくれよ
> 高品質なRustデコーダの実装が、JPEG XLをinterop 2024に選択する唯一の決め手となるのであれば、Google ResearchのJPEG XL開発チームは、2024年第2四半期末までにそれを提供することができます。 Chromeチームから調査を依頼された?AVIFチームが「jxlは実装する価値ない」って結論出してるから調整以前の状況な気がする 利害関係者が調査するとか面白い企業だな、公平とか金にならんし正しい態度だ 利害関係者が調査するとか面白い企業だな、公平とか金にならんし正しい態度だ ブラウザがネイティブ対応してくれんと如何ともしがたい。中華のアドオン対応は怖すぎるw Androidより先にiOSが対応するとは思わんかった HEIC画像ってPNGに変換するとファイルサイズが10倍になるんだけどこういうもんなの?
そんなにHEICの圧縮率ってすごいのか? 結局ブラウザやビューア対応もwebpがなんとか残ってるだけで
avifもxlも自然消滅か Interop 2024が来年1月に決定通知と一般公開
なのでそれまで待ちかな webpだってGoogleが自社のプラットフォームでゴリ押ししてる
だけだからな。そうでもなければjpegで十分 avifってEdgeで暫定対応だったのに118かそこらで
なぜか大元のav1ごとダメにされちゃったんだよね
他のブラウザは勿論そのままだから脆弱性とかは
関係ないだろうし、なんか大人の事情が絡んでそう AdobeのブログのHDR解説がカーソルを合わせるとHDRで見れるよとか書いてるのに一向にHDRで見れなくて
https://blog.adobe.com/jp/publish/2023/10/26/cc-photo-hdr-explained
散々色々試した結果、なんのことはない、翻訳元の英語記事だとちゃんとマウスオーバーでHDRになる
https://blog.adobe.com/en/publish/2023/10/10/hdr-explained
本来この記事特有のマークアップしないとダメなのに翻訳の過程で雑にブログシステムに画像放り込んでHDRもマウスオーバーの仕掛けもオミットしてた(のにマウスオーバーでHDRって説明はそのまま)というオチだった
Adobeジャパンさあ… Google pixelでUltra HDR試した人いる? >>545
最近こういう技術解説のほとんどが機械翻訳だからなあ
MSのドキュメントでもコードの中まで翻訳しちゃってることがあった
まあ開発系は英語で読むのが普通だけど adobeのなんかの記事にHDRとSDRの両方の画像を1ファイルに同梱する方式も考えてるよ的なこと書いてあって嬉しい
HDRを自動でSDRにマッピング表示するより絶対そっちの方が良い
Jxlとかでビューアーも読み取ってHDR内包しているときにSDR表示してたら
HDRありますよ的なアイコンを表示するとかの運用できたら最高 ChromeにJXLのサポートを切られてそろそろ1年かな
切られてなくてもいまだに実験的サポートだったと思う
開発が遅すぎる JPG品質85と同等画質を目指す場合は同じくJXL品質85でいいのか低容量でも潰れにくそうだからもっと下でもいいのか XL普及させたいんなら
何でjpegやwebpをXLに変換出来るアプリを
AndroidやiPhoneで公式で出さないんだろう
オンラインでXLに変換出来るサイトもあるみたいだが
画像を送信するとか気持ち悪いし そもそもJpegの品質って統一されてるの?
前実験した時は同じ品質(91くらい)でソフトによって全然SSIM違ったんだが
lightroomに至っては
80-88,89-91,92-96(数字はテキトー)まですべて同じファイルサイズとかになったし >>553
jpgエンコーダーと画質評価指標と元画像によって色々だが
jxl(q85)はjpg(q85)より画質良いので同等ならq80からq75程度まで下げられる
jpg(q85)と同等画質のjxlを雑に作りたいなら
jpg(q85)のbutteraugliスコアをcjxlの-dオプションで指定すればおk
mozjpegデフォルトのq85なら2から3前後になると思う
>>557
jpgに限らず異なるソフト間では統一されていない
なんなら同じエンコーダーでも使うオプションによって変わる >>556
一番新しいバージョンのiOS以外対応してないから リファレンス実装が正式リリースしないと色々と話が進まないからなぁ
さすがに今年中には出ると思うけど、その後どうなるかだね インテルCPU12世代や13世代にしたらAVIFってデコード速くなる?
マンガとかAVIFにしたいけど表示速度の引っ掛かりがどうしても気になるんだよ 実際オフラインでjpeg xlに変換出来るAndroidアプリってないの? >>562
HWデコード対応かどうかは使用ソフトによって変わるので
具体的に名前書くか開発元に問い合わせるべし
まぁ現状だと大抵は未対応かと
>>563
Termuxはリファレンス実装の最新版を公式サポートしてる githubにあるifjxlとifavif、ダウンロードリンクが切れてる…やる気がないのか appleの電撃参入で劇的に進展すると思いきや相変わらずで吹いた lightroomでHDR現像出力するとき
chromeでできた画像見るとjpegのHDRとavifで見た目結構変わるな
ゲインマップのjpegのほうがなんかいい感じ(lightroomでの編集中の画面に近い)ように見える SamsungがJPEG XLサポートを発表
RAW現像の出力フォーマットとして それな
appleはsafariで表示できますじゃなくて
カメラアプリでjpegxlで出力できますにしてくれんとな AVIFは主要ブラウザ対応完了か
やはりJXLではなくAVIFなのか 興味が湧いてこのスレを頭から追ってみたけどローカルでpngとjpeg以外を使う気が起きなかった 手持ちの画像をjxlに変換してたんだけど抜けがあるなと思ったらUnicodeのファイル名処理できないのね ローカルならむしろavifやheicみたいな圧縮率高いの使うな
ブラウザの対応とか気にしなくていいわけだし Windows Server 2025向けWindows SDKのWIC関連ヘッダにjxlの型が確認される
将来的な標準サポートに期待増
https://pbs.twimg.com/media/GEymaR2WUAAbZIO?format=png jxlより動画の低負荷高圧縮フォーマット出ないのかよ HDR現像をバンバンしているがjpegかjxlで保存するか悩み中 名前がJPEGなのが悪い
一般人がJPEGって聞いてもガビガビ低画質のイメージしかない >>592
ジジイの主観を一般化するのは無理がある 刻んでいく―www
ロスレスで容量が膨らむとかいろいろあるからまだまだ先か でかい画像使いたかったからstreamingオプションが嬉しい ロードマップ無いのかな
今年中には来てほしいんだけど >>599
マイルストーンのページを見れば分かる
1.0 version
78% complete
24 open
90 closed この進行度って具体的に何表してんの
画像の圧縮率とか展開の負荷を抑えるとか8割近く達成してんの? WindowsのWICのコーデック調べたら
Microsoft公式のJPEGXLデコーダー
がインストールされてた
何かの拡張パックに含まれてるのか avifはwebpより順調じゃね
Edgeも今年対応して主要なブラウザはコンプリートしたし
WordPressの次のバージョンで対応するって発表も先週あったし
webpがアップル製品からボイコットされて最近やっと使えるようになったのと比べたら早すぎる ほんとに終わったっていうのはwebp2みたいなのを言うからな
webpは一つ世代前だし今はjxlとavifの一騎打ちじゃないの 2000は映像業界や医療業界で今でも現役だからwebpavifjxlとは比べもんにならん 2000死滅してなかったのかw
誰も使ってないと思ってた webpはGoogleが主導してるからYouTubeのサムネとかにも使われてるみたいだし
avifやxlのようなゴミと違って利用状況はダンチ Xnconvertってソフトで使ってるんだけどjpgをwebpに変換すると明るい赤が暗くなるんだけど劣化しない方法どうやるんだろ
jpgに変換するときはサブサンプリングファクタを最高品質にすれば色の劣化も防げるだけどな
こんな風に明るい赤が暗くなる
https://i.imgur.com/MWb4G57.jpeg
https://i.imgur.com/n3syst3.jpeg WebPの色化けが対策されたのはかなり後なので
ちゃんと更新されてる変換ツールに替えるしかない
ImageMagickでuse-sharp-yuvを有効にするとか > ImageMagickでuse-sharp-yuvを有効にするとか
XnConvertだとこれじゃない?
https://i.imgur.com/j1QvqVJ.png 俺のバージョンが古いからその項目なかったんやね
新バージョンだと変換した画像を置き換えて削除してしまうんよね
旧バージョンならゴミ箱に送ってくれるのでやめたい時に元に戻せる
なんか使いにくいんよ PDFに画像埋め込むときってwebpとかAVIFとかXLとかって使えないんかね
JPEG2000は使えるみたいだけど
AdobeがPDFの仕様を改訂しないかぎり次世代画像形式は使えないって理解でいいんだろうか >>620
多分そう
あんま使わんけどEPUBとかも新しいの対応してほしいなあ EPUBは去年出た3.3でWebPに正式対応してる EPUBってビューアが大抵ブラウザベースだから規格として対応してなくてもベースとなるブラウザエンジンが対応してたらしれっと表示できそう テストEPUB作って雑に検証してみた
Thorium(Readium) : WebP○ AVIF○
Adobe Digital Editions : WebP○ AVIF○
Kobo : WebP○ AVIF×
Kinoppy : WebP× AVIF×
MuPDF : WebP× AVIF×
Perfect Viewer : WebP○ AVIF△(要画像プラグイン) Android12でavifサポートしたのに個々のアプリで対応必要とか・・・Googleさんあんたにはがっかりだよ iOSもjpeg xlに対応したけどブラウザくらいにしか使われてなかったな
カメラはハードル高いんかな 10年前に落としたエロゲーCG集webpにして軽くしようかな
捨てられないけど邪魔で35Gあるんよね
品質あんまり下げたくないなぁ…80〜90どうしようか 2500×3600の大きい画像だとwebp品質値92でも劣化してるの分かってしまった…
開いたときの縮小サイズだと分からないけど等倍にしたら白い斑点が薄く見えるし消えてる箇所があるやん
https://i.imgur.com/GYG0toH.jpeg
jpeg品質値92のがまだ劣化が少ないような
小さい画像くらいしか使えないな webpて思ったほど縮まないよな
個人利用なら互換性だの気にしなくていいんだからavif heic jxlのどれか使ったら webpとavifは範囲塗り潰しで減色するから絵だと原寸表示しなくても分かるくらい派手に輪郭消えること結構あるんだよなあ webで使うとかじゃなくて個人利用で圧縮したいだけならjxlでいいんじゃない エッジが際立ったり塗りつぶしでベタっとしたりはあるけど
斑点は見たことない
塗りつぶしとは真逆の現象起きてるじゃんなんだそれ webpとかまじ色を破壊するからグレースケール以外は不可 >>636
絵の女の子の太ももなんかは光らせてる箇所が斑点でグラデーション表示されてるんだけど元画像とwebp比較してみると薄くなって消されてる箇所があるのよ
劣化が不安やから高画質の画像で比較した
blob:https://imgur.com/39ada4a2-6425-482b-9bbe-e1fc8fc484cf WebPはYUV420の仕様上高品質だと頭打ちになるので品質85以上で使うもんじゃないよ
あと大判画像も不得手 >>641
そうなんだ?
昔のエロCG集20万点の解像度850×とかだからそれなら問題ないってことか
>>635
jxlは自分の環境ではサムネ表示されないから使いたくないな
コーデック入れたらええのかもしれんが >>631
エロゲはbmpにしたあと7zで圧縮という手があるぞ
似たような画像はbmpのバイナリも似通ってくるから7zで高圧縮できる
書庫を解凍しないと見られないし、解凍した画像が容量を食うしであまりおすすめはできんけどな
やったことはないが動画化してもかなり縮むはず >>643
さすがに解凍しないと見れないのは嫌やな
動画化はちょっと…写真じゃなくなるのは後悔しそう
そこまでするなら動画何個か消すわww cb7対応のコミックビューアならそのまま見られるけどそれならavifでいいわな
jpeg/webpで高品質だとjpegliのq=90あたりが良さげ
https://imgur.com/a/0GC3eSr >>646
jpegliって、JPEG XLのサブプロジェクトで
同じリポジトリのサブディレクトリに入ってるプログラムだぞ jpegliめっちゃ速いな
mozjpeg使う理由がなくなった
俺は今日から乗り換える だいぶ前からあるけどどういうこと?
新しくなったの? jpegliの主要開発者のZoltan Szabadkaを含むGoogle Researchでmucped23やったメンバーが
4/3にGoogle Open Source Blogで記事を書いてそれがメディアで取り上げられただけ
jpegli自体に何か大きな変更があったわけではない jpegliが大型アップデートしたのかと思ったが違うのか
個人的にUltra HDRの動向がどうなるかが気になる いつから公開されてたんだろ
その記事見るまで知らんかった デコーダーの実装が2022年11月末からでエンコーダーが2023年1月初頭から
個人でビルドして試せるようになったのが2023年6月半ばでこの頃から話題になりだした
バイナリリリースに含まれるようになったのは2023年12月22日の0.9.0以降 jpegとXLとjpegliのファイルサイズ比較は? jpegliは布系が苦手なのか・・・av1みたいにおじさんのあし毛が消えたりする現象が起きるんかな 久しぶりにJXL使ってみたけど前より安定して動いている
0.7の頃に俺のPCをクラッシュさせたから避けてたけどそろそろ本格的に使ってみようかな こういう画像フォーマットってゲームのテクスチャでも使われたりすんのかな 「使われたり」の意味によって変わってくるけど
GPUデコードできないフォーマットがランタイムのテクスチャとして使われることはない
基本据え置きならBCモバイルならASTC、他の選択肢はほぼない
ストレージレベルでの利用なら普通にされてる
例えばグランツーリスモがJPG XLを最近使い始めたはず https://jp.khronos.org/news/press/khronos-ktx-2.0-gltf3d
専用のフォーマットだけど、JPEGの様な圧縮をしといて、実行時(ロード時)にGPU用のフォーマットに展開するとかしてるね なるほどやっぱ専用のフォーマットがあるんだなありがとう そもそもテクスチャって256色gifで十分でフルカラーである必要性って無さそう
解像度上がろうが結局テクスチャよりシェーダでよく見えるかどうかだし GPU用のテクスチャーは4×4の中から代表色2色を選んでそれらを線形補間して色を決めるのが基本的なやり方だ
パレットは256色をレジスタなりに保持してなきゃいけないから効率が良くないな gifとか言ってる時点で素人さんなんだから細かいこと言いなさんな avifはゴミすぎて自滅しちゃったし
結局普及度も対応度もwebpだけ一抜けしたな お前には縁がないだろうが日々女子たちが映え写真大量に
とってるが今時どのフォーマットで保存してるの ニュースサイトの画像にavif使ってる所も有るぞ
avifは普及期に入ったな av1エンコーダはだいぶ早くなってavif流行り始めてるよ svt-av1は相当速いけどavif向けだと制限多すぎて使いにくい 今からでも遅くないから静止画向けだけでもライセンスフリーにしたらHEIFが覇権取れるのに >>669
libjxlが一向に完成しないから無理 xlってお手軽に変換出来るスマホアプリすらないんだから普及する訳が無い 性能もアプリの数も関係ない
旗振り役の大企業がいるかどうかが全て JXLって昔APNGを推すMozillaがChromeを糾弾してたのを思い出す
どちらも劇的に性能向上するわけでもなく互換性だけが取り柄という共通点
結局モダンブラウザが全対応したのにAPNGは普及せず終了 つーか互換性もねーだろ
互換性しか取り柄ないってUltraHDRとかいうゴミと勘違いしてねーか NothingPhone(2a)買ったんだが撮って出し写真がUltraHDR対応だったわ
UltraHDRってPixel限定じゃなかったんだな
OSネイティブサポート最高 Appleはjxl対応してるんだしもっと使わんかなあ webpもavifも動画コーデックの1フレームってのが共通してる
jxlも動画コーデックも一緒に作るべきだったのかもしれない
寿司職人も寿司しか握れないってよりも、和食も作れると言う人の方が採用されやすいだろうw このベンチじゃJXLよりAVIFの方が速いことになってるが
ttps://storage.googleapis.com/avif-comparison/decode-timing.html >>684
雇用コストや肝心の寿司の品質低下を伴わない前提なら、そうかもね avifはプログレッシブに対応してないからな
jxlは対応してるから同じデコード速度だったとしてもjxlのほうが描画は速い プログレッシブ使わなければJXLの方が遅いってこと?
世の中のプログレッシブ利用率ってどのくらいなんだろう >>690
いや使わなくてもjxlのが早いよ
まあ画像のためのフォーマットなんだからwebp.avifみたいな派生より性能いいのは当たり前だけど 特許騒動あったgifもその反動で出てきたpngも生き残ってるけど
xlやavifはお手軽に変換出来ない時点で消える運命にある 現状のロスレスプログレッシブJXLは普通のロスレスJXLと比べて約2倍、
pngと比べても少し大きぐらいのサイズになるから話にならん
そこまでデカくなるならもうサムネを別途格納したほうが早いし、省サイズだろ ロスレスを使う状況ってそんなシビアにデータサイズとか見てないからな
pngでいいよね webpとかavifそこそこ使われるようになってきてるけどロスレスとして使われてるのほぼ見ないもんな avifのロスレスはクソだからな
ホントそれが残念 あのAppleが電撃参入して一気に進展するかと思いきや
相変わらずのトロさで当のAppleが既にやる気失せてるの草生えますよ
Googleはこうなるのを見抜いてたんやね pngはpngな時点でロスレスとわかるけど
jxlもavifもwebpもわからん
拡張子からわけろや pngだって減色という選択肢はあるからロスレスとは限らんよ 可逆は速度と圧縮率のバランスでwebpに落ち着いてしまったなぁ グレスケのlossy画像だと、AVIFとJXLでどう調整してもAVIFの圧勝だった
内部実装に詳しくないけどYUV400ネイティブ対応してるのが大きいのかな? avifのロスレスのアルゴリズムが全然分からん
ググる程度じゃ分からんかった
いやソース見ろよと言われればその通りなんだが…
猿でも分かるavifロスレスアルゴリズムと言う記事を誰か書いてくれくれ ロスレスAVIFはAV1に規定されているロスレスモードを使うので
イントラ予測して予測残差を直交変換して量子化してエントロピー符号化するという流れは同じ
ロスレスモードは周波数領域への変換にDCTもしくはAsymmetric DSTの代わりに可逆のWalsh-Hadamard変換を使うのと
量子化係数は常に1なので精度が落ちないという点が異なる >>706
DCTが不可逆と思ってる時点で信憑性がな… さらに言うとH.264以降動画のDCTと言えばいわゆる整数DCTで
実装により変換に差が出ないようにはなから実数で処理することを諦めている 実数にするから不可逆て…
可逆か不可逆かの定義はそれで良いのか?