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