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側に向かってチンタラやってる開発者のケツにも火がつくだろう
889:名無しさん＠お腹いっぱい。
22/10/31 12:48:00.22 rBzIW6QZ.net
>>845
chromiumはラッパーすら書いてないよ笑
ffmpegのjpegxlデコーダーを使ってるだけ
890:名無しさん＠お腹いっぱい。
22/10/31 12:55:15.30 kmmzIiBH.net
libjxlは根幹が純グーグルのbrotliやhighwayの、ほぼグーグル開発のライブラリだってのになんで仲間割れが起きてんだ
891:名無しさん＠お腹いっぱい。
22/10/31 12:56:35.23 2N1B05BK.net
あれじゃないの？自分はjxlを完全対応させられなかったので、腹いせに機能ごと消してしまおう的な？
892:名無しさん＠お腹いっぱい。
22/10/31 13:06:15.20 oF6MgdJC.net
>>853
>私たちの多くはJPEG-XLが非推奨であることをPhoronixの記事から知りました。あなたの会社の会社のためにJPEG XL開発にここ数年を費やしてきたGoogleのエンジニアが「Twitterで共有されたPhoronixの記事」によって自身の仕事が採用されない可能性が高いことを知ることを想像できますか? ましてや非常に曖昧な言葉でその理由が自分たちの仕事が十分な進捗と業界の関心を得られなかったからだと非常に短い更新で告げられるなんて。
心情に訴えるのはええ作戦やなｗ
893:名無しさん＠お腹いっぱい。
22/10/31 16:48:33.75 JedRT4bd.net
件のチケットにマジギレしてる人がいるな
ジョンも性能に問題あるというなら計測結果出してみ？とか書いてるし
894:名無しさん＠お腹いっぱい。
22/10/31 18:21:14.17 7USNLWq9.net
こういうのの対応って誰が決めてるんだろう
Chromiumのプロマネとかかな
895:名無しさん＠お腹いっぱい。
22/10/31 20:35:03.25 hYqNwnF+.net
>>857
JPEG XL設計者のスナイアーズ氏はlibjxlのセキュリティ性能やChromeの実装状態については問題なかったと
896:言ってるな https://twitter.com/jonsneyers/status/1587019540755611648 >To be honest, I don't think software development/maintenance is the real issue here. Libjxl as it is now is quite robust, and the Chrome integration of it is quite complete (including animation, HDR, progressive decode, etc) and does not really require additional work. (deleted an unsolicited ad)
897:名無しさん＠お腹いっぱい。
22/10/31 21:07:56.95 /ypMZpJ6.net
>>861
マイルストーン見るとやばいのが結構あるよ
898:名無しさん＠お腹いっぱい。
22/10/31 21:18:23.61 j8/wpw46.net
廃止コミットしたやつAV1/AVIFの開発者らしいｗ
でもそいつがどのコーデック/フォーマットをサポートするかの影響力がありそうな人物でもあるっぽい
899:名無しさん＠お腹いっぱい。
22/10/31 21:18:36.29 hYqNwnF+.net
スナイアーズ氏曰く、今回の意思決定者はChromeコーデックリーダーで、VP8/WebPの立役者かつAV1/AVIFにも深く関わっている人物だそうだ
一応名は伏せるが流石に陰謀論的というか被害妄想が過ぎるんじゃないかなと思う知らんけど
900:名無しさん＠お腹いっぱい。
22/10/31 21:21:15.37 hYqNwnF+.net
被ったｗ
真相はChromeにはフラグ状態を2年以上キープ出来ないという不文律があるとかそんなしょうもない理由だったら笑えるんだがなｗ
901:名無しさん＠お腹いっぱい。
22/10/31 21:33:53.51 5qNzbnlt.net
avifのなにがイヤかって、中身がheifやheicのavifがネットで大量に散布されててdav1dでデコードできないものがあること
ライセンス的にGPL3のlibde265を開発に組み込めないから開発者泣かせでマジむかつく
902:名無しさん＠お腹いっぱい。
22/10/31 21:35:31.65 5qNzbnlt.net
中身はheifのavifを読み込めない読み込めない言われても知らんて
マジavif死滅しろ
903:名無しさん＠お腹いっぱい。
22/10/31 21:47:51.92 SBqBLQON.net
中身はheifってAVIFはHEIFコンテナだぞ
904:名無しさん＠お腹いっぱい。
22/10/31 21:56:16.27 bkp3huqh.net
>>863-864
ググったらそいつOn2 Technologiesの元CTOらしくてかなりの権力者っぽいぞｗ
905:名無しさん＠お腹いっぱい。
22/10/31 21:58:12.18 lzFihJLy.net
ロイヤルフリーのHEIFのデコーダーほしいな
906:名無しさん＠お腹いっぱい。
22/10/31 21:59:16.19 lzFihJLy.net
結局利権争いみたいなことになったか
907:名無しさん＠お腹いっぱい。
22/10/31 22:07:28.26 R2WUaoxk.net
avifがjpegxlに本質的に劣ってるのがchromeコーデックリーダーさんは分かってるから強硬手段に出たわけだ
いくら優れていようと流行らなければ使われないってこった
908:名無しさん＠お腹いっぱい。
22/10/31 22:22:05.42 ZvPxUrrW.net
かつてAV1コーデックもJPEG XL規格策定前の技術公募に立候補していたようだが、そこでAV1が採用されていれば全て丸く収まっていた可能性が・・・？
しかしPik+FUIFに機能的に劣ると判断されて選考落ちしたこの世が現実である
909:名無しさん＠お腹いっぱい。
22/10/31 22:33:26.88 4Te5UVw7.net
>>872
といっても現状は本質での勝負どころか大した説明も無く権力で捻じ伏せてるだけでこんなんただのパワハラですやん
せめてロジハラしてクレメンス
910:名無しさん＠お腹いっぱい。
22/10/31 22:40:39.21 xcOs8rPq.net
AVIFってそもそもデコード遅いし負荷も大きいんだろ？
そもそもそんなの誰も使わねえよ
911:名無しさん＠お腹いっぱい。
22/10/31 22:50:33.70 nBLQl1Do.net
使われるかどうかは検索エンジン最適化の扱い次第かな
912:名無しさん＠お腹いっぱい。
22/10/31 22:59:04.34 FlOOQ7hG.net
10年前のWebPvsAPNG規格対立も件の元CTO氏が暗躍してたのかな
最終的にAPNGもChromeでサポートされたしJPEG XLもいつかはサポートされるでしょ
まあしかし、APNG全然普及しなかったな笑
913:名無しさん＠お腹いっぱい。
22/10/31 23:07:01.09 Z
914:nXIlB7J.net
915:名無しさん＠お腹いっぱい。
22/10/31 23:09:45.74 ZnXIlB7J.net
色んな新技術が開発されてんのに人類の権力争いで未だに何も浸透してないのホンマにザ・愚かな人類すぎて溜息が出ますねえ
916:名無しさん＠お腹いっぱい。
22/10/31 23:11:51.44 ZnXIlB7J.net
これでWebP2()もJPEG XLも共倒れになったら草々の大草原ですわぁ～www
😇😇😇
917:名無しさん＠お腹いっぱい。
22/10/31 23:21:21.47 nBLQl1Do.net
Webp2は既に画像フォーマットとしてリリースしないと明言してる
918:名無しさん＠お腹いっぱい。
22/10/31 23:35:25.27 rMAsHKdT.net
陰謀論に飛びつくのはまだ早すぎる
919:名無しさん＠お腹いっぱい。
22/10/31 23:51:38.31 knZd6hry.net
禿同。スナイアーズ氏も感情的になって関係各所と社会的信頼失いそうな扇動紛いの言動やっててヒヤヒヤするわ
でもまあChrome側もセキュリティ上の問題とか無難な回答しときゃよかったのに
あんな回答じゃもやり場のない怒りを誰かにぶつけたくなる気持ちは分かんでもない
920:名無しさん＠お腹いっぱい。
22/11/01 00:31:17.35 xvY2qpOP.net
何か技術的な課題を提示して今のお前は時期尚早だ出直して来いって突っ放せば格好良かったな
怒りより向上心が沸き立つ少年漫画的展開も有り得た
921:名無しさん＠お腹いっぱい。
22/11/01 06:29:22.50 IH+CzEDQ.net
ちょうど延期したMV3切り替えに合わせて、Firefoxでjxlが正式に使えるようになって、
数パーセントユーザーが流れてから、こんなもん大したことあらへんとか呟きながら
渋々実装する絵が見えるわ
922:名無しさん＠お腹いっぱい。
22/11/03 13:00:03.55 gCy3vBKK.net
ギガジンがJPEGXLの可逆圧縮性能を評価してるけど、JPEGXLって可逆圧縮用途がメインなん？非可逆圧縮は微妙なんか？
Google Chromeが次世代画像規格「JPEG XL」形式のサポート廃止を検討、その理由とは？
URLﾘﾝｸ(gigazine.net)
923:名無しさん＠お腹いっぱい。
22/11/03 13:48:46.31 d3U6yYbP.net
>>886
ただのエアプ記事やん
ギガジン………
924:名無しさん＠お腹いっぱい。
22/11/03 14:59:15.82 Ln74D76m.net
Sneyers氏が冷静さを取り戻して会社のblogに反論をまとめた
URLﾘﾝｸ(cloudinary.com)
925:名無しさん＠お腹いっぱい。
22/11/03 15:24:24.35 uizws9YV.net
>>888
ワイ結論、webpでよくね？
926:名無しさん＠お腹いっぱい。
22/11/03 15:35:41.87 8hRGe35Q.net
個々の性能では各フォーマットに劣るけど、総合的な相互運用性の視点ではjxlが優位ってことか>>888
927:名無しさん＠お腹いっぱい。
22/11/03 15:46:32.72 MTldvCr5.net
ロスレス JPEG 再圧縮
→avifで可逆圧縮すればいい
プログレッシブデコード
→4G5G環境で必要なし
無損失圧縮性能
→avifとほぼ同等
非可逆圧縮のパフォーマンス
→avifとほぼ同等
展開可能なエンコーダ
→普及してないからサード開発者が採用しない
ワークフロー全体で機能
→個々のサードライブラリを組み合わせるので問題なし
あれ？jxlのメリットどこ？
928:名無しさん＠お腹いっぱい。
22/11/03 15:48:18.86 WcRUEhWa.net
>>887
もっと酷いのもあるぞ。Googleは自社規格webp2を推進したいからとか出鱈目書いてるクソ記事
日本のWebライターもこれくらい調べて記事書けよな
Chrome Banishes Photo Format That Could Save Space on Your Phone
URLﾘﾝｸ(www.cnet.com)
929:名無しさん＠お腹いっぱい。
22/11/03 15:49:48.76 6np5RBPd.net
むしろMS特許問題のせいでJPEGXL組み込みへの採用にはリスクしかないよ
930:名無しさん＠お腹いっぱい。
22/11/03 15:53:32.93 5bg56cfP.net
>>889
webpはHDR写真無理だから、2も出ないし
avifと被ってて特許が不穏なのがjxlの弱み
931:名無しさん＠お腹いっぱい。
22/11/03 15:55:17.38 1cTJX5sw.net
it系のwebライターは直接取材しないでネタを盗んでコピペするだけのゴミ
932:名無しさん＠お腹いっぱい。
22/11/03 15:56:26.59 1cTJX5sw.net
>>894
お前chromeでHDR画像みるの？みないでしょ
933:名無しさん＠お腹いっぱい。
22/11/03 15:58:59.28 f2qqr3N9.net
chrome画像を見るぶんにはjpegやpngに次いで最速のwebpでおけ
934:名無しさん＠お腹いっぱい。
22/11/03 16:03:22.12 5bg56cfP.net
>>896
見る見ないは人の環境によるでしょ…
あった方がいいって話よ
935:名無しさん＠お腹いっぱい。
22/11/03 16:05:52.61 pVr1cPmM.net
ロスレスJPEG再圧縮はAVIFの可逆圧縮で代用できるようなもんじゃないぞ
936:名無しさん＠お腹いっぱい。
22/11/03 16:09:19.70 5bg56cfP.net
アップルはいつも対応遅いから反応なくてもどうでもいいけどmsが何も言わんのが気になるjxlのことどう思ってるんだろう
937:名無しさん＠お腹いっぱい。
22/11/03 16:10:18.56 uA8HGLfp.net
>>893-894
ゆうてAV1/AVIFもHEVC陣営の特許管理会社が勝手にライセンス契約プログラム発表して特許料請求してきてたやん？
あれどうなったんやろか
938:名無しさん＠お腹いっぱい。
22/11/03 16:16:59.57 TOGB/wfh.net
結局利権争いになるから、組み込み開発者にとっては完全ロイヤルフリーのjpegが一番使いやすい問題
939:名無しさん＠お腹いっぱい。
22/11/03 16:19:36.06 mXTjIOw/.net
>>900
ms「ver1完成後にライセンス料吹っかけて総横取りしたほうがええやろ？」
940:名無しさん＠お腹いっぱい。
22/11/03 16:23:56.18 vJ3UcR2v.net
>>900
MSは十数年前に自社規格を国際標準化して普及させようと頑張ってた先駆者だからな…VC-1然りJPEG XR然り
正直後発のAV1やJPEG XLに対して複雑な心境なんじゃないかな…
941:名無しさん＠お腹いっぱい。
22/11/03 16:36:35.89 JJ+9dLvG.net
msはIEや純edgeを捨ててchromiumを採用してプライドズタボロやから、なにか言う気力がないんじゃないか？笑
942:名無しさん＠お腹いっぱい。
22/11/03 16:51:40.25 L1Mmzecy.net
JPEG XL陣営が書いたテキストだけど、これがわかりやすい？
AVIFはAOM陣営？
URLﾘﾝｸ(cloudinary.com)
943:名無しさん＠お腹いっぱい。
22/11/03 17:02:19.90 ajXIkNyA.net
>>888
こんなjpegxl自体の長所短所はわかってるから、マイクロソフトの取得した特許による影響の方を書いてほしかった
944:名無しさん＠お腹いっぱい。
22/11/03 17:02:30.94 AwQbqS8K.net
>>890
むしろ性能的に優れてるって反論なのだけど
なんで個々の性能では各フォーマットに劣るなんて要約になったの
945:名無しさん＠お腹いっぱい。
22/11/03 17:24:04.58 e0QQx/8p.net
>>907
その記事の趣旨は、JPEG XLが他のフォーマットと比較してデフォルトで有効化するほど利点があるわけではない、に対する反論だから
ちなみにChrome開発チームは特許関係は問題に上げていない
946:名無しさん＠お腹いっぱい。
22/11/03 17:27:39.16 uYzpSWPF.net
ChromeでJXLサポート削除は決まってそうだから、Chrome運営がどんな反論するか楽しみだ、単に無視で押し通して来そうだけど
947:名無しさん＠お腹いっぱい。
22/11/03 17:30:19.02 uYzpSWPF.net
邪魔なJpegXLを排除するために、上っ面だけの公言できる削除理由を作った感じが見え透いてる
948:名無しさん＠お腹いっぱい。
22/11/03 17:38:44.40 nkzyaylY.net
Chrome 110でフラグ削除は避けられないかもしれんけど
その後libjxl 1.0が出て
949:暫くしたら再度サポートされる可能性も十分あると思う
950:名無しさん＠お腹いっぱい。
22/11/03 17:46:50.30 OLwhQfVT.net
Chromeがブラウザシェアの大半を獲得したせいで市場をコントロールしてきたか
951:名無しさん＠お腹いっぱい。
22/11/03 17:54:22.11 h1AV65om.net
>>891
AVIFはエンコードとデコードが冗談みたいに遅いっていう明確なデメリットがあるからそのAVIFと他が同等なら完全な上位互換なんだわ対応するメリットがなく切り捨てられるのはAVIFの方なんだわ
952:名無しさん＠お腹いっぱい。
22/11/03 17:57:16.73 F2bsDXMR.net
>URLﾘﾝｸ(news.ycombinator.com)
>jonsneyers 16 minutes ago | root | parent | next [–]
>とはいえ、私たちは合理的な期間、つまり2023年のどこか、できれば前半にlibjxl 1.0のマイルストーンに到達することを目標としています。
libjxl 1.0が今年中にリリースされることは無い模様
953:名無しさん＠お腹いっぱい。
22/11/03 18:00:07.55 l1FFgLPY.net
>>915
そりゃChromeも呆れてサポート外すわな
954:名無しさん＠お腹いっぱい。
22/11/03 19:02:39.59 F2bsDXMR.net
>nine_k 2 hours ago | parent | prev | next [–]
>I wonder what is the Mozilla's position on JPEG XL.
>JyrkiAlakuijala 2 hours ago | root | parent | next [–]
>MozillaのエンジニアはJPEG XLに熱狂的ですが、彼らのディレクターはそうではありません
>jonsneyers 9 minutes ago | root | parent | next [–]
>基本的に、Mozilla の立場は、Chrome が最初にそれを行うまで、この面では何もしないということのようです。 Mozilla の意思決定者は、Chrome コーデック開発者と同様に、非 AOM コーデック、特に JXL をブロックすることで、「AOM への忠誠を証明する」必要性を感じているとしか思えません
955:名無しさん＠お腹いっぱい。
22/11/03 19:15:41.81 smD4+x3u.net
jxlを採用するとav1に喧嘩を売ったことになる構図ができてて草
956:名無しさん＠お腹いっぱい。
22/11/03 19:43:21.10 F2bsDXMR.net
被害妄想拗らせ過ぎて対立煽りしててちょっと見るに堪えない
第一項の、実験的なフラグやコードを無期限に残すべきではありません。が理由の大部分だったと改めて思うよ
Chromeもまさかフラグ状態が2年以上継続するとは想定していなかったんだろう
かといって現在のlibjxl実装は正式サポートできるレベルに達してない→削除という塩梅な気がするわ
957:名無しさん＠お腹いっぱい。
22/11/03 19:49:35.76 leXWCbog.net
avifに劣るjxlは開発終了していいよ
958:名無しさん＠お腹いっぱい。
22/11/03 20:05:40.94 5bg56cfP.net
今んとこ v1.0はよ！ に尽きる気するな
959:名無しさん＠お腹いっぱい。
22/11/03 20:09:53.86 Ln74D76m.net
webpはv1.0に達する遥か前から正式採用されていると書いてあった
960:名無しさん＠お腹いっぱい。
22/11/03 20:11:18.25 9YsD7X4N.net
abort問題が致命的、全部クラッシュする
961:名無しさん＠お腹いっぱい。
22/11/03 20:22:28.48 pVr1cPmM.net
完成度が低いってのはlibavifも同じでまだAPI固まってない
962:名無しさん＠お腹いっぱい。
22/11/03 21:25:05.63 d3U6yYbP.net
AVIFはゲロ重な援交度と出光度をなんとかしろ🤮
963:名無しさん＠お腹いっぱい。
22/11/03 21:27:24.85 d3U6yYbP.net
ムーアの法則が生きてりゃAVIF問題も時間が解決してくれたけど今じゃ性能向上ほとんど頭打ちだしなぁ
お㍗ル
964:名無しさん＠お腹いっぱい。
22/11/03 22:12:30.33 Y+NmcQ1A.net
>>923
それキミの実装が悪いのでは？
965:名無しさん＠お腹いっぱい。
22/11/03 22:18:44.99 Ln74D76m.net
AVIFはハードウェアエンコードが前提でしょ
966:名無しさん＠お腹いっぱい。
22/11/03 22:30:25.95 l7ZQZoM4.net
AVIFはJPEG XLに比べてエンコード・デコード共に計算量が多すぎて、特にバッテリー駆動のポータブルデバイスには不向き
967:名無しさん＠お腹いっぱい。
22/11/07 07:14:46.83 ffVJQ9Wp.net
avifは細部がつぶれすぎ
968:名無しさん＠お腹いっぱい。
22/11/09 00:18
969::26.77 ID:kDJ6OMti.net
970:名無しさん＠お腹いっぱい。
22/11/09 00:36:09.07 979UyruG.net
まあそれが普通だわな
971:名無しさん＠お腹いっぱい。
22/11/09 07:46:43.28 WSB7aSa/.net
Firefoxはサポート続けるのかな
972:名無しさん＠お腹いっぱい。
22/11/09 08:28:00.99 XU30PMEy.net
JXL結局ここでマンセーされてるほど優れた需要あるフォーマットでは無かったってことでFA？
973:名無しさん＠お腹いっぱい。
22/11/09 09:09:14.76 bkerEg7n.net
ここよりツイッターの方で熱いからそっちで聞いてみたら
974:名無しさん＠お腹いっぱい。
22/11/09 09:16:25.80 mIU+5Ksm.net
libjxlはabortをはよ修正しろ
libjpegみたいにエラー時にハンドラを渡してくれるだけでいいから
975:名無しさん＠お腹いっぱい。
22/11/09 09:17:58.80 mIU+5Ksm.net
abort問題のせいでアプリ開発のjxl対応企画が上に通らんのや
976:名無しさん＠お腹いっぱい。
22/11/09 09:20:31.68 mIU+5Ksm.net
chromeの件に文句言う前に、もっと組み込み開発者目線になって不具合潰してけやlibjxlがよ
977:名無しさん＠お腹いっぱい。
22/11/09 09:27:00.64 SBy008HJ.net
いくらjxlが優れていても普及せずに開発者たちが採用せずに使い道が無かったら需要のないゴミカスと一緒
978:名無しさん＠お腹いっぱい。
22/11/09 09:31:20.44 EPaUlA+M.net
>>938
何様だよおまえ
979:名無しさん＠お腹いっぱい。
22/11/09 09:33:21.85 mYM1tLD0.net
>>938
カスみたいなお前のゴミアプリひとつjxl対応したところで誰も使わないから
自意識過剰過ぎる🤣
980:名無しさん＠お腹いっぱい。
22/11/09 09:59:55.26 FFNzev0x.net
憶測だけど依存部分の開発を進めてから対応するほうが全体として完成早くなる判断っぽく見えた
さすがに何も考えてないわけないだろうし
981:名無しさん＠お腹いっぱい。
22/11/09 13:52:46.38 XU30PMEy.net
なんかどの新フォーマットも不便さが続きそうだしmozjpeg使い続けるしかないのか
982:名無しさん＠お腹いっぱい。
22/11/10 18:01:45.48 idx+a2G3.net
URLﾘﾝｸ(pbs.twimg.com)
983:名無しさん＠お腹いっぱい。
22/11/10 19:22:16.49 9Sq6sE8V.net
こうなってくるとjpegxlは主にイラストレーター、クリエイター向けの超高画素画像保存用途になるのかな
984:名無しさん＠お腹いっぱい。
22/11/10 19:30:28.24 DzlFFaYQ.net
microsoftは未だにダンマリなのな
985:名無しさん＠お腹いっぱい。
22/11/11 09:30:15.26 ckwuz4yz.net
結局ソフトウェア界のインフルエンサー（≒ブラウザやOSなど）がせーので対応しないと小規模デベロッパーも永久に採用できないんだよな
愚かで間抜けでハゲな人類の歴史を見ているようだ
986:名無しさん＠お腹いっぱい。
22/11/11 10:21:22.85 JHC2IPU1.net
x 小規模デベロッパーも永久に採用できない
o 採用する価値がない
987:名無しさん＠お腹いっぱい。
22/11/11 12:13:39.59 ckwuz4yz.net
余計に浪費してたストレージを半分以上も節約できるのに価値がないとは何ぞやね
もうハードウェアの進化もじょじょに鈍化してきて容量問題が深刻になってきてるんだからソフト屋はもっとハードウェアリソースを節約する方向へ努力すべきだと思うんだよね
988:名無しさん＠お腹いっぱい。
22/11/11 12:34:01.42 uUBA6w0T.net
ストレージ乞食沸いちゃってるやんオワタ
989:名無しさん＠お腹いっぱい。
22/11/11 13:48:22.66 Lc9W1LRx.net
写真のクラウドサービス持ってるとこは容量削減できる機会なんだからもうちょい反応しても良くないかって思うな
マイクロソフトとかアップルとかアマゾンとか
990:名無しさん＠お腹いっぱい。
22/11/11 17:13:04.17 n5+lHPHg.net
HDR画像普及の布石になると思ってたのに
991:名無しさん＠お腹いっぱい。
22/11/11 18:04:51.86 gcToa2/s
992:.net
993:名無しさん＠お腹いっぱい。
22/11/11 18:13:59.24 1nWl0kis.net
HDR対応（）モニターへHDR出力したら画面が黄色っぽく汚くなって速攻で戻した
以来HDR出力はゴミとしか思ってない
994:名無しさん＠お腹いっぱい。
22/11/12 11:25:24.71 3+0f9dAG.net
URLﾘﾝｸ(groups.google.com)
ウェブの進化を支援することは困難なことであり、私たちは難しい選択をすることを要求されます。
また、ブラウザやデバイスのパートナーから、フォーマットを追加するたびに（金銭的またはハードウェア的な）コストがかかると聞いており、これらのコストが Google 以外の人々によって負担されていることを強く意識しています。
新しいメディアフォーマットを評価するとき、まず問われるのは、そのフォーマットがウェブに最適かどうかということです。
たとえばJPEG XLのような新しい画像フォーマットでは、さまざまな要素を総合的に検討する必要があります。
たとえば、さまざまな画像の圧縮性能、小さな画像の高速レンダリングを可能にする高速デコーダ、大規模ユーザーにとってエンコーディング費用が妥当となるハードウェアサポートを備えた高速エンコーダ、新たなフォーマットのサポートを追加するのではなく、既存のフォーマットを最適化し新しいユースケースに対応できるか、他のブラウザやOSはサポートしているか、などです。
データを精査した結果、ChromeのJPEG XL実験を中止し、実験に関連するコードを削除することを決定しました。 今後、数週間のうちにデータを公開できるよう努力します。
ChromeでJPEG XLを使いたい人にとって、WebAssembly（Wasm）の実装はパフォーマンスも高く、前途洋々であると信じています。
995:名無しさん＠お腹いっぱい。
22/11/12 13:05:39.35 e0HawjZu.net
今後はwasmでウェブサイト側が各々wasmでjxl表示に対応すればいいってことだな
996:名無しさん＠お腹いっぱい。
22/11/12 13:22:08.68 Oc+v9hAv.net
今後はウェブページのバイナリ化がいっそう進みそうだね
997:名無しさん＠お腹いっぱい。
22/11/12 13:25:52.51 DV5OcWjr.net
>>956
サイト側が対応なんて、そんなことできるの？
998:名無しさん＠お腹いっぱい。
22/11/12 14:27:21.82 s7lq5j5I.net
件のチケットに大物の支援コメントが来てた
999:名無しさん＠お腹いっぱい。
22/11/12 14:33:31.17 QCPKjcII.net
>>958
cloudinary.comのJPEGXLコンバータはWASMで動いてるはず
1000:名無しさん＠お腹いっぱい。
22/11/12 14:51:16.53 q4oRQX55.net
ウェブアセンブリは次世代のflashだっけ？あんまよく知らない
1001:名無しさん＠お腹いっぱい。
22/11/12 15:00:09.78 s7lq5j5I.net
WebAssemblyは機能面だけ見れば、単に処理速度が速いJavaScriptだよ
1002:名無しさん＠お腹いっぱい。
22/11/12 15:39:15.91 7q2c2XV7.net
javascriptより軽量、高速、主要ブラウザで完全対応、と宣伝しとくわ
1003:名無しさん＠お腹いっぱい。
22/11/12 19:21:33.75 IwPA2T4P.net
>>958
ブラウザをavifに対応させるやつとかあるので
出来ないことはないが余計な読み込みが増えるからね…
URLﾘﾝｸ(github.com)
1004:名無しさん＠お腹いっぱい。
22/11/12 20:15:57.12 Cz4gIlkG.net
悲しい
URLﾘﾝｸ(jpegxl.info)
1005:名無しさん＠お腹いっぱい。
22/11/12 23:28:42.99 mVvmYk8v.net
＞たとえばJPEG XLのような新しい画像フォーマットでは、さまざまな要素を総合的に検討する必要があります。
＞たとえば、さまざまな画像の圧縮性能、小さな画像の高速レンダリングを可能にする高速デコーダ、大規模ユーザーにとってエンコーディング費用が妥当となるハードウェアサポートを備えた高速エンコーダ
これXLはエンコード遅くて対応する価値無いって事だよね
1006:名無しさん＠お腹いっぱい。
22/11/13 04:20:06.26 0FoxLh8W.net
理由に関しては
>数週間のうちにデータを公開できるよう努力します。
って書いてあるんだしそれ待つしかなくないか
1007:名無しさん＠お腹いっぱい。
22/11/13 07:16:01.80 4+rRLQOe.net
速度の比較ってないの？
にわかだけどあまりエンコード遅いって話聞
1008:かないけど
1009:名無しさん＠お腹いっぱい。
22/11/13 07:32:12.69 m6p9jO6g.net
>>747のやつとかそういう比較じゃないのかな
1010:名無しさん＠お腹いっぱい。
22/11/13 09:47:58.87 a4cUJ75L.net
問題はエンコードじゃなく
xlに変換した後の表示速度やスマホやPCへの負荷が他のフォーマットより重いって事じゃねーの？
ChromeはAVIFですらサポートしてるのにxlは消極的だからな
1011:名無しさん＠お腹いっぱい。
22/11/13 11:16:31.42 aOYNRhVy.net
libjxlのデコードはクソ遅いよ
dav1dのデコードのがよっぽど速い
1012:名無しさん＠お腹いっぱい。
22/11/13 11:53:38.19 +yyfMbrv.net
AVIFもゲロ重じゃなかったか
デコードはそうでもないのか
1013:名無しさん＠お腹いっぱい。
22/11/13 12:16:33.87 CPrUPFal.net
AVIFはAV1と一蓮托生だし今更ChromeもAV1のサポートは切らないだろうし
1014:名無しさん＠お腹いっぱい。
22/11/13 12:17:14.21 gXIWKucM.net
エンコードは最近のlibaomがかなり最適化が進んでJXLと遜色ないレベルになってる (除ロスレス)
手元の環境では両者デフォルトのavif speed 6とjxl effort 7で同じぐらいの速度だった
デコードはlibaomを使うとJXLより重くdav1dを使うとJXLより軽いって感じ
1015:名無しさん＠お腹いっぱい。
22/11/13 12:19:24.35 XaR4sxRw.net
dav1dは高度に最適化されてるからね
1016:名無しさん＠お腹いっぱい。
22/11/13 12:21:50.88 Rq5E8x5I.net
なんでこのスレでJXL が持ち上げられてるのか意味わからん
1017:名無しさん＠お腹いっぱい。
22/11/13 13:09:53.63 ry050fQf.net
ハードウェア支援がないって理由はなんか納得しきれないな
もっとトラフィックの削減を気にした方がいいんじゃないですかね
1018:名無しさん＠お腹いっぱい。
22/11/13 13:11:54.33 IegRKP+T.net
技術系の板なんて、古いものを使い続けるぞとかレストアするぞ
みたいなスレを除いて、基本的に新しいものが好きだから普通
1019:名無しさん＠お腹いっぱい。
22/11/13 13:52:52.25 dfSoTmEZ.net
速度と画質を比較した第三者的なデータがないと単純な比較にもならないでしょ
そもそもどっちが上位互換とかでもなく特徴の違うものを並べて特定要素で優劣つけるのは何の意味もなくて浅はかだけど
まあJPEG Xで想定されるWebのユースケースがすべて他で問題ないっていうデータをGoogleが出してくれたらある程度白黒つくよ
1020:名無しさん＠お腹いっぱい。
22/11/13 14:45:54.80 3cdrbLDP.net
>>976
スレタイ通りの画像コーデックはjxlしか無かったからな
1021:名無しさん＠お腹いっぱい。
22/11/13 17:28:42.23 fOXyYoDA.net
>>974
うちのロースペに片足突っ込んだマシンだとavifdec(libdav1d6)よりdjxlの方が速かった
特に大型ディスプレイ向けの壁紙なんかだと結構な差に
1022:名無しさん＠お腹いっぱい。
22/11/13 17:46:04.17 K9FUfJEh.net
jpegが一番早い
1023:名無しさん＠お腹いっぱい。
22/11/13 18:22:29.64 +yyfMbrv.net
mozjpegかguetzliを使えってことでつね
1024:名無しさん＠お腹いっぱい。
22/11/13 19:01:27.83 PqiknxxU.net
HDR使えない
1025:名無しさん＠お腹いっぱい。
22/11/13 19:10:36.76 C+FPwM6U.net
hdrとかいう容量無駄食いフォーマットを使うアホ
1026:名無しさん＠お腹いっぱい。
22/11/13 19:12:35.60 GYG5RfCZ.net
>>984
pngかavifでいいじゃん、なにか問題あるの？
1027:名無しさん＠お腹いっぱい。
22/11/13 19:26:18.37 ZmBiGqoO.net
jxlの化けの皮を剥がしたChrome最高
1028:名無しさん＠お腹いっぱい。
22/11/13 19:45:09.61 85q/QI0Q.net
Jpeg XLをサポートしない理由が他の画像サポートする時にあったのかいって思う
公正な判断とは言えないし、今回のでChromiumはGoogleの所有物だと強く感じたな
1029:名無しさん＠お腹いっぱい。
22/11/13 19:51:12.33 kB6BRC7y.net
>>988
ゑ？知らなかったの？
1030:名無しさん＠お腹いっぱい。
22/11/13 19:51:56.35 dhU0qFw1.net
jxlが潰れてこのスレも役目終了だな
1031:名無しさん＠お腹いっぱい。
22/11/13 19:55:27.34 phxGwz5E.net
Twitterとかredditと違ってここはgoogle様が正義だって意見多くて�
1032:rビるな 代わりがあります！我慢します！とか奴隷かよ…
1033:名無しさん＠お腹いっぱい。
22/11/13 20:05:23.23 C7A+zgrv.net
安心しろ、無能が一人で自演してるだけだ
専門版で無知晒して喜ぶ本物の知恵遅れなんてそうそういないし
現実で認められないから優しく相手してあげるほど喜んで増長する
1034:名無しさん＠お腹いっぱい。
22/11/13 20:08:09.30 ANGPZT9r.net
jpegxl信者だけど実際のところ大半が事実で反論できなくて悔しい
なんでデコードがあんなに遅いんだよ
1035:名無しさん＠お腹いっぱい。
22/11/13 20:09:44.36 DlPGBsgM.net
jxlの表示速度はjpegより速いって聞いたけど
1036:名無しさん＠お腹いっぱい。
22/11/13 20:10:53.57 phxGwz5E.net
デコードに関しては誰もデータ出してないから好き放題言えるよな
1037:名無しさん＠お腹いっぱい。
22/11/13 20:14:34.50 mm4ZTo2G.net
JpegXLはエンコード能力が過去最高なのは認めるけどデコード能力がゴミすぎる
1038:名無しさん＠お腹いっぱい。
22/11/13 20:24:51.21 hbyA8iNK.net
>>995
jxlは不利になる情報を出さないからしょうがない
1039:名無しさん＠お腹いっぱい。
22/11/13 20:28:39.80 NQIbXMRh.net
デコード速度で切られるなら真っ先に切られるのはAVIFだろ
これ言い訳にしてきたらAOMのご機嫌取りしたって自白と同義だ
1040:名無しさん＠お腹いっぱい。
22/11/13 20:31:22.61 CPrUPFal.net
AVIFはAV1サポートするならおまけで対応できる
1041:名無しさん＠お腹いっぱい。
22/11/13 20:32:59.93 0FoxLh8W.net
JPEGの後継画像フォーマットについて議論するスレ 2
ｽﾚﾘﾝｸ(cg板)
1042:1001
Over 1000 Thread.net
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 6012日 13時間 11分 48秒
1043:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています