22/01/07 22:26:54.37 2bbq9J7r.net
twitterなんかもgif投稿するとmp4に自動変換される仕様やな
464:名無しさん＠お腹いっぱい。
22/01/08 03:09:05.89 UKvaS7xS.net
SNSで言えば画像メインのインスタ等から音楽と動画セットのtiktokがきてるし音無しの動画像は居場所が減ってきてんね…
465:名無しさん＠お腹いっぱい。
22/01/09 04:41:50.97 Hy4a9M9k.net
今更知ったんだけどデジタルシネマってJPEG2000使ってるんだな
466:名無しさん＠お腹いっぱい。
22/01/10 05:35:31.87 1JMilJxo.net
医療現場もjpeg2000よ
467:名無しさん＠お腹いっぱい。
22/01/10 15:55:37.43 juolPBsw.net
AVIFエンコーダ
SquooshはlibavifのWebAssembly実装
Cloudflareはcavif-rsというrav1eベースのRust実装を使ってるらしい
URLﾘﾝｸ(github.com)
468:名無しさん＠お腹いっぱい。
22/01/12 21:44:05.29 1NLzaTWY.net
>>448
はえーそうなのか
その辺も新しいフォーマットになれば便利そうだけど変えるハードル高そうだなあ
469:名無しさん＠お腹いっぱい。
22/01/12 22:32:07.07 8Xd/oJYp.net
今、JPEG2000使ってる業界は今後もそのままでしょ
JXLに変えても大差はないから
470:名無しさん＠お腹いっぱい。
22/01/13 00:35:32.52 eiXsiNQ2.net
mac用avifエンコーダーもweb用の流用して対応してくれないかな
471:名無しさん＠お腹いっぱい。
22/01/13 16:30:25.23 NW0woHNQ.net
アニメーションのavif見れるとこ無いかな
472:名無しさん＠お腹いっぱい。
22/01/14 15:17:35.34 u49JhELV.net
URLﾘﾝｸ(bugzilla.mozilla.org)
英ガーディアン紙のエンジニアがBugzillaに寄稿しとるな
>ガーディアンの代表として、JPEG XLの採用に対する私たちのサポートを表明したいと思います。
・JPEG XLは現在標準化中で、私たちはウェブブラウザが標準を実装し、ウェブコンテンツ制作者がニーズに最適な標準化された形式を決定できるようにする必要があると考えています。新しい標準化されたフォーマットの一般的な採用は、ブラウザのロードマップに影響を与える能力よりも、むしろ使用法によって推進されるべきだ
473:と考えています。 ・JPEG XLの後方互換性とJPEGでのエンコードおよびデコードの利点により、CDN（またはクラウド画像サービス）とコンテンツ制作者が迅速に採用すると考えています。自社サイトについては、CDNと一部のブラウザでサポートされ次第、採用する予定です。 ・JPEG XLは現在最も強力な画像フォーマットだと思いますが、非常に低い画質ではAVIFの方がうまくいく可能性があるという条件が付いています。 ・より効率的な圧縮フォーマット（JPEG XLやZstandardなど）を使用することは、持続可能性にプラスの影響を与えると考えています。
474:名無しさん＠お腹いっぱい。
22/01/14 20:40:17.43 rQ1BusTo.net
>>454
おっ地味に写真管理サイトSmugMug+FlickrのCEOの人もJXLサポートの意向を表明してるやん！
本気で対応頼むでまじで
475:名無しさん＠お腹いっぱい。
22/01/17 23:12:26.13 dhme7k/r.net
>>425のアプデ後
URLﾘﾝｸ(pbs.twimg.com)
476:名無しさん＠お腹いっぱい。
22/01/19 12:01:57.73 wFLusHO7.net
Firefoxのjxlサポート優先度上がった
P5 → P3
URLﾘﾝｸ(bugzilla.mozilla.org)
477:名無しさん＠お腹いっぱい。
22/01/19 19:05:48.66 DW4oxv+5.net
P5: Will not fix, but will accept a patch
P3: Backlog
P2: Fix in the next release cycle or the following (nightly + 1 or nightly + 2)
リリース版に入れるつもりはないけど、やるつもりはあるみたいな優先度？
478:名無しさん＠お腹いっぱい。
22/01/19 22:54:54.36 Cok0c9tT.net
まあ入れるも入れないも実装はすでになされていて
フラグの切り替えで有効化できるから、ただの形式的な表示だろ
479:名無しさん＠お腹いっぱい。
22/01/20 02:21:38.09 FXlOM5Pf.net
P3のAVIFは普通にサポートされたし
P1だったHEVCは結局サポートされ無かったし
あんまり参考にならんな
480:名無しさん＠お腹いっぱい。
22/01/25 01:10:25.66 ixwdVvr6.net
ごめんこの画像の1番上の設定だけe9の後ろにE3ってのがついてるのってどういう意味？
圧縮の設定とか全然詳しくないんだけど何となく気になった
URLﾘﾝｸ(pbs.twimg.com)
481:名無しさん＠お腹いっぱい。
22/01/25 03:34:01.61 QDq8f09f.net
そのグラフを作った人のみぞ知る
Twitterで本人にリプ送って訊いたら確実に正確な回答貰えそうやけどな
482:名無しさん＠お腹いっぱい。
22/01/25 04:27:17.40 QDq8f09f.net
URLﾘﾝｸ(docs.google.com)
によると-E 3はModular modeのoptionの一つでextra propertiesを意味すると書いてあるな
>Use -s 9 -E 3 for best quality lossless file. E make channels see each others (E 3 all colors channel see each other) seam one of the flags that always make smaller file but is slow
483:名無しさん＠お腹いっぱい。
22/01/25 04:59:18.65 QDq8f09f.net
スナイアーズ博士による-E optionの解説あった
URLﾘﾝｸ(encode.su)
>Each channel separately does mean it's missing opportunities to use previous channels as context for the current one, e.g. for a 10-channel image you could give it as a 10-channel image to cjxl -q 100 -e 9 -E 9 and the -E option means it will take up to 9 previous channels as potential Extra properties when learning the MA tree context model.
Also color decorrelation could be useful - RCTs can be applied to arbitrary channels, though the current encoder will only try that on the first 3 channels (since it assumes those are RGB or CMY and thus quite correlated).
484:名無しさん＠お腹いっぱい。
22/01/25 05:26:26.67 r4jjVxb5.net
なるほどよくわからん
485:名無しさん＠お腹いっぱい。
22/01/25 05:34:55.30 r4jjVxb5.net
>>463
速さへの拘りを感じるオプションの数々
イイネ！
486:名無しさん＠お腹いっぱい。
22/01/25 12:12:12.20 VoNU53rv.net
>>463
>>464
ありがとう
あとで翻訳して読んでみる
487:名無しさん＠お腹いっぱい。
22/01/26 16:25:43.57 b2FTyExU.net
ロスレス圧縮のサイズ比較
URLﾘﾝｸ(docs.google.com)
488:名無しさん＠お腹いっぱい。
22/01/26 16:32:23.17 c2LolPCg.net
画像ファイルのサイズ圧縮＆JPEG/PNG/WEBP/AVIF/JXLにフォーマットを変換＆オフラインでも利用可能な「Compress Images」
URLﾘﾝｸ(gigazine.net)
489:名無しさん＠お腹いっぱい。
22/01/27 00:48:26.35 QAZi3IOB.net
>>468
jxlが0.7.0だから一番新しいやつか
490:名無しさん＠お腹いっぱい。
22/01/29 03:50:48.83 Om7ncLsU.net
古いスレだから上の方のレス見ると面白いな
>>32とか>>54とか
491:名無しさん＠お腹いっぱい。
22/01/29 05:07:00.88 vQ3tbjxx.net
JPEGは結局今も使ってるという
MP3はそろそろAACかOpusに置き換わってきたかな？
492:名無しさん＠お腹いっぱい。
22/01/29 12:59:12.49 byqT1YfI.net
最新音声コーデックOpusももう10年選手か…時が経つのはやい
493:名無しさん＠お腹いっぱい。
22/01/29 13:23:33.29 EhAOlHFF.net
>>468
圧縮率PNG比33~58%ってすごいね
494:名無しさん＠お腹いっぱい。
22/01/31 17:13:28.80 1SvSROA5.net
>>328
Susieプラグイン作ってる人居た
URLﾘﾝｸ(github.com)
495:名無しさん＠お腹いっぱい。
22/02/02 05:51:41.08 t0mlUtDL.net
LCPだけでは画像最適化に不向き、新しい指標が必要な理由
URLﾘﾝｸ(zenn.dev)
496:名無しさん＠お腹いっぱい。
22/02/14 11:24:42.26 kbkbhSCg.net
JXLに期待してる人多いけどよ、FLOSSで低遅延、低ビットレートでも高音質のopusが未だに覇権取れず
やっとゲームの分野でVorbisから置き換わったくらいなのを見たら土台無理なのくらい分かるでしょうよ
497:名無しさん＠お腹いっぱい。
22/02/14 13:03:19.34 ckqNYYcm.net
覇権が取れるかどうかはどうでもいい
自分が所有する画像をjxlに変換してメリットがあるかどうかが重要
498:名無しさん＠お腹いっぱい。
22/02/14 13:59:52.87 D9xx00RT.net
>>477
音声圧縮のopusが流行ってないから画像圧縮のフォーマットのJXLも流行らないってこと？
繋がりがよく分かんないや
499:名無しさん＠お腹いっぱい。
22/02/14 14:40:57.58 DBnfLQJB.net
検索エンジンの扱いがopusか他のaudioフォーマットで変わるなんてことはないと思うが
jxlをどうgoogleが扱うかは知らないけど
500:名無しさん＠お腹いっぱい。
22/02/14 20:49:29.09 9gCDUJMR.net
WebRTCはOpus一択だぞ
501:名無しさん＠お腹いっぱい。
22/02/15 08:04:06.18 GEYIOM//.net
YouTubeもOpus（とAAC）だが
502:名無しさん＠お腹いっぱい。
22/02/15 10:14:47.95 H5TKxHC7.net
URLﾘﾝｸ(i.imgur.com)
503:名無しさん＠お腹いっぱい。
504:
>>483 https://twitter.com/jonsneyers/status/1493314353998794753 例えば、p10を見た場合、mozjpeg q85 (avg bpp: 1.579) は webp q90 (avg bpp: 1.437), avif q=15 (avg bpp: 1.322) および jxl q85 (avg bpp: 1.154) と同様の知覚品質を持つというのが一つの結論である 【悲報】webpさん、mozjpegに負ける (deleted an unsolicited ad)
505:名無しさん＠お腹いっぱい。
22/02/16 08:44:31.64 uo+zj76j.net
AVIFを使ったサイトが増えてきたな
やっぱChromeとFirefoxが対応したのが大きい
あとはWindowsのAV1 Video Extensionがバグ修正してくれたら満足
506:名無しさん＠お腹いっぱい。
22/02/16 19:35:06.43 BRrb8DqJ.net
>>484
なんでファイルサイズじゃなくてエンコーダのオプションで比べるの？
q95～100あたりのロスレスでかすぎるからとりあえず圧縮しました的なとこでjpgに劣る事が多いのはwebpの欠点だと思うけど
それでもサイズはmozjpegよりだいぶ縮むぞ
507:名無しさん＠お腹いっぱい。
22/02/16 19:49:37.49 KFGZY1P6.net
jpgのbpp 1.579とwebpのbpp 1.437でwebpのほうがわずかに知覚品質が上なら一応webpの勝ちでは
508:名無しさん＠お腹いっぱい。
22/02/16 20:20:49.92 +Twr1llu.net
漫画の比較だけどwebpとmozjpegでカラーとモノクロをどっちもq75でやってみたら
画質も圧縮もwebpの方が余裕で上だったわ
509:名無しさん＠お腹いっぱい。
22/02/16 20:37:06.38 fC/uV9TL.net
まさかとは思うけどbppが(横幅*縦幅)/(ファイルサイズ*8)だとわかってない人がいる？
510:名無しさん＠お腹いっぱい。
22/02/16 21:40:45.83 Gjvc6x9E.net
bits per pixel つまり、 (ファイルサイズ * 8) / (横 * 縦)
小さいほど圧縮率が良い
511:名無しさん＠お腹いっぱい。
22/02/16 21:43:11.16 ZDin1ORj.net
>>490
計算間違ってた恥ずかし
512:名無しさん＠お腹いっぱい。
22/02/16 22:08:51.87 r2gFO3FA.net
自分は個人用で90とか95あたりの圧縮したことしかないんだけどネットでよく使われてるのはqどのあたりなんだろか
513:名無しさん＠お腹いっぱい。
22/02/16 22:40:30.72 ks6XWu10.net
squooshのデフォルトはどの画像フォーマットも一律75だけど
jpeg系だと85以上ほしいし
逆にavifには過剰という塩梅
514:名無しさん＠お腹いっぱい。
22/02/16 23:10:03.46 g3N09yCR.net
ミスavifだけデフォ30だわ
q最大値63という半端な数値ややこいわ
515:名無しさん＠お腹いっぱい。
22/02/17 00:13:59.84 nvqG4r21.net
>>493 >>494
はえーありがとう、max100じゃないやつもあるんだな…
516:名無しさん＠お腹いっぱい。
22/02/17 05:49:54.26 K7N1XlFV.net
webpとjxlってどのくらい差あるの？
もうwebpに乗り換えちゃったんだけど
517:名無しさん＠お腹いっぱい。
22/02/17 06:10:07.50 ESna9mr4.net
当分はwebpで良さそう
2年後くらいからJXLも視野に入りそう
518:名無しさん＠お腹いっぱい。
22/02/17 10:12:20.76 DGEHrsVO.net
PNGとWebP Losslessを比べると、置き換えてもよい感じだけど
JXLはデコード速度がまだ最適化されていない印象
PNG:15.0MB - 44MP/s (iftwic.spi)
WebP:11.3MB - 30MP/s (iftwebp.spi)
JXL:9.4MB - 8MP/s (djxl 0.6.1)
519:名無しさん＠お腹いっぱい。
22/02/17 14:16:01.17 J8bX4QI5.net
>>498
それってspeedいくつくらい？
520:名無しさん＠お腹いっぱい。
22/02/17 21:01:34.52 jUcFhUm3.net
>>499
>>498は1秒で何メガピクセル表示できるって値
1920x1080(約2MP)の表示だと
PNG 0.045秒
WebP 0.066秒
JXL 0.250秒
ぐらいかかるということ
WebP Losslessは微妙にイラッとする遅さだと感じる
あの微妙な速度を
521:我慢するぐらいなら多少でかくてもPNGがいいかなって思う
522:名無しさん＠お腹いっぱい。
22/02/17 21:03:37.21 SaRC1Suw.net
effort設定値はいくつくらい？
523:名無しさん＠お腹いっぱい。
22/02/17 21:48:06.47 pRVmHf9z.net
ifavif.spiを参考にlibavifとdav1dの最新版でマルチスレッド高速版を作ってみた
けど思ってたほど速くならなかった
まだ実用的な段階ではないのか
ifavifx.spi
URLﾘﾝｸ(www.axfc.net)
524:名無しさん＠お腹いっぱい。
22/02/17 22:24:20.56 fjsP7lTG.net
>>500
ごめん、それはわかってるけど>>501的なことが聞きたかった
525:名無しさん＠お腹いっぱい。
22/02/17 23:04:48.91 cWCbbk2B.net
496は、デフォルト値だからe7だった、コア数4
環境変わってしまって申し訳ないけど、EFFORTの値、一通り試してみた コア数8
JXLはCPUフルに使っていて、コア数増えればもっと早くなるかも
PNG:12.0MB 55.7MP/s (iftwic20)
WebP:8.91MB 41.4MP/s (iftwebp10)
JXLe1:9.92MB 45.7MP/s - 87.20MP/s 28.21MP/s
JXLe2:9.61MB 41.7MP/s - 74.48MP/s 26.33MP/s
JXLe3:8.71MB 19.1MP/s - 37.53MP/s 17.48MP/s
JXLe4:7.84MB 14.8MP/s - 25.07MP/s 1.15MP/s
JXLe5:7.74MB 15.5MP/s - 25.32MP/s 0.81MP/s
JXLe6:7.56MB 13.6MP/s - 26.34MP/s 0.80MP/s
JXLe7:7.24MB 13.5MP/s - 23.31MP/s 0.37MP/s
JXLe8:7.22MB 13.5MP/s - 22.95MP/s 0.14MP/s
JXLe9:7.14MB 12.9MP/s - 20.25MP/s 0.03MP/s
(ifjxl - djxl0.6.1 cjxl0.6.1)
526:名無しさん＠お腹いっぱい。
22/02/17 23:19:04.92 ONdVqOq2.net
>>504
これはいいデータ
乙
527:名無しさん＠お腹いっぱい。
22/02/18 00:09:57.88 tpL24fX2.net
URLﾘﾝｸ(eclipseo.github.io)
ここに載ってるe3,e5,e7,e9E3のデータだとeffort値はデコード速度には殆ど影響しない様子だったけど
>>504の結果を見るとe3~9は概ね横並びでe1,2はかなり別格っぽい感じですな
528:名無しさん＠お腹いっぱい。
22/02/18 14:54:48.21 aM1cBZg5.net
なんかめんどくさいこと起きてるっぽいな
Alarm raised after Microsoft wins data-encoding patent
URLﾘﾝｸ(www.theregister.com)
529:名無しさん＠お腹いっぱい。
22/02/18 15:55:00.98 JI3NWdcE.net
>>507
＞Microsoftは先月、rANSと呼ばれるデータエンコード技術の改良に関する米国特許を取得した。rANSは、大手テクノロジー企業やオープンソースプロジェクトで使われているデータ圧縮方式をサポートするAsymmetric Numeral System（ANS）ファミリーのいくつかのバリエーションの1つである。
このアルゴリズムは、JPEG XLやCRAMのほか、Facebook(Meta)やNvidiaなどが運営するオープンソースプロジェクトで使用されている。
The RegisterはMicrosoftに、特許の使用料を求める意向があるかどうかを尋ねたが、同社は回答していない。
ANSの生みの親であるJarosław Duda助教授は「このrANSバリアントは、実質的に完成しているJPEG XLで使用されており、サポートを獲得しつつあります。JPEG同様の計算コスト、JPEGとの互換性、プログレッシブデコード、JPEGよりも約3倍優れた圧縮、HDR、アルファ、ロスレス、アニメーションなどのJPEGに不足している機能を提供します。その背後には、主にGoogleの大規模なチームがあります。30年近く経った今、Chrome、Androidをはじめ、�
530:ﾊ真や画像用の1992年のJPEGに取って代わるはずです。しかしMicrosoftの特許がJPEG XLの採用をより困難にする可能性があります」と語る。 一方、JPEG XL仕様のエディターであるJon Sneyers氏は「私の知る限りこの特許はJPEG XLに影響しないはずです。MicrosoftはISOに対して影響を与えるとは宣言していません。MicrosoftもJPEGに参加しているのでJPEG XLで使われている技術を認識しているでしょう」と述べた。
531:名無しさん＠お腹いっぱい。
22/02/18 16:09:55.46 oaWQ3ZQH.net
MSなのでゲーム業界でいう任天堂とかがやってる防衛出願の線もありそう？
特許取得企業がインター○ジタルみたいなパテントトロールじゃなくてよかったな
532:名無しさん＠お腹いっぱい。
22/02/18 16:52:46.94 GvRMiIxE.net
MSがFATMAN-Gの掌握に動いたってことだぞ
これは良くない傾向
俺はIBMになりたいんだ！IBMになって1984するんだ！という表明だぞ
533:名無しさん＠お腹いっぱい。
22/02/18 17:11:31.80 MHtKYJbw.net
昔のMSならともかく今のMSはOpen Invention Networkに加入して特許開放したりオープンソースプロジェクトにかなり貢献してるし大丈夫やろ知らんけど
534:名無しさん＠お腹いっぱい。
22/02/18 23:31:34.31 LlJyddkT.net
JpegXRの産みの親マイクロソフトが姪っ子のJpegXLを虐める姿なんて見たくないよ(´；ω；｀)
535:名無しさん＠お腹いっぱい。
22/02/19 09:53:37.24 MuBPGKtw.net
QRコードを開発したデンソーは、普通のQRコードが世の中でいくら使われても全く儲からないけど
狭い範囲で使われる、カスタム仕様のQRコードを開発・販売する権利を得たことで儲けを出してるみたいな話を聞いた
画像フォーマットも多分そういうのがあるんだろう
MSはJPEG XLの発展製品で儲ける権利を狙ってるだけで、
JPEG XLは普通に世に出せるはず
536:名無しさん＠お腹いっぱい。
22/02/19 12:28:07.13 P/bKvb5e.net
Jonがredditで書いている事によれば、
JPEG XLで使ってるANSは、JPEG XLの元になったpikで使っていたのと同じ種類のANSである
pikが公開されたのが2017年で、MSが特許を申請したのは2019年だ
537:名無しさん＠お腹いっぱい。
22/02/19 13:01:33.20 1C+LoCn/.net
>ソフトウェア特許の標準的な用語がない。 化学式を指定できる医薬品特許とは異なり、ソフトウェア特許は同じことを異なる方法で説明する場合があります。
>We are back to patenting an obscure written variant of a plurality of 1+1=0 and 1-1=0 statements.
>先行技術の存在は、そもそも特許の付与を妨げるはずでした。 しかし、米国の特許制度は何年もの間そのような特許を発行してきました。 問題は、特許を取り消すために訴訟を起こす必要があるということです。
多くの法域ではソフトウェア特許は不可能ですが、米国経済の重要性と米国の非地形性の傾向は、世界の他の地域が米国のブーンドックの地方裁判所を恐れて生きる傾向があることを意味します。 これは、イノベーション、開発、商取引の足かせになります。しかし、根本的な問題は、すべてのソフトウェア特許が本質的に数式の表現であり、特許性がないことです。
>この記事から、JPEG XLとCRAMはどちらも先行技術であるように思われるため、関連する委員会は、そのような主張を行うために単に公開する必要があります。
コメント欄白熱しとるなｗ
538:名無しさん＠お腹いっぱい。
22/02/19 13:26:31.43 jwjt+3zd.net
アメリカの特許制度は複雑怪奇
ポーランドの大学研究所の先生が発明した符�
539:�化アルゴリズムを自国の特許にするとかジャイアニズムのそれで笑った これが中国だったらもっと非難轟々だったろうなw
540:名無しさん＠お腹いっぱい。
22/03/02 17:01:13.07 sPC5wWqS.net
jpeg xlとwebpとAVIFの圧縮率、表示速度を比較してるサイトどこ？
てか表示速くてもメモリ食って負荷が高いとかならマイナス要素になるけど
541:名無しさん＠お腹いっぱい。
22/03/02 18:17:59.57 DEYasKCw.net
圧縮率は>>468とか>>483
表示速度比較してるサイトはまだなかったはず
542:名無しさん＠お腹いっぱい。
22/03/05 00:33:19.48 /2PCthSX.net
Alliance for Open Mediaがんばれとしか
543:名無しさん＠お腹いっぱい。
22/03/05 07:16:30.73 HktVJ4rO.net
AOMはAV1が本分だから画像より動画の方で頑張ってる
544:名無しさん＠お腹いっぱい。
22/03/05 10:55:00.15 mL+b9o3b.net
AVIFはロスレス弱いんだね
デコード速度はJXLe5程度っぽい?
思っていたほど遅くはないけど、絶望的にエンコードが遅い…(JXLe9位)
545:名無しさん＠お腹いっぱい。
22/03/05 11:37:28.45 j03NF66P.net
動画の方は対抗馬のHEVC VVCが特許料かかるから価値あるけど、JPEG XLがある画像界におけるAVIFの価値は…
546:名無しさん＠お腹いっぱい。
22/03/12 03:50:12.34 tF2bfCQ0.net
win版のxnconvertを使って、jxlファイルを読み込めたのですが
画像サイズが120ピクセル前後の画像として読み込んでしまいます
設定の問題でしょうか？未対応なだけでしょうか？
547:名無しさん＠お腹いっぱい。
22/03/12 21:25:12.47 vxTbDV4a.net
>>523
普通に対応してたはずだし自分の環境だと問題なかったから多分設定かなんかの問題じゃないかな
548:名無しさん＠お腹いっぱい。
22/03/12 21:46:00.27 tXsJBr/e.net
avifとかjxlの組み込み済みandroid向けライブラリ見つけたけど、なぜかlibjpeg-turboとlibwebpがブッキングしてビルドできん。うーん。
549:名無しさん＠お腹いっぱい。
22/03/12 21:46:31.51 tXsJBr/e.net
ビルド出来るか誰か試してくれんか？
URLﾘﾝｸ(github.com)
550:名無しさん＠お腹いっぱい。
22/03/12 22:34:08.99 tF2bfCQ0.net
>>524
ありがとうございます
再インストール等を試しても不具合が続いたのですが、
インストーラーではなく"zipped program folder"の方を落として使ったところ問題なく動きました。
ご報告までに
551:名無しさん＠お腹いっぱい。
22/03/25 13:10:00.58 C7Lnebzd.net
【訃報】画像ファイルフォーマット「GIF」生みの親スティーブ・ウィルハイト氏死去
URLﾘﾝｸ(gigazine.net)
Burn ALL GIFs day
552:名無しさん＠お腹いっぱい。
22/04/01 00:38:46.77 QsMBa135.net
標準化
URLﾘﾝｸ(www.iso.org)
553:名無しさん＠お腹いっぱい。
22/04/01 13:20:27.05 RbFt+9iv.net
誰か買ってよ
554:名無しさん＠お腹いっぱい。
22/04/01 17:36:01.03 muZSOxkw.net
>>525 >>526
ArchLinuxでビルドできたよ
AvifとHeifは試してない
555:名無しさん＠お腹いっぱい。
22/04/01 19:59:45.38 cdidUcDW.net
libjxlは何で半年もリリース止まってるの？
何か問題発生した？
556:名無しさん＠お腹いっぱい。
22/04/02 18:13:40.59 evnTbaxo.net
こーいうのはコミットが止まってなければ大丈夫
557:名無しさん＠お腹いっぱい。
22/04/06 00:25:11.56 gXQAHEuc.net
【2022年最新版】mozjpeg vs guetzli vs webp vs avif 圧縮率
URLﾘﾝｸ(qiita.com)
558:名無しさん＠お腹いっぱい。
22/04/06 00:40:36.07 1BvNt6mW.net
>>534
何も参考にならん
559:名無しさん＠お腹いっぱい。
22/04/06 00:49:16.25 tPX
560:sU0QG.net
561:名無しさん＠お腹いっぱい。
22/04/06 07:24:17.90 zOnL7Blu.net
>>534
URLﾘﾝｸ(gigazine.net)
これをお手本に、書き直してから来なさい
562:名無しさん＠お腹いっぱい。
22/04/06 07:39:05.66 zOnL7Blu.net
これとかも比較的わかりやすいね
URLﾘﾝｸ(apribase.net)
563:名無しさん＠お腹いっぱい。
22/04/08 05:15:45.38 pE2TnQXQ.net
結局今年もWebP最高で終わりそうだな
564:名無しさん＠お腹いっぱい。
22/04/08 08:35:24.17 cTIruYlP.net
定期的にwebpの勝ちだなって言ってるやつって同じ人なんかな
565:名無しさん＠お腹いっぱい。
22/04/08 17:55:08.13 0ZTB1aEy.net
jpegの陳腐化を押しとどめているmozjpegの偉大さよ
566:名無しさん＠お腹いっぱい。
22/04/09 19:12:28.34 lmk4kVIg.net
>>532
libjxlバージョン1.0へのマイルストーン
URLﾘﾝｸ(github.com)
567:名無しさん＠お腹いっぱい。
22/04/11 04:42:29.37 YUTFhHaP.net
>>540
俺はあくまで客観的事実を述べているだけだ
今年こそJXLの時代になるならそう言うがどう見ても今年もWebP最高で終わる
568:名無しさん＠お腹いっぱい。
22/04/11 08:28:11.82 ibX8aKt1.net
>>543
webpかjpegかjxlのどれを使うかはユーザが決めることじゃないから、何が最高かだなんて心底どうでもいい
ただし、ブラウザやスマホ側は早くjxlを標準サポートしろとは思う
569:名無しさん＠お腹いっぱい。
22/04/12 00:02:20.66 fD7mQSZB.net
現状はjpeg最高じゃね、使用率的には
570:名無しさん＠お腹いっぱい。
22/04/12 15:10:41.07 YcuP2ifh.net
webpは写真とかそういう用途には使いにくいからな
エンコードに時間かかりすぎるから
普及に限界ある
スレタイ的にもwebpはjpegの後継じゃない
571:名無しさん＠お腹いっぱい。
22/04/12 18:05:45.60 UjvRWaz+.net
写真用途なら解像度が両側に10億（2^30 -1）ピクセルを超える画像サイズ対応のJpegXL一択
Jpegは最大65,535 × 65,535ピクセル（2^16 -1）しか対応してないから写真資料の保存に困ったことがある
avif（65,536x65,536）やwebp（16,383 x 16,383）は論外
572:名無しさん＠お腹いっぱい。
22/04/13 03:35:55.02 C4OS9BKT.net
超解像度写真管理するようになってからデコード処理速度性能重視になったな
あとプログレッシブレンダリングが結構捗る
573:名無しさん＠お腹いっぱい。
22/04/13 04:18:24.21 j8EynlJU.net
圧縮アルゴリズム自体webpとかより高解像度向きだよね
webpやavifのような細部塗り潰しは低解像度である程目立たなくて正にweb向けって感じだ
エンコードとデコードの遅さも低画像度なら大した問題にならないしほんと良く特化してると思うわ
avifは流石に遅過ぎてこれじゃ普及しないだろうなーってひしひし感じるけど
574:名無しさん＠お腹いっぱい。
22/04/13 13:20:14.92 uNTFaJq/.net
>>548
プログレッシブレンダリング良いよね
それあるからJXLはweb向きでもあると思う
575:名無しさん＠お腹いっぱい。
22/04/16 04:02:25.10 vsrz79Oc.net
JPEG XL Part 4: Reference software
がFDIS段階に入ったな
576:名無しさん＠お腹いっぱい。
22/04/17 01:51:48.03 Cs1/kiyU.net
本当に無知で申し訳ないんだけどあの標準化って作業はなんのメリットがあるの？
あと何で4パートで分けてるんだろう
577:名無しさん＠お腹いっぱい。
22/04/17 04:38:16.75 uNgzrMxP.net
箔がつく
しっかり校閲されるから互換性や特許等の心配が減る（ベンダーが嬉しい）
とかかな
578:名無しさん＠お腹いっぱい。
22/04/17 04:39:40.34 uNgzrMxP.net
パート分けしてるのは最低限必要なところから順にやってくことで使えるようにするのを早めたかったからかと
579:名無しさん＠お腹いっぱい。
22/04/17 06:18:52.96 tcSNhIIl.net
現場猫は聞いたことあるやろ
標準化された仕様書が無いと皆オレオレ実装やり始めて収拾つかなくなるんや
580:名無しさん＠お腹いっぱい。
22/04/17 06:54:54 zzt68zsQ.net
よくわからんが、まぁ動いてるからヨシ！
581:名無しさん＠お腹いっぱい。
22/04/17 07:12:03 PjtUsAVX.net
顧客「環境によって挙動が全然違うんですけど・・・
582:名無しさん＠お腹いっぱい。
22/04/17 08:01:08.81 ojTLaLCZ.net
ISO/IEC 18181はJPEG XLの規格書やJPEG XL準拠製品実装の開発を支援指導する仕様書も含まれてる
Part 3: Conformance testingに違反してたらJPEG XL非準拠のパチモンってこと
583:名無しさん＠お腹いっぱい。
22/04/17 13:21:20.42 Cs1/kiyU.net
教えてくれてありがとう
584:名無しさん＠お腹いっぱい。
22/04/19 06:29:49.49 LARYOCpP.net
jpeg xlのバージョン0.6.1で止まってるのに0.7.0使ってるグラフとかあるのはなんでだろ
585:名無しさん＠お腹いっぱい。
22/04/19 08:23:18.65 JAXMLtme.net
>>560
その記事には使ってるlibjxlのコミットハッシュはついてないの？
586:名無しさん＠お腹いっぱい。
22/04/20 04:50:46.09 CTgl4hMP.net
JPEGXLと小室圭って似てるよな
587:名無しさん＠お腹いっぱい。
22/04/20 14:41:08.63 NQ8EvNFi.net
JPEG XLはフリーだけど小室圭はフリーじゃないぞ
588:名無しさん＠お腹いっぱい。
22/04/20 19:54:46.09 dp+anzuG.net
フリーじゃねンだわ
589:名無しさん＠お腹いっぱい。
22/04/20 20:30:36.64 5XkHu/Nz.net
・沢山の人に期待されてる
・スペックは凄いっぽいけど、まだ使える実力ではない
・一般人は無料で使える
という点が似ている
590:名無しさん＠お腹いっぱい。
22/04/20 21:54:08.72 tO7CURKu.net
この表を見るとjpeg xlが最強すぎに見えてしまう
URLﾘﾝｸ(res.cloudinary.com)
URLﾘﾝｸ(cloudinary.com)
591:名無しさん＠お腹いっぱい。
22/04/20 22:50:24.13 MJX5J1e2.net
JPEG後継画像フォーマットではないが数年前に標準化されたJPEG XSの実装例は最近続々増えてきたなー
JPEG XLの製品実装も早よ
592:名無しさん＠お腹いっぱい。
22/04/21 02:30:24.24 OePtwvWR.net
規格候補が今後発表されるであろうJPEG AIみたいな機械学習ベースのコーディックも楽しみ。数年先の話だけど
593:名無しさん＠お腹いっぱい。
22/04/21 08:20:03.46 /tKEDpoP.net
なんかもう海外では痛いファンボーイ扱いされてるしフォーエバー過ぎて駄目そうな気がしてきた
594:名無しさん＠お腹いっぱい。
22/04/21 14:23:01.68 XZSrZlzB.net
>>568
そんなのあるんか
595:名無しさん＠お腹いっぱい。
22/04/21 16:21:41.70 6OVSGqvF.net
これか。超解像技術とかも内包されるんかな
URLﾘﾝｸ(jpeg.org)
JPEG AIは、シングルストリームでコンパクトな圧縮領域表現を提供する学習ベースの画像符号化規格で、人間の視覚をターゲットとし、同等の主観品質で一般的に使用されている画像符号化規格よりも大幅に圧縮効率を高め、画像処理とコンピュータビジョンのタスクに有効な性能を実現し、ロイヤリティフリーのベースラインをサポートすることを目標としています。
JPEG AIは、クラウドストレージ、視覚監視、自律走行車やデバイス、画像コレクションの保存と管理、視覚データのライブモニタリング、メディア配信など幅広いアプリケーションを対象としています。その目的は、同等の主観品質で一般的に使用されている符号化規格よりも大幅に圧縮効率を向上させるとともに、機械学習ベースの画像処理およびコンピュータビジョンのタスクに対して効果的な圧縮領域処理を必要とする符号化ソリューションを設計することにあります。また、ハードウェア／ソフトウェアの実装に適した符号化・復号化、8ビット／10ビット深度のサポート、テキストやグラフィックスを含む画像の効率的な符号化、プログレッシブ復号化などの要件も重要です。
JPEG AIの最終提案募集は、第94回JPEG会議の成果として、「JPEG AIの使用例と要件」および「JPEG AI共通トレーニングおよびテスト条件」とともに発行されました。関心表明と登録の締め切りは、2022年2月25日です。また、テストデータセットのビットストリームとデコード画像の提出期限は、2022年5月2日です。
596:名無しさん＠お腹いっぱい。
22/04/21 18:30:40.18 BmkiT77j.net
スマホSoCに搭載されてるNPUで画像処理が行われるようになるのかな
ダークシリコン化するエリアを有効活用できるし一石二鳥的な
597:名無しさん＠お腹いっぱい。
22/04/24 13:14:52.79 vJ5k1tmx.net
ffmpegがJPEG XLサポート
598:名無しさん＠お腹いっぱい。
22/05/01 00:16:05.92 0+7yZRZl.net
mpvがJPEG XLサポート
URLﾘﾝｸ(github.com)
599:名無しさん＠お腹いっぱい。
22/05/03 05:42:36.62 W7Xj0Duu.net
>>542
30%か
600:名無しさん＠お腹いっぱい。
22/05/03 22:44:50.36 J9yNliTZ.net
なんでこんなに進展鈍化してんねん
601:名無しさん＠お腹いっぱい。
22/05/03 23:53:08.87 q9P9zHBD.net
バグ取りとか色々あるだろうからしゃーない
602:名無しさん＠お腹いっぱい。
22/05/04 00:02:36.73 CZY/d/Vl.net
マイルストーンのパーセンテージを見て言ってるなら、アクティビティをよく見ろとしか
つい一時間前に#1388がマイルストーンに追加されてパーセンテージが下がってるし
決して鈍化では無いね
603:名無しさん＠お腹いっぱい。
22/05/04 00:16:26.05 erNcCATp.net
なんで libjxl 0.7 出せなくなっちゃったの？
604:名無しさん＠お腹いっぱい。
22/05/04 04:02:16.09 jeqorMU9.net
まもなくFDIS投票が始まるがその間は内容修正ができないらしい
605:名無しさん＠お腹いっぱい。
22/05/04 05:02:50.29 oFak7aJV.net
>>574
スクリーンショット出力形式がJPEG XLに対応
JPEGよりも高品質で高速なスクリーンショットを撮ったり、PNGよりもファイルサイズが小さいロスレス高ビット深度のスクリーンショットを撮ったりすることが可能
まじか
606:名無しさん＠お腹いっぱい。
22/05/04 05:17:21.94 erNcCATp.net
>>580
へー、そうなんだ
607:名無しさん＠お腹いっぱい。
22/05/04 09:58:49.51 /Vku/ITy.net
exampleのencode_oneshot.ccとかdecode_oneshot.ccをもうちょいわかりやすくしてほしい
608:名無しさん＠お腹いっぱい。
22/05/04 11:35:32 lBBJbVNE.net
普及にはもう一段ラッパーライブラリが必要な気がする
WindowsならWICがあれば要らないのかも
609:名無しさん＠お腹いっぱい。
22/05/04 12:11:24.44 T1mCKxs+.net
見てみたけど十分分かりやすくね
マルチスレッド処理とかがデフォルトで組み込まれてる分他より手順多いのは仕方なさそう
610:名無しさん＠お腹いっぱい。
22/05/15 03:29:41 QYc0jsbQ.net
>>566
対応してるはずなのにアニメーションjxlを未だに見ないから気になるー
611:名無しさん＠お腹いっぱい。
22/05/15 04:33:36.70 ql649IQg.net
FFmpeg Lands JPEG-XL Support
URLﾘﾝｸ(www.phoronix.com)
FFmpeg Lands AVIF Muxer For This Image Format Based On AV1
URLﾘﾝｸ(www.phoronix.com)
612:名無しさん＠お腹いっぱい。
22/05/15 04:49:34.01 ql649IQg.net
JPEG XL animation を実装してみた
613: https://qiita.com/unicodon/items/b7c1e1915c34d2f02e04 Support Animated JPEG-XL images https://github.com/WebKit/WebKit/commit/3cddf74bb622d2cad2bd2220cd1f3b9cdab3dfd7
614:名無しさん＠お腹いっぱい。
22/05/15 05:29:16.05 bv6YHGDC.net
必ずしも画像フォーマット規格側とソフトウェア実装側の対応が一致してるとは限らんから
例えばFirefoxはAVIFの静止画形式に対応したがアニメーション形式には未だに非対応という落とし穴
EdgeとSafariに至っては静止画形式すら非対応なんで此処らの足並みが揃わぬ限り普及が進まん
615:名無しさん＠お腹いっぱい。
22/05/15 11:40:43.66 zJBadZlK.net
公式libjxlのアニメーションデコーダ・エンコーダサンプルがないから見かけなくてもしょうがない
616:名無しさん＠お腹いっぱい。
22/05/15 16:45:41.39 QYc0jsbQ.net
v1.0になったら色んなとこで見れるようになるんかなあ
>>588
ありがと
617:名無しさん＠お腹いっぱい。
22/05/21 07:52:00.91 DQfHB0o3.net
jpegXLがはやいとこperfectviewで見れるようになればなあ
618:名無しさん＠お腹いっぱい。
22/05/23 00:40:50.02 GGzTbX5P.net
>>560
Bump version to v0.7 (#571)
URLﾘﾝｸ(github.com)
619:名無しさん＠お腹いっぱい。
22/05/26 00:49:49.30 OeRUYOmK.net
URLﾘﾝｸ(i.imgur.com)
620:名無しさん＠お腹いっぱい。
22/05/28 00:04:51.64 8tltT90g.net
う～ん、苦戦しているな…
URLﾘﾝｸ(encode.su)
621:名無しさん＠お腹いっぱい。
22/05/28 09:59:45.98 VfuYIptd.net
結局のところ遥かに優れたjpeg xlではなく、特許云々の法的リスク安全の保証されたavifが採用されていくのさ（白目）
URLﾘﾝｸ(encode.su)
622:名無しさん＠お腹いっぱい。
22/05/28 10:08:42.82 4hc+h5TN.net
JpegXL（GoogleとCloudinary） vs 特許（マイクロソフト）か、
623:名無しさん＠お腹いっぱい。
22/05/28 11:13:44.70 0FwoiFoK.net
特許侵害訴訟を起こした団体に対して即時ライセンス解除される条項がAV1にあることは割と知られてるけど
似たようなのがJPEG XLにも存在するみたいだ
624:名無しさん＠お腹いっぱい。
22/05/28 12:28:52.86 oU4e7XTe.net
ハフマンの代替として期待されていたANSの発展を、このMicrosoftの提出特許は事実上完全に妨害した。fuckなMicrosoftは淘汰されるべき、
と掲示板で書かれまくってます
625:名無しさん＠お腹いっぱい。
22/05/28 12:43:04.97 4hc+h5TN.net
>>599
違う、特許提出したMicrosoftが、っていうより、
欠陥だらけの特許を認可した米特許庁に問題あり、特許の再審査を私たちは求める、って感じかな
626:名無しさん＠お腹いっぱい。
22/05/29 04:30:39.46 Au2tuh/X.net
やっぱりMSが足枷になったな
これでGoogleもWebP2に注力するだろうしJXLは終了かな
627:名無しさん＠お腹いっぱい。
22/05/29 05:05:26.99 ic2phNNm.net
なんか頭おかしい人湧いてるな
628:名無しさん＠お腹いっぱい。
22/05/29 10:34:04.07 KVNui94g.net
そもそもJPEG XLがそこまで優れてるとは思わんけどな
WebPとAVIFは実際使ってみると悪くない
629:名無しさん＠お腹いっぱい。
22/05/29 10:49:27.38 5k+sR8hB.net
画像フォーマットなんて低容量高品質に拘るブロガーか、HDRとかいう無意味なクオリティーに拘る人だけ騒いでりゃいい
630:名無しさん＠お腹いっぱい。
22/05/29 10:56:47.73 jK216dJV.net
圧縮率か機能性か得意分野がまるっきり違う感じがするな
軽さの定義もファイル容量だったり表示速度だったり人によって認識違うだろうし
別に二者択一ってわけでもないから方向性が異なるアプローチを同時進行させて最終的に
631:jpeg,png,gifに引導を渡すことができれば何でも構わん
632:名無しさん＠お腹いっぱい。
22/05/29 11:14:48.19 L9cn4v42.net
今上がってるすべての新規格をプロデュースしてるGoogleも端からその方針なんじゃないの
意味のない対立煽りだよ
633:名無しさん＠お腹いっぱい。
22/05/29 11:46:58.49 ULBGOBKU.net
avifはav1ハードウェアデコードに対応したGPUじゃないと画像表示が遅いじゃん
ソフトウェアデコード特化で高速化を実現したjpegxlのほうがいいな
634:名無しさん＠お腹いっぱい。
22/05/29 11:51:01.79 ic2phNNm.net
カタログスペック的にはJXLが総合的に良いでしょ（まああの表は半分プロバガンダだけど）
ただ単純に登場が遅いのでその分のハンデはあるし、環境が整いつつある今だからみんな期待してるんだ
もし使ってみて駄目なら使われないだけだし
635:名無しさん＠お腹いっぱい。
22/05/29 13:09:36.65 g0lXZ2qX.net
>>603
実はjpegも使ってみるとそんなに悪くないぞ
636:名無しさん＠お腹いっぱい。
22/05/29 19:00:58 uC9z3u3t.net
結局流行るためには何が良いかよりどこが使うかみたいなとこもあるよな
googleは競わせる側として他の企業がどれに興味持つか気になる、どうせappleは遅れて動くだろうけど
637:名無しさん＠お腹いっぱい。
22/05/30 06:51:37 vuQonp53.net
Facebookのとこは投稿だけならjpeg xlは対応してたね、表示はjpegだけどここが変わればデカイかもなあ
638:名無しさん＠お腹いっぱい。
22/05/30 06:59:10 yk8NfMdA.net
こういうの気にするのって結局ストレージやネットワーク帯域幅を削減したい大手IT企業だからな
639:名無しさん＠お腹いっぱい。
22/05/31 07:20:05.84 p1X7PSB4.net
URLﾘﾝｸ(i.imgur.com)
640:名無しさん＠お腹いっぱい。
22/05/31 19:40:55.78 CLr7QQhh.net
>>542
これ、50%まで来たんだな
まあこれから課題増えたら下がりもするだろうけど
641:名無しさん＠お腹いっぱい。
22/06/01 00:35:05.17 0fmb8Oxd.net
もう世間はwebpとheicで満足してるんだわ
642:名無しさん＠お腹いっぱい。
22/06/01 01:47:54.99 Emtc6S9Y.net
世間が現状で満足していても、Google様が満足してないので、Googleのお膝元ユーザから順にいずれ半強制的に代替わりさせられるかと。
643:名無しさん＠お腹いっぱい。
22/06/01 02:00:10.54 bjmBvN2j.net
てかwebpとHEIFでいいとかどこの世間だよ
大体のSNS未だにjpegGIFだぞ
644:名無しさん＠お腹いっぱい。
22/06/01 09:59:25.91 Yl1N2ogn.net
Wikipediaみたいに拡張子はJPGのままWebPを使ってるケースもあるからな
意外と使ってるサイトは多い
645:名無しさん＠お腹いっぱい。
22/06/01 23:31:11.88 qFZTOOrL.net
>>542
54%になってる、へっへっへ
特許とか色々と難題だろうけど、着々と出来上がってるのを見るだけで楽しいよ
646:名無しさん＠お腹いっぱい。
22/06/02 02:00:32.47 SFK8H6F5.net
URLﾘﾝｸ(pbs.twimg.com)
647:名無しさん＠お腹いっぱい。
22/06/02 02:26:46.97 YdWkRBcx.net
>>620
で、何が分かったの？
648:名無しさん＠お腹いっぱい。
22/06/02 04:39:31.88 3hkVy/B7.net
webp大したことなくね
649:名無しさん＠お腹いっぱい。
22/06/02 10:12:59.04 g/UIr9jY.net
イラスト系（non-photo）の画像エンコードはjxlはavifより弱いのか全体的には。
それでも0.8ではほぼ同等みたいだけど
650:名無しさん＠お腹いっぱい。
22/06/02 10:47:54.13 MbsFwPTq.net
AVIFの細かいところが潰れる特性がnon-photo系だとそこまで悪さしないから強いんだろね
651:名無しさん＠お腹いっぱい。
22/06/02 18:49:09.25 Ew6nIS4K.net
WebPしか勝たん
652:名無しさん＠お腹いっぱい。
22/06/02 19:00:36.49 qN89mUh7.net
>>620
コーデックごとのサイズ容量も欲しいな
低容量ほど通信完了まではやくなるわけだし
653:名無しさん＠お腹いっぱい。
22/06/02 19:27:52.31 U03/zxI
654:/.net
655:名無しさん＠お腹いっぱい。
22/06/02 19:30:56.51 Q5E31NGG.net
点線と線の2種類あるけど何が違うの
656:名無しさん＠お腹いっぱい。
22/06/02 20:21:05.15 bfa2E/mc.net
点線は中央値って書いてる
657:名無しさん＠お腹いっぱい。
22/06/02 20:22:04.26 Q5E31NGG.net
ああ本当だ
書いてあった
658:名無しさん＠お腹いっぱい。
22/06/03 01:05:25.89 CCZ1Lnus.net
デコード速度の比較も見てえなあ
多分jpegxlが1番良さそうだけど
659:名無しさん＠お腹いっぱい。
22/06/03 03:56:54 e4z1EnW2.net
URLﾘﾝｸ(pbs.twimg.com)
660:名無しさん＠お腹いっぱい。
22/06/05 19:38:51.29 ov4w6/Lf.net
>>620
(moz)JPEG vs WebP vs (Kakadu) JPEG 2000 vs (libaom) AVIF vs (libjxl) JPEG XL
って元のツイートに書いてあった、mozjpeg使ってたんだな
661:名無しさん＠お腹いっぱい。
22/06/08 06:12:37.81 MBB06Mpd.net
ロスレス比較の記事
URLﾘﾝｸ(siipo.la)
URLﾘﾝｸ(cdn.siipo.la)
URLﾘﾝｸ(cdn.siipo.la)
662:名無しさん＠お腹いっぱい。
22/06/09 05:03:33 t9vcgQSN.net
>>634
これwebpやたら早いけど8bitまでだからとかそういう理由なんかな
663:名無しさん＠お腹いっぱい。
22/06/09 13:05:18 wG4msmmv.net
JPEG XL Part 3: Conformance testing
がFDIS段階に入った
ワンチャン年内IS発行あるで
664:名無しさん＠お腹いっぱい。
22/06/09 15:54:55 /6NxSIVy.net
Part1
URLﾘﾝｸ(www.iso.org)
URLﾘﾝｸ(www.iso.org)
Part2
URLﾘﾝｸ(www.iso.org)
Part3
URLﾘﾝｸ(www.iso.org)
Part4
URLﾘﾝｸ(www.iso.org)
665:名無しさん＠お腹いっぱい。
22/06/10 11:03:06 YshemOn4.net
>>637
何でパート1だけ2つあるんだろう
666:名無しさん＠お腹いっぱい。
22/06/10 11:28:41.41 FyuIL6+k.net
>>638
改定されたからだね
上がEdition 2
667:名無しさん＠お腹いっぱい。
22/06/10 15:38:13 YshemOn4.net
>>639
はえーありがと
668:名無しさん＠お腹いっぱい。
22/06/15 10:50:32.40 g05cUy36.net
GIMPもjpeg xl対応したのね
URLﾘﾝｸ(gimp.org)
669:名無しさん＠お腹いっぱい。
22/06/24 23:56:02.04 WU63wDdQ.net
jpegxlデコードあんま速くねぇな..jpeg並み軽いとはほど遠い..
670:名無しさん＠お腹いっぱい。
22/06/25 11:57:15.60 EA3s/A9C.net
kritaがjxl試験サポート
671:名無しさん＠お腹いっぱい。
22/06/25 12:23:52.03 PMNTzZhu.net
skiaも早くjxlに対応してほしい
672:名無しさん＠お腹いっぱい。
22/06/25 16:13:33.42 3PWSBLlK.net
paint.netはどうなる？と思って検索したら
libjxl API が安定化したらプラグイン作るとフォーラムに書いてる人がいた
673:名無しさん＠お腹いっぱい。
22/06/25 18:38:24.41 I60AKPug.net
画像編集ソフトに関しては可逆圧縮で保存してからcjxlに通せばいいだけだからどうでもいいけど、>>644みたいなAndroid にも使われてる画像処理ライブラリには迅速に対応してほしいものだね
674:名無しさん＠お腹いっぱい。
22/06/25 19:12:52.13 gUYft+zy.net
>>637
Part2 Edition2
URLﾘﾝｸ(www.iso.org)
675:名無しさん＠お腹いっぱい。
22/06/25 23:25:43.22 fhmb1o2Q.net
>>642
そんなことないと思うけど
URLﾘﾝｸ(cloudinary.com)
Jpegより速い、MP/sはMegapixels/secondの略
こういう統計が出てるけど、きみのはどこ情報なの？
676:名無しさん＠お腹いっぱい。
22/06/26 10:18:10.76 fWx3tOF7.net
djxlはむっちゃ速いよ
677:名無しさん＠お腹いっぱい。
22/06/26 13:37:29.33 QsOfPUT9.net
>>648
自分でlibjxlビルドして、小さなCプログラム書いて画像を読み込んでみた
で、似たようなサイズの画像のjpegやらwebp,pngやらと適当に比較してみた
他がおそらくマルチスレッド対応してなさそうなので、libjxlのマルチスレッド機能は使ってない
djxlはしっかりソース追ってないけど、マルチスレッド有効になってたりしないか?
678:名無しさん＠お腹いっぱい。
22/06/26 14:53:11.25 sWI4m/hn.net
>>650
いやなんでそこ切るんだよ
あとさっきのデータには4コアでやってるって書かれてる
679:名無しさん＠お腹いっぱい。
22/06/26 15:10:38.67 QsOfPUT9.net
え?
jpegxlはだけマルチコア使って速いって主張だったの??
別に他も使えるならご自由に使っていいよって条件かもしれんが
そうだったならびっくり
680:名無しさん＠お腹いっぱい。
22/06/26 15:26:20 sWI4m/hn.net
詳しくは言及されてないけど、実験してみてそうだったならそうなんじゃね？
マルチコア有効化してどうなるかやってみると分かるかもね
681:名無しさん＠お腹いっぱい。
22/06/26 15:34:48.28 Qb+sWK1/.net
今時マルチスレッド使わないという選択肢はない
JPEG XLはわざわざマルチスレッド向きのデータ構造にしてあるんだから
682:名無しさん＠お腹いっぱい。
22/06/26 15:37:37.76 QsOfPUT9.net
jpgxlはビットストリーム自体の仕様見ると、画像をブロックごとのグループに分割して、並列処理できるぽっくなってたから、その場合はマルチスレッド有効にすれば速くなるのはおそらく確かだと思う
俺はそういうの抜きに計量量自体が少ないから速いのかと思ってた
683:名無しさん＠お腹いっぱい。
22/06/26 15:42:51.52 R3qgfFJf.net
他がマルチスレッド対応してないのにずるいぞ！平等に競争だ！ってしたくなる気持ちはまあわからんでもないが…
684:名無しさん＠お腹いっぱい。
22/06/26 16:02:16.36 QsOfPUT9.net
今時、マルチスレッド対応は当たり前で、マルチスレッド対応してないフォーマットでも、画像を複数枚をマルチスレッドで同時にデコードしたりするわけど
そういう場合においてはjpegxl自体が軽いわけじゃないから、jpegxlに変えたところでトータルとしては変わらないってことだよな..
画像1枚だけをデコードする場合はすばらしいということね
元からマルチスレッドで複数枚を同時にデコードするケースでは...
こういうことか
685:名無しさん＠お腹いっぱい。
22/06/26 16:50:52.73 W4q6TiXF.net
複数画像並列読込時こそマルチスレッドとプログレッシブレンダリングが効果を発揮すんじゃないの
686:名無しさん＠お腹いっぱい。
22/06/26 16:58:48.91 H43wP80Q.net
プログレッシブ機能も切ってそう
687:名無しさん＠お腹いっぱい。
22/06/26 17:01:55.14 wEOVLvxd.net
>>650
こんなとこにいないでqiita にでも結果を投稿して思う存分論弁してくれ
688:名無しさん＠お腹いっぱい。
22/06/26 17:14:05.15 EL32E3XT.net
基本的に圧縮率と計算量はトレードオフだからな～
だから皆クッソ難しい並列処理実装の効率化高速化で血反吐はいてるわけで
689:名無しさん＠お腹いっぱい。
22/06/26 18:32:01.30 sWI4m/hn.net
PNGは忘れたしWebPは知らないけどJPEGはブロック単位で圧縮してなかったっけ？
そっちも並列処理できそうな気がするけどライブラリにその機能はないのかね
あるいはできないのか
690:名無しさん＠お腹いっぱい。
22/06/26 21:20:15.96 nWe6ii9z.net
>>657
>元からマルチスレッドで複数枚を同時にデコードするケースでは...
それも試してみたら？
691:名無しさん＠お腹いっぱい。
22/06/27 01:03:28.19 cHpTR68g.net
4枚の画像を1枚毎に4スレッド割り当てて1枚ずつ順番にデコードするならJPEG XLが速いけど
4枚の画像を1枚毎に1スレッド割り当てて4枚同時にデコードするならWebPやAVIFの方が速いってことでしょ
だいぶ前に自分で実験してみたらそうなった
692:名無しさん＠お腹いっぱい。
22/06/27 06:45:43.75 JSoFKEVb.net
結構試してる人いるんだな
デコード関係は全然比較上がってないからどっかで見れたらいいなあ
693:名無しさん＠お腹いっぱい。
22/06/27 06:53:19.08 nbdopuVb.net
この手のチューニングって大体機能が揃ったあとに行われると思うから1.0.0が出るまでは参考程度にしたほうが良さそう
694:名無しさん＠お腹いっぱい。
22/06/27 07:19:40.63 NclpsoX9.net
なんだ、jxlってゴミやん
695:名無しさん＠お腹いっぱい。
22/06/27 07:26:40.25 gTVueh1G.net
対立煽りにしても流石に雑すぎるぞ
696:名無しさん＠お腹いっぱい。
22/06/27 18:32:17.62 QBnvtFMQ.net
MozJpegでエンコードされたjpegファイルを使って
MotionJpegファイルを作ったのですが、
VLCやMPC-BEであれば再生出来たのですが、
WindowsMediaPlayerで再生する事が出来ませんでした。
(エラーとかは出ずに再生時間分黒画面)
WindowsMediaPlayerで再生可能なMozJpeg製MotionJpegを
作る事は出来ないのでしょうか？
697:名無しさん＠お腹いっぱい。
22/06/27 18:40:32.16 vKVnJSw8.net
>>669
スレチ
698:名無しさん＠お腹いっぱい。
22/06/28 13:12:04.44 jFN/IBW9.net
>>670
jpeg関係だからイケるかなと思いましたかダメでしたか
すみませんでした
699:名無しさん＠お腹いっぱい。
22/06/29 08:35:35.68 gBtp6lN1.net
結局圧縮率も高くデコードも早いwebp最強なんだな
700:名無しさん＠お腹いっぱい。
22/06/29 13:14:59.70 OLbkTkr6.net
webpってプロ仕様に耐えられないウンコ野郎じゃないか?
色深度8bitのみ?
lossyはyuv 4:2:0のみ?
701:名無しさん＠お腹いっぱい。
22/06/29 13:19:15.79 OLbkTkr6.net
次世代としてさすがにこれはひどいだろ??
702:名無しさん＠お腹いっぱい。
22/06/30 01:42:24.67 7cKmwTnr.net
web用途ならwebpで十分なんだよなぁ
703:名無しさん＠お腹いっぱい。
22/06/30 03:02:43.27 5oOfT902.net
web用途しかないとも言える
704:名無しさん＠お腹いっぱい。
22/06/30 03:19:46.15 WRBmYdhh.net
ていうかweb用の画像フォーマットを話すスレじゃないからwebpは単純にスレチじゃね
705:名無しさん＠お腹いっぱい。
22/06/30 03:52:42.51 tRdp1AGl.net
web用途に限ればwebpは後継になり得るな
すでに普及してるし
706:名無しさん＠お腹いっぱい。
22/06/30 03:58:49.98 V/CMi3Ak.net
ぶっちゃけweb用途でなければ保存容量を気にしないから、いままでどおり高画質jpegでいいわw
707:名無しさん＠お腹いっぱい。
22/06/30 08:06:47.68 bASb0alX.net
JPEGはビット深度が24 bitしか使えないからダメ
HDRに対応してない
708:名無しさん＠お腹いっぱい。
22/06/30 10:07:43.67 zHUrS9Qz.net
URLﾘﾝｸ(pbs.twimg.com)
709:名無しさん＠お腹いっぱい。
22/06/30 11:34:49.55 Hd/F43Im.net
>>681
よく見るとスピード欄にsingle coreの文字が
流石にこれは嘘や
webpもデコード遅いけどjpegxlと同じくらい
jpeg>png>webp=jpegxl(1コア)
ただ、jpegxlはマルチコア利用すればjpegすら越えられる
710:名無しさん＠お腹いっぱい。
22/06/30 11:43:45.91 Hd/F43Im.net
ハイエンドのiphoneのディスプレイはとっくにDisplay P3だかの広色域になってるのに、それを生かせないのはないだろ
>>681でwide gamutのところ
これからはチャネルあたりの色深度は最低10bitはないと
jpegとwebpは脱落
711:名無しさん＠お腹いっぱい。
22/06/30 11:52:47.88 rOgnvFBp.net
シングルコア=シングルスレッドと勘違いしてそうなキチガイおるw
712:名無しさん＠お腹いっぱい。
22/06/30 11:55:53.90 CEAwaTls.net
>>684
ちがうの？意味は一緒でしょ？
713:名無しさん＠お腹いっぱい。
22/06/30 12:05:45.32 Hd/F43Im.net
厳密には違うけど、このコンテキストそんな細かいこと気にしないだけ
アホがどうでもいいことで騒ぎ立ててるだけ
714:名無しさん＠お腹いっぱい。
22/06/30 19:44:36.57 I+TfL2H/.net
適当に調べてみたけど、
確かにSingleCore 4点は盛りすぎだな
Lossless
WEBP (35.8MP/s)
PNG (30.9MP/s)
JXL1 (17.0MP/s)
JXL2 (32.5MP/s)
JXL4 (64.3MP/s)
JXL8 (99.0MP/s)
Lossy
JPEG (71.8MP/s)
WEBP (32.1MP/s)
JXL1 (29.7MP/s)
JXL2 (58.0MP/s)
JXL4 (112.7MP/s)
JXL8 (195.3MP/s)
GraphicsMagick 1.3.36
djxl v0.6.1 (EFFORT=1)
715:名無しさん＠お腹いっぱい。
22/06/30 23:00:29.22 V/CMi3Ak.net
>>687
さんくす
ソースもあって有能
716:名無しさん＠お腹いっぱい。
22/07/02 09:32:51.41 4/Vzs4fT.net
macOS VenturaとiOS 16でAVIFサポート
URLﾘﾝｸ(github.com)
717:名無しさん＠お腹いっぱい。
22/07/06 17:44:48.36 2auXRy4b.net
>>619
今 63% complete
718:名無しさん＠お腹いっぱい。
22/07/17 16:02:37.47 IZlMn0vD.net
69%
719:名無しさん＠お腹いっぱい。
22/07/19 11:11:15.87 mnCalYMP.net
JPEG XL Part 4 FDIS通過
720:名無しさん＠お腹いっぱい。
22/07/20 04:09:39.88 eawy3up/.net
Part3.4が公開まで行くのとv1.0どっちが先だろう
721:名無しさん＠お腹いっぱい。
22/07/20 12:26:03.23 6dHXRRHv.net
cjxlが大幅改修されとる
722:名無しさん＠お腹いっぱい。
22/08/06 13:28:03 NMWvApou.net
JPEG XL Part 4 IS発行
URLﾘﾝｸ(www.iso.org)
723:名無しさん＠お腹いっぱい。
22/08/09 03:39:09 dgJlNpAv.net
>>542
75%まで来たか
724:名無しさん＠お腹いっぱい。
22/08/10 00:52:30.95 krmK6QEF.net
RC版来た
0.7 release candidate
We expect to have v0.7 release soon.
725:名無しさん＠お腹いっぱい。
22/08/10 05:36:06.70 Le9upN6b.net
え??次は1.0に一気に行くんじゃなくて
0.7リリースすることしたの??
726:名無しさん＠お腹いっぱい。
22/08/10 08:40:38.91 NbnlKfp8.net
libjxlは生真面目にv1.0までのマイルストーン設定してるし飛び級せんやろ
ちなlibwebpはver1.0になるまで8年以上掛かってて
libavifはv0.9.3からv0.10.0に進級してる（現在v0.10.1が最新）
727:名無しさん＠お腹いっぱい。
22/08/10 10:23:05.78 4tm7HQjC.net
この時点で0.7かと思ってた
Bump version to v0.7 (#571)
URLﾘﾝｸ(github.com)
728:名無しさん＠お腹いっぱい。
22/08/11 17:30:47.44 eNkEsXan.net
マイルストーンって1.0しか設定してないやろ
つか、79%になってるな
もうちょいやん
リリースページ見ると0.7.0 Release Candidateがリリースされてるし
突然0.7をぶっこんできた意味がわからん
729:名無しさん＠お腹いっぱい。
22/08/11 17:35:01.53 YJIB9HCQ.net
0.7からcjxlのspeedオプションが変わったんだな
730:名無しさん＠お腹いっぱい。
22/08/11 20:53:37.45 W8eG8Fz6.net
標準化工程が一段落したしそろそろ更新来る頃合いだと思ってたから予定調和だったわ
731:名無しさん＠お腹いっぱい。
22/08/12 19:38:49.17 NuH+jiSn.net
WebPもAVIFもどんな次世代フォーマットも
「可逆圧縮も非可逆圧縮も両方いけます！」ってのが良くないんだよ
ユーザーは拡張子によってその画像が劣化してるのかどうか概ね知りたいんだから
どっちも同じ拡張子じゃ判りにくくて不快なわけよ
だから明確にふたつに分けろって
可逆圧縮（PNG/GIFなど）の後継 .xxx
非可逆圧縮（JPEG）の後継 .yyy
みたいにな
この心理を理解しないと代替りなんて永久に無理だぞ
性能なんて重要じゃねんだわ
732:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
拡張子で分けたらいいんじゃないの
733:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
ごめん昔のレスと混ざってそのまま誤爆した
>>705スルーしていいよ
734:名無しさん＠お腹いっぱい。
22/08/13 01:49:07.03 ptHD9DVe.net
不快かどうかは重要かもな
もうすでに.pngのふりした.webpとかかなりうざいわ＾＾；
735:名無しさん＠お腹いっぱい。
22/08/13 02:13:06.41 VLh/odhZ.net
そんなのあるのか…
736:名無しさん＠お腹いっぱい。
22/08/13 02:34:10.49 vkntbdlw.net
WebPは最強だからしょうがない
737:名無しさん＠お腹いっぱい。
22/08/13 02:45:38.03 oiSdaoJv.net
>>707
保存しようとしてそれだった時の絶望感
738:名無しさん＠お腹いっぱい。
22/08/14 00:54:38.39 wRrdkn8y.net
>>704
個人的には
可逆圧縮.xxx
非可逆圧縮.yyy
とアニメーション画像.zzz の3パ
739:ターン欲しい あんま詳しくないけど同じコーデックの拡張子って後から増やせるのかな
740:名無しさん＠お腹いっぱい。
22/08/18 00:44:25.18 Sh7o8sIa.net
81%
741:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
来月くらいにはワンチャン出るかもってペースなんかねv1.0
742:名無しさん＠お腹いっぱい。
22/08/19 01:36:46.94 RT0TAzud.net
今年中にはおそらく
743:名無しさん＠お腹いっぱい。
22/08/19 11:03:16.98 eyHbW1TR.net
一段落ついたら、ひとまずv0.8が出るのではないかと
744:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
Krita 5.1 Released with JPEG-XL Support, Full WebP Support, PSD Improvements, and More
URLﾘﾝｸ(9to5linux.com)
>“We haven’t yet enabled saving and loading of the HDR color spaces to JPEG-XL, but what we do have is saving and loading animations, making JPEG-XL the first file format that doesn’t require FFmpeg to allow exporting animations,” said the devs.
745:名無しさん＠お腹いっぱい。
22/08/20 07:02:53.15 mEaS0AlN.net
HDRはまだだけどアニメーションには対応してる感じなのね
あんま見たことないけどアニメjxlってサイズはどんなもんなんやろ
746:名無しさん＠お腹いっぱい。
22/08/20 08:30:47.63 MwufuTSa.net
SkiaのJXL対応はよ
747:名無しさん＠お腹いっぱい。
22/08/25 23:35:43.43 Du42fj+G.net
ChromeのJPEG XLについて
URLﾘﾝｸ(bugs.chromium.org)
Adobeの人とintelの人が一眼レフカメラで撮った写真のHDRサポートの為に
ChromeのJPEG XLデコードをフラグ無しで有効にしてよーって書いてる
もう製品レベルの話にしたいんだーみたいなノリ？
748:名無しさん＠お腹いっぱい。
22/08/26 01:34:03.99 juGgp7ou.net
年末までには正式ローンチしそう
749:名無しさん＠お腹いっぱい。
22/08/26 12:00:47.60 0geQH8Rs.net
今のHDR写真はHEIFとか使ってんのかな
750:名無しさん＠お腹いっぱい。
22/08/26 17:14:12.49 /kMkImp4.net
こんな化石みたいなスレが今になって賑わうとはな
751:名無しさん＠お腹いっぱい。
22/08/27 10:50:23.56 +19Mbphj.net
XLって画像表示する時の速度や負荷ってwebpやAVIFよりいいの？
752:名無しさん＠お腹いっぱい。
22/08/27 11:04:55.51 Vz0qXadi.net
libjxl-tiny
URLﾘﾝｸ(github.com)
エンコーダのみ
753:名無しさん＠お腹いっぱい。
22/08/27 11:07:55.31 emb7rBtG.net
>>722
ここ1年で400レスくらい進んでて笑う
てか16年も前に立ったスレなんだなここ…当時の人もういないだろうな
754:名無しさん＠お腹いっぱい。
22/08/27 11:11:03.24 zQc/DIy/.net
JPEG XL Part 3 FDIS通過
755:名無しさん＠お腹いっぱい。
22/08/27 17:18:00.59 120ggfFM.net
>>637見た感じあとpart3だけなんだね
756:名無しさん＠お腹いっぱい。
22/08/28 07:39:08.59 mmPOUDGX.net
Part1
URLﾘﾝｸ(www.iso.org)
Edition2
URLﾘﾝｸ(www.iso.org)
Part2
URLﾘﾝｸ(www.iso.org)
Edition2
URLﾘﾝｸ(www.iso.org)
Part3
URLﾘﾝｸ(www.iso.org)
Part4
URLﾘﾝｸ(www.iso.org)
757:名無しさん＠お腹いっぱい。
22/08/28 09:05:35.47 6T4D2OU4.net
>>719
このチケット、今日も引き続き盛り上がってる
担当者っぽい人もコメントしてる
758:名無しさん＠お腹いっぱい。
22/08/28 11:54:34.15 R7aGgnDd.net
>>401の比較のやつアプデされてるね
最新が2022-08-23になってる、何が変わったのかはわからんけど
759:名無しさん＠お腹いっぱい。
22/08/28 13:21:32.74 LYGOROwY.net
URLﾘﾝｸ(pbs.twimg.com)
URLﾘﾝｸ(pbs.twimg.com)
URLﾘﾝｸ(pbs.twimg.com)
URLﾘﾝｸ(pbs.twimg.com)
URLﾘﾝｸ(pbs.twimg.com)
760:名無しさん＠お腹いっぱい。
22/08/28 13:31:48.10 h9VFeCcC.net
やっぱavifは神だな
761:名無しさん＠お腹いっぱい。
22/08/28 17:05:57.26 xmewU4oA.net
>>719
�
762:ｻの下くらいに名前出てるガーディアンってどっかの新聞だっけ ニュースやってるとこも反応してんだね
763:名無しさん＠お腹いっぱい。
22/08/28 17:18:49.59 3L8tJ6Vk.net
メディアサイトは画像を多用するからね
あとはまあ漫画村みたいなところとかｗ
764:名無しさん＠お腹いっぱい。
22/08/28 18:43:51.41 L7US5+/d.net
ガーディアンの同じ人がFirefoxの同じようなチケットにも書いてるね
8か月前
URLﾘﾝｸ(bugzilla.mozilla.org)
765:名無しさん＠お腹いっぱい。
22/08/29 12:04:06.41 PHUXV7NI.net
>>719
ffmpegのlibjxlラッパー製作者がJPEG XLデコーダの技術的な話を寄稿しとるな
曰くJPEG XLのアルファチャンネルの処理はAVIFよりも余分なオーバーヘッド発生が少なく、WebPやPNGといった既存のフォーマットよりもカラーマネジメントがずっとシンプルになっているとか
766:名無しさん＠お腹いっぱい。
22/08/29 12:22:03.27 3mn8Rxby.net
jxlのexamplesのdecoder_onshotを参考にデコーダー組んだけど、マルチスレッド処理してくれてないっぽいんだよなあ
誰か先駆者いる？toolsのdjxl各種を見るのは億劫なんだ
767:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
>>737
ツイッターに責任者いるからそっちに聞いた方が良いかもよ
日本語でも対応してた記憶
768:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
JxlThreadParallelRunner作ってJxlDecoderSetParallelRunnerでデコーダに渡したら普通に指定した分だけスレッド走るけどな
769:名無しさん＠お腹いっぱい。
22/08/29 15:08:47.06 ZWeVEaSJ.net
examplesを見るとこっちはJxlResizableParallelRunnerを使ってて
スレッド数をJxlResizableParallelRunnerSuggestThreadsで決めてるから
マルチスレッドになるかどうかは画像サイズ依存なんじゃない
770:名無しさん＠お腹いっぱい。
22/08/30 10:44:58.89 XrGuibOA.net
>>724
JPEG XLのHWコーディング用に作られた実装なのかこれ
ゆくゆくはスマホISPとかに搭載されたりするかもな
771:名無しさん＠お腹いっぱい。
22/08/30 17:15:09.80 UKuII12x.net
rust実装のjxl-rsも気になってるけど全然動いとらんな
772:名無しさん＠お腹いっぱい。
22/08/30 20:47:18.27 qW70nplJ.net
今、実装はこんだけあると例のチケットに書いてあるぞ
- J40 is an independent decoder reimplementation from spec (getting close to complete)
- fjxl is a fast lossless-only encoder implementation (complete but only uses a subset of the codec)
- libjxl-tiny is a simplified encoder implementation (forked from libjxl though, so doesn't really count)
- hardware coding is being investigated within the JPEG committee (in fact libjxl-tiny was created for that purpose)
- jxl-rs is an implementation in Rust (very incomplete)
- ffmpeg has its own parser and is considering to do their own implementation (work still needs to start afaik)
773:名無しさん＠お腹いっぱい。
22/08/30 22:21:29.03 1YO0C7y1.net
rustのやつの(very incomplete)ちょっとウケる
なんとかみんな完成してほしいわね
774:名無しさん＠お腹いっぱい。
22/09/03 23:36:03.91 dQ6oqrY6.net
jxlの対応はペイントソフトとかブラウザが優先だろうけど5ch使ってる者としてはimgurも早めに対応してほしいなあ
775:名無しさん＠お腹いっぱい。
22/09/09 02:16:53.44 JT+5pYhr.net
急に動き止まってんだな
iso待ちなんか
776:名無しさん＠お腹いっぱい。
22/09/12 12:24:40.44 j4xde368.net
URLﾘﾝｸ(sneyers.info)
URLﾘﾝｸ(pbs.twimg.com)
777:名無しさん＠お腹いっぱい。
22/09/12 13:10:2
778:6.51 ID:dMqRN2zR.net
779:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
>>747
これjxlはe4で見ても結構悪くないなと思った、早いし
780:名無しさん＠お腹いっぱい。
22/09/12 16:42:14.12 qtrHwAQj.net
>>748
twitterのやつでは？知らんけど
781:名無しさん＠お腹いっぱい。
22/09/14 04:17:06.98 eWcEanDt.net
URLﾘﾝｸ(pbs.twimg.com)
782:名無しさん＠お腹いっぱい。
22/09/15 23:35:11.81 boahk9qe.net
66%に下がっててワロた
783:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
まだまだ先は長いね
784:名無しさん＠お腹いっぱい。
22/09/16 09:38:39.38 OyEl7f9u.net
新しく追加されたissuesで深刻なバグは２つだけだな、すぐに解決する
ほかはドキュメントの整備とか一部環境でのビルドバグとかUnicode問題だけだから早くver1出てほしい
785:名無しさん＠お腹いっぱい。
22/09/20 15:15:34.86 kzK/rRh3.net
Stable Diffusion based Image Compression
URLﾘﾝｸ(matthias-buehlmann.medium.com)
面白い検証
786:名無しさん＠お腹いっぱい。
22/09/20 15:41:43.91 Dr6rOTgY.net
>>755
こういうナチュラルグラデーションはアニメ系の絵にもいいのよね
787:名無しさん＠お腹いっぱい。
22/09/20 16:01:49.22 tkpmwLJx.net
J40: Independent, self-contained JPEG XL decoder
URLﾘﾝｸ(news.ycombinator.com)
作者によると製作期間4ヶ月、うち主要な機能 (モジュラーとVarDCT) が機能するようになるまでに1, 2ヶ月かかったと。将来的にはRust版も構想してる模様
788:名無しさん＠お腹いっぱい。
22/09/20 16:26:05.39 kz9s5QXJ.net
>>757
パブリックドメインライセンスなんだw
URLﾘﾝｸ(github.com)
789:名無しさん＠お腹いっぱい。
22/09/20 16:26:27.93 kz9s5QXJ.net
URLﾘﾝｸ(github.com)
790:名無しさん＠お腹いっぱい。
22/09/20 22:32:49.70 Xd96gWwe.net
>>755
これXLが一番ファイルサイズ小さくて綺麗なのか？
デコード速度も一番早く軽いのか？
791:名無しさん＠お腹いっぱい。
22/09/21 03:56:45.12 GF7MlDUA.net
>>757
rust版いいね
頑張ってほしい
792:名無しさん＠お腹いっぱい。
22/09/21 03:58:34.08 MJJuBm0H.net
>>760
お絵かきAIの圧縮をjpeg.webpと比較してる記事だからJXL関係無いと思うよ
793:名無しさん＠お腹いっぱい。
22/09/22 02:25:52.73 DHC+4VNx.net
libjxl v0.7.0 リリースされたよ
Windows版バイナリもリリースページから落とせる
794:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
URLﾘﾝｸ(twitter.com)
>数日前、libjxlのバージョン0.7がリリースされました
APIの他のいくつかの側面が改善、変更、または廃止となった。0.7 APIの廃止されていない部分はすべて、1.0 APIに残ると見込まれる。今回のリリースは主に1.0に向けた準備段階として機能し、1.0より前の最後のリリースとなる可能性が高い。今こそソフトウェアにjxlサポートを追加する良い機会だ！
(deleted an unsolicited ad)
795:名無しさん＠お腹いっぱい。
22/09/29 18:29:11.13 WGI2geG3.net
ブラウザもデフォでサポートしてくれねえかなあ
それだけで結構変わりそうなもんだけど
796:名無しさん＠お腹いっぱい。
22/09/29 19:33:39.12 mJzfJUqF.net
FirefoxもChromeもconfigなりflagsなりのスイッチ切り替えるだけだと思うが
797:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
>>766
edgeもだね
そこの設定触る必要無くなってほしい的な話じゃないかな
798:名無しさん＠お腹いっぱい。
22/10/03 15:16:22.82 Y0OdL5wk.net
JPEG XL Part 3 IS発行
URLﾘﾝｸ(www.iso.org)
799:名無しさん＠お腹いっぱい。
22/10/03 16:52:59.77 mBCrR86o.net
あとはv1.0かー
800:名無しさん＠お腹いっぱい。
22/10/10 23:06:17.38 TlHGS6GF.net
WordPress、アップロードされたJPEG画像をWebpに自動変換する機能先送り
URLﾘﾝｸ(news.mynavi.jp)
>時期尚早というのが現時点で優勢な意見
寧ろ遅きに失した感あるような
801:名無しさん＠お腹いっぱい。
22/10/13 10:34:56.74 d4ZkLrYZ.net
普及率的に一番マシなフォーマットってWebP？
AVIFも割と期待持てそうだよな
公開用なら徐々に移行してもいいかな
解像度インフレしてんのに未だJPEGは辛い
なのに他の後継フォーマットは揃いも揃って普及率クソザコナメクジばっかだったしなあ
802:名無しさん＠お腹いっぱい。
22/10/13 12:45:32.47 8Tg6lI6E.net
普及率的に一番マシなフォーマットならJPEGかPNGとしか
803:名無しさん＠お腹いっぱい。
22/10/13 13:12:00.95 3I6QJScP.net
オンライン用途ならwebp一択だろ
jxlがブラウザで設定無しに見れるようになればjxl一択
804:名無しさん＠お腹いっぱい。
22/10/13 13:13:20.81 3I6QJScP.net
普及率なんざ、ブラウザが対応してれば画像は見れるんだから考えなくていい
805:名無しさん＠お腹いっぱい。
22/10/13 13:21:35.06 d4ZkLrYZ.net
年々画質が上がってんのにJPEGやPNGがクソ重いから公開用だけでなく保存用もマシなフォーマットへ再圧縮かけれないかと思ったんだけど
普及してないナメクジどもは色んなソフトやサイトから見向きもされず未対応ばっかで何かと困るからなあ
やっとこWebPやAVIFが普及へ近づいてるかな？ってレベルよね
まぁ暫くJPEG PNG ド安定なんだろーけど（泣）
806:名無しさん＠お腹いっぱい。
22/10/13 15:01:46.02 k4Q9tlXR.net
なんだ煽り厨か返信して損した
807:名無しさん＠お腹いっぱい。
22/10/13 15:42:14.82 d4ZkLrYZ.net
事実を並べただけで煽りに見えるのかぁ…（困惑）
どれも期待してたのに結局JPEGを打ち崩すどころか殆ど見向きもされなかったナメクジっぷりに落胆もしますよ……
というかこのスレみてJPEG XLの存在始めて知った
何でもいいから普及進んでほしいわね
技術はあるのに特許だの規格争いだの人間ども足引っ張り合いすぎだろ
808:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
メジャーブラウザでサポートされているならもう普及していると言っていい
可逆なWebPはもはやためらいなく使えるしavif,JPEG XLもいずれはそうなるだろう
heicはちょっと怪しいが
809:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
avif系はエンコードが遅すぎて無理
810:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
遅すぎってことはないよ
最新のlibaom使えばjxlと遜色ない程度にはなってる
811:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
>>778
ブラウザサポートだけで普及云々言ってるから中途半端なコーデック増えたんじゃないの
812:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
5年後くらいにはWebの画像もカメラの画像もスクショもJXLになってると良いなあ
813:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
JXLに期待が集まってるが
まず先発のWebPやAVIFが今後どれだけJPEGを切り崩せるか
814:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
WebPとAVIFはもう退場していいよ
815:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
またどこぞの大手が対応渋って総崩れにならないといいがなｗ
816:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
webpは10年経ってこれなんだからもう眠らせてやれ
実質avifとjpeg xlの一騎打ちでしょ
817:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
Crusheeって変換ソフト使ってPNGやJPGをAVIF変換試してるけどめっちゃサイズ潰れるな
だが圧縮処理が凄まじい高負荷で遅い
JXLが熱望されるのもまぁまぁ分かるな
818:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
AV1はAV1で応援してるけどな
AVIFは…JPEG XLで良い�
819:謔ﾈぁ
820:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
そういやJPEG XLはアニメーションもサポートしてるはずだけどこっちは流行る未来が見えないわ
APNGの二の舞いになりそう（対応ソフトが少ない、それ動画でよくねになる）
821:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
JPEG XLが普及してアニメーションとして使われるようになっても
一般人からはGIFと呼ばれ続ける未来が見えるわ
822:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
libaoeもrav1eも画像エンコード遅すぎて無理
823:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
アニメーションgifで駄目って局面がほとんどないからなあ
10秒以上は普通は動画ファイルだし
824:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
AVIFやHEICのエンコードはほぼハードウェアエンコーダとセットやろ
825:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
つーかデコード遅い方がどうにかしてほしいわ
連続で何枚か見ようとすると多少高解像度なだけで本気でイライラする遅さ
エンコードは放置でいいから大して気にならないけどデコードはそうはいかん
826:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
avifの利点は皆無>>566
827:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
>>792
10秒以上は動画ファイルってのは同意だけど単純にGIFは画質がきつくない？
828:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
パワポが永遠にアニメ画像をgifしか採用しないせいだな
829:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
jpegxlのデメリットがOS,ブラウザ等の各プラットフォームにデフォルト非対応のみだから、はやく対応してほしい
Googleさん頼むよ、、
830:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
v1.0を待ていって感じなんだろうな
831:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
JPEG XL は JPEG XR（）に名前が似すぎているのが問題だと思う
割とマジで
832:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
ロイヤリティーのせいで産廃と化したHEIFも埋葬されてほしいけどAppleが暫くはしがみつくんだろうなあ
833:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
>>800
同名じゃないだけマシ
834:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
XRの認知度ほぼ0だからセーフ
835:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
avifをwebp並に普及してるように印象操作してるバカがいるけど
ブラウザでも全然対応せずドマイナーフォーマットでしかないからな
836:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
拡張子が.avifなのに中身はHEIFのファイルに何度遭遇したことか
837:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
>>804
そら4年のavifと10年のwebpならサポートに差はあるでしょ…
てかvp8の派生のwebpからしたらvp10を取り込んだav1の派生のavifは後継みたいなもんじゃないの
838:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
>>804
Chrome、Firefoxが既に対応してて
Safariも既にテスト段階だから主要ブラウザ全対応までもうすぐだよ
ChromiumなEdgeも後追いですぐ対応するだろうし
URLﾘﾝｸ(caniuse.com)
839:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
というかロイヤリティーフリーなんだから各社適当に最新版へぶっ込めば済む話なのでは
何を渋ってるのか分からん
840:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
まあぶっこむのにも手間かかるし何よりバグがね…時間かかるのはしゃーない
ただappleは流石に遅すぎるだろって思っちゃうわ、自前のosで固めてる割に
841:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
libjxlがイマイチこなれてないから今製品版に入れると脆弱性になってしまう
最近の奴だと、abort()が入ってるせいで変なデータ喰わせるとプロセス自体が終了してしまうとか
842:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
>>810
そりゃ不味いな
843:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
cppだとabortをcatchする手段は無いんだっけ？
844:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
シグナルハンドラ登録すりゃいけるかもしれんけどあろうがなかろうがabort呼ばれたら�
845:怩ﾍキツイわ
846:名無しさん＠お腹いっぱい。
22/10/20 00:16:58.60 RwkzKL9r.net
Adobe Camera RawでHDR写真をJXLで保存できるようになったらしい
URLﾘﾝｸ(helpx.adobe.com)
847:名無しさん＠お腹いっぱい。
22/10/20 09:50:03.97 3yKT67EC.net
>>814
「テクノロジープレビュー機能」とは書いてあるが、割と快挙では？
この分野でのAdobeの影響力は大きい
848:名無しさん＠お腹いっぱい。
22/10/20 13:38:57.88 EIR8mBEa.net
素晴らしい
今までの写真も現像し直そう
849:名無しさん＠お腹いっぱい。
22/10/20 13:49:30.81 iemEkEKm.net
encodeは問題なさそうね
decodeのバグの個数が報告済のやつだけでも割とあってつらい
850:名無しさん＠お腹いっぱい。
22/10/21 16:24:27.76 odSTGoZL.net
つくる方は対応増えてきてるけど見る方はまだだったりするのもどかしい
851:名無しさん＠お腹いっぱい。
22/10/22 10:36:33.30 iKSDDd3t.net
WindowsとAndroidとChromeがデフォで対応してくれれば嬉しい
852:名無しさん＠お腹いっぱい。
22/10/22 10:51:40.69 oqT7PXRl.net
Windows 10は既にHDR写真をJPEG XRで保存するようになってるんだよね
JPEG XRで実装済みの機能をJXLに切り替えてもらうのは難しいかも
URLﾘﾝｸ(zenn.dev)
> Xbox Game Bar (Win + G で表示される) に静止画キャプチャ機能があり、これでキャプチャすると任意のウィンドウの映像をクリップボードではなく PNG ファイルとして直接ファイルに出力します。また、 HDR 出力になっているディスプレイ上のウィンドウは PNG に加えて JPEG XR (.jxr) ファイルにも出力されます。
853:名無しさん＠お腹いっぱい。
22/10/22 13:56:37.01 91gtucs3.net
chromeだとフラグをオンにするだけで
普通にWebサイト上のHDRのJXL画像を表示できるんだね
HDRオフでも普通のjpeg写真みたいに違和感無く表示されるし
環境としては非常に土台が整ってはいるんだけど
ちょっとやそっとじゃ完全普及はしないんだろうなぁ…
854:名無しさん＠お腹いっぱい。
22/10/22 14:09:56.89 TOEdWOTl.net
例えばYouTubeの保存サムネイルがjxlとかにでもならない限り普及しましぇん
855:名無しさん＠お腹いっぱい。
22/10/22 15:17:38.48 1OnYGiJ9.net
>>820
この辺とかandroid iOSのスクショ機能がjxlになればかなり普及してると言えると思うけど当然表示する方もOSから対応しないといけないからサポートするのもかなり先のことだろうなあ
856:名無しさん＠お腹いっぱい。
22/10/22 15:24:49.57 5qxx31Vi.net
まーた一部の大手企業が自社規格じゃない儲けがないヤダヤダヤダ～って対応渋るんだろうな～
まったく人間同士で足を引っ張り合いやがって
まるで学習していない……
857:名無しさん＠お腹いっぱい。
22/10/23 20:22:07.81 lI09m//m.net
いざスマホで写真撮ると画質インフレでガッツリ容量食ってビビる
はやくJPEGをリプレースしてほしいわ
もはやJPEGによる資源浪費と環境破壊ヤバいんでないの
858:名無しさん＠お腹いっぱい。
22/10/23 22:33:11.62 M9wh2Cwq.net
非可逆圧縮でhdr対応でavif,heif以外の画像フォーマット、つまりjpegxlはよ頼む
859:名無しさん＠お腹いっぱい。
22/10/29 20:47:38.62 3/eUkvws.net
企業に儲けるなって言う人、働いてなさそうだよな
働いてたとしても給与もらう資格がないレベルのアホ
慈善活動じゃねーのにな
860:名無しさん＠お腹いっぱい。
22/10/29 21:19:59.77 0KJR2SYZ.net
JPEG XL 形式は、Chrome 110 リリースで非推奨になります。
URLﾘﾝｸ(www.phor)
861:onix.com/news/Chrome-Deprecating-JPEG-XL
862:名無しさん＠お腹いっぱい。
22/10/29 21:47:07.57 CN65PrAI.net
libjxlのAPI周りが固まったから中途半端だったテスト実装を削除して本格的に作り直すんでしょ
やる気が感じられて嬉しいな
863:名無しさん＠お腹いっぱい。
22/10/29 22:29:17.82 TPiAhmIh.net
2011年2月Chrome 9でWebPサポート
2011年10月Android 4.0でWebPサポート
2020年8月Chrome 85でAVIFサポート
2021年10月Android 12でAVIFサポート
来年2月頃までChromeでJPEG XLサポートされたらAndroid 14でJPEG XLサポート来るかも？
逆にChromeが8月以降に遅れたらAndroid 15に持ち越しになりそう
864:名無しさん＠お腹いっぱい。
22/10/29 23:05:00.25 xA/xsnBH.net
ググったらChrome 110は2023年2月7日リリース予定らしい
およそ2ヶ月先の話やね。どうなることやら
ちなそのChrome 110でWindows 7/8.1がサポート終了するのでワンチャン大型アップデート説あるで
865:名無しさん＠お腹いっぱい。
22/10/29 23:59:59.14 vbazmp97.net
>>827
そうは言うがそもそも流行らなくて廃れたら元も子も存在価値も収益源もないゾ
866:名無しさん＠お腹いっぱい。
22/10/30 07:31:27.20 cCKI75ah.net
>>828
ここのブログのコメント欄を見てると、Googleは自社のWebPを展開していきたいらしいぞ
Microsoftの息のかかったJpegXLではなく
867:名無しさん＠お腹いっぱい。
22/10/30 07:34:43.84 cCKI75ah.net
URLﾘﾝｸ(jpegxl.io)
このANS特許問題のせいでJpegXLが将来ロイヤルフリーでなくなる可能性がある
868:名無しさん＠お腹いっぱい。
22/10/30 07:38:58.21 jB4vx5Vt.net
まぁまだ緊急課題でもないしJPEG使い続けたらいいんじゃないすかね（白目）（鼻ホジ）
869:名無しさん＠お腹いっぱい。
22/10/30 11:09:20.57 +mbce1B0.net
Phoronixのコメント欄はYahooニュースに毛が生えた程度の民度だからあまり気にすんな
5chの方がまだマシなレベル
870:名無しさん＠お腹いっぱい。
22/10/30 14:33:00.17 eUKq0Hb5.net
Googleが邪悪に染まり切っていないことを祈る
頼むぞGoogleはん…！
871:名無しさん＠お腹いっぱい。
22/10/30 15:10:09.13 8KeVlgB7.net
どうせlibjxl実装に見過ごせない抜け穴バグが見つかったとかなんじゃねえの
つべこべ言ってねえでさっさとlibjxl 1.0完成させろやオラァ！
872:名無しさん＠お腹いっぱい。
22/10/30 17:18:14.88 chNX91R8.net
>>838
これだよな
期待してるんだから1.0頑張ってくれ
873:名無しさん＠お腹いっぱい。
22/10/30 17:26:00.78 n7ju05xw.net
急かしても碌なことはない
874:名無しさん＠お腹いっぱい。
22/10/30 17:31:03.79 Y9vn8uYh.net
JPEGをぶっ壊す
875:名無しさん＠お腹いっぱい。
22/10/31 06:16:57.62 efSx2wvw.net
webp2の扱いも今はこんなだな
>WebP 2 will not be released as an image format
>but is used as a playground for image compression experiments.
URLﾘﾝｸ(chromium.googlesource.com)
876:名無しさん＠お腹いっぱい。
22/10/31 08:10:21.83 ZT2qXWdc.net
大してやる気なさそうだな
877:名無しさん＠お腹いっぱい。
22/10/31 08:58:41.20 BRp1TMyh.net
URLﾘﾝｸ(bugs.chromium.org)
皆様には、JPEG XL に関するご意見・ご感想をいただき、ありがとうございました。以下の理由により、JPEG XLのコードとフラグをChromiumから削除することになりました。
- 実験的なフラグやコードを無期限に残すべきではありません。
- エコシステム全体から、JPEG XL の実験を継続するための十分な関心が得られていない。
- この新しい画像フォーマットは、既存のフォーマットと比較して、デフォルトで有効にすることを正当化するほどの十分な利点をもたらしません。
- M110のフラグとコードを削除することで、メンテナンスの負�
878:Sを軽減し、Chromeの既存のフォーマットの改善に集中することができます。
879:名無しさん＠お腹いっぱい。
22/10/31 09:19:19.31 nxBJavVw.net
>>844
メンテナンスって、、😅 お前らブラウザはlibjxlのラッパーを書くだけだろ
「デフォルトで有効にする十分な利点がない」参考文献も検証も示さずに何言うてんねん
誰がこの説明で納得するんだろうか
880:名無しさん＠お腹いっぱい。
22/10/31 09:23:17.80 lzFihJLy.net
abort問題のようなセキュリティ的脆弱性がある、みたいに言えばいいのにね
これ書いたのavif信者だろ
881:名無しさん＠お腹いっぱい。
22/10/31 09:30:34.37 Jc5Jc5LN.net
どうせ利権問題やな
882:名無しさん＠お腹いっぱい。
22/10/31 09:41:01.43 i8gxbvJH.net
1.0が見えてきたのに実験的とはどういうことなのか
883:名無しさん＠お腹いっぱい。
22/10/31 09:42:57.82 19tjyeTz.net
足を引っ張り合う愚かな人類案件ですか？
884:名無しさん＠お腹いっぱい。
22/10/31 12:04:43.56 7C3/+X2p.net
>>845
よくある勘違いをしているなw
885:名無しさん＠お腹いっぱい。
22/10/31 12:14:06.43 NwCSoRKb.net
Android開発チームは違う見解だと信じたい
例えChromeで非推奨化されようが俺はAndroid14でのJPEG XLネイティブサポートに一縷の望みを掛けるぜ！
886:名無しさん＠お腹いっぱい。
22/10/31 12:38:22.35 nfhE56r5.net
libjxl側がNDKツールチェーンでstaticビルドできない問題を触れてはいけないもののようにずっと放置してるから、永遠に泥実装はされないよ
887:名無しさん＠お腹いっぱい。
22/10/31 12:41:02.33 a1hSjPrX.net
URLﾘﾝｸ(bugs.chromium.org)
おっ考え直せっていうコメントが殺到しまくってるぞｗ
民意の力で覆せ！
888:名無しさん＠お腹いっぱい。
22/10/31 12:47:45.41 +c7HP57M.net
ここからChromeさんにはそもそもlibjxlがバグを放置し過ぎだの進捗が遅いだの逆ギレムーブをかましてほしい
そしたら矛先がlibjxl側に向かってチンタラやってる開発者のケツにも火がつくだろう