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