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:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています