21/04/18 22:35:03.46 5Bh0OAhB.net
>>313
XRは対応してるとこ少ないのがね…HDRならjpeg XLの方が推されると思う
326:名無しさん@お腹いっぱい。
21/04/19 00:00:01.58 yNlyR/A6.net
webpとJXRって同等の品質ならどっちが圧縮率いいの?
327:名無しさん@お腹いっぱい。
21/04/20 19:49:47.37 N1fm0dbV.net
>>314
jpeg XLってのがあるんですね。
まだ国際標準規格化されてないのがアレですが。。。
328:名無しさん@お腹いっぱい。
21/04/20 20:34:33.06 /2OjoqXn.net
>>316
XLの方も現状は無理だろうけど、この先を考えると多分XRの方が分が悪いというか
329:名無しさん@お腹いっぱい。
21/05/06 23:27:55.70 ymzGkPr4.net
firefox90から
330: https://twitter.com/jyzg/status/1390252388443897862?s=21 (deleted an unsolicited ad)
331:名無しさん@お腹いっぱい。
21/05/07 06:23:15.25 xEBMjhQj.net
>>318
これはPriority: Not set
Bug 1539075 (JPEG-XL) は Priority: P5
まるでやる気なしだな
332:名無しさん@お腹いっぱい。
21/05/08 10:58:59.31 uo1b3uoN.net
まあ優先度低くても予定があるだけappleよりはいいよ
333:名無しさん@お腹いっぱい。
21/05/10 11:50:35.09 OauPVsZ4.net
URLリンク(twitter.com)
WordPress 5.8でWebPに対応
日本だとシェアが高くてここが変わらなきゃ始まらないんだが、AVIFやJPEG XLに対応するのはいつになるやら
ついでにInternet Explorer 11サポートも終了するかもだって
>>315
圧縮効率の美味しいところが違うから基本的に比較は不可能
ハイクオリティならJPEG XLでロークオリティならWebPと使い分けるしかない
>>320
appleさんは突然やる気を出すから期待してていいよ多分
(deleted an unsolicited ad)
334:名無しさん@お腹いっぱい。
21/05/26 19:10:58.64 5IwUhgus.net
今日リリースされたChrome 91にJPEG-XLサポートが入ったよ
chrome://flags/#enable-jxl
で有効化が必要
335:名無しさん@お腹いっぱい。
21/05/28 12:34:04.89 UNMOpfkt.net
あーjxl標準になって欲しいんじゃぁ~
336:名無しさん@お腹いっぱい。
21/06/16 13:42:55.95 6j97DE5r.net
FirefoxもNightlyでimage.jxl.enabled=trueにすればJPEG XL読める
337:名無しさん@お腹いっぱい。
21/06/16 14:03:56.49 TO7VyFLu.net
FirefoxはいまだにAVIFのカラースペースバグを修正できず、全ユーザーで有効化できてない
詳しく見てないがカラースペースバグはJPEG XLにも引きずっていると思われるので
こちらの有効化も当分できないだろう
338:名無しさん@お腹いっぱい。
21/08/03 14:24:36.91 oEyPNb+Z.net
libjxl 0.5 やっとでた
しばらくリリースがないからどうなってんのかと思ったけど
339:名無しさん@お腹いっぱい。
21/09/07 09:39:27.53 wtZ/Ll9z.net
今日リリースのFirefox 92でAVIFサポート
340:名無しさん@お腹いっぱい。
21/09/09 19:40:00.54 tDKzyZ19.net
自炊でスキャンした漫画とかをJPEG XLに変換してみたけどあまりサイズ小さくならないね。
AVIFのほうが小さくなるけどMicrosoft AV1 Video Extensionの仕様か白飛びするのが困る。
誰かJPEG XLのSusieプラグイン作ってくれないかな。
341:名無しさん@お腹いっぱい。
21/09/09 20:38:59.85 DSSw8XNE.net
Firefox92入れたのにavif有効になってなかった・・・
Microsoft AV1 Video Extensionおかしいね・・・うちは紫色になる
342:名無しさん@お腹いっぱい。
21/09/09 20:45:39.09 iKeQgyKc.net
jpeg xlはこの先生きのこれるのか
ていうか名前がxrと紛らわしい
343:名無しさん@お腹いっぱい。
21/09/10 06:21:17.81 GUNYG1Ah.net
AVIFもJPXLも、早いとこperfect viewerが対応してくれないかな
344:名無しさん@お腹いっぱい。
21/10/07 13:11:26.42 ecCUj8bR.net
画像保存するときに拡張子がavifだったときのウザさ半端ねぇわ、webpの比にならん
自力で変更も出来ねぇし誰だよこんなクソみたいな拡張子作ったの氏ね
345:名無しさん@お腹いっぱい。
21/10/07 14:00:37.34 mdPikMjI.net
もう次世代はwebp一択だろ
GoogleがブラウザやYouTubeで対応してiOSも対応したし
346:名無しさん@お腹いっぱい。
21/10/13 14:09:10.59 yOteUKak.net
webpは次世代じゃないよ
347:名無しさん@お腹いっぱい。
21/10/17 09:23:59.85 qEaMw3w2.net
webpは次世代だろ
jpg2000とか出てたが自滅して空白期間が出来て結局jpgに変わるものが長らくなかったしな
348:名無しさん@お腹いっぱい。
21/10/21 21:45:13.09 ZgMXSM5r.net
webp2出るしそもそもweb専だからjpegの後継でも無いよ
349:名無しさん@お腹いっぱい。
21/10/22 00:42:06.52 /Z4Q+5Z+.net
webp2はwebpの次世代であってjpgの次世代ではない
350:名無しさん@お腹いっぱい。
21/10/22 08:47:24.70 3nwPrxL+.net
写真とかイラスト保存する時の形式にjpgが使われなくなったら世代交代かな
351:名無しさん@お腹いっぱい。
21/10/22 11:13:46.58 Bb9r0ctb.net
>>338
その用途だとJPEG XLしかない
352:名無しさん@お腹いっぱい。
21/10/22 17:23:00.47 8/LkSt+G.net
>>328
漫画とかイラストはavifの細かい部分を塗り潰しちゃう悪いとこが目立ちにくいから向いてるね
写真メインのとこは微妙だろうけどイラストメインのpixivとかと相性良さそう
353:名無しさん@お腹いっぱい。
21/10/23 02:40:51.60 MSZDA/Tp.net
GIMP 3がJPEG XLをサポート
354:名無しさん@お腹いっぱい。
21/10/23 16:58:05.46 +xs/NsEe.net
はよJPEG XLさんが世界統一果たしてほしい
355:名無しさん@お腹いっぱい。
21/10/23 20:16:50.79 86oQ9l4b.net
ほんと後継きまるまでなげーな・・・
356:名無しさん@お腹いっぱい。
21/10/24 13:49:09.84 8tJOz5Ez.net
JPEG XLの人も技術的には問題ないけどコーデックの普及には政治的な難しさもあるとか言ってたからなあ
でかい企業さん方が乗り気になれば早いだろうけどそうなるまでが長そう
357:名無しさん@お腹いっぱい。
21/11/09 05:22:54.96 TD6mju5P.net
jpegもだけどgifの後継はどうなるんだろな
358:名無しさん@お腹いっぱい。
21/11/13 00:33:23.06 fODktyw/.net
URLリンク(twitter.com)
URLリンク(pbs.twimg.com)
(deleted an unsolicited ad)
359:名無しさん@お腹いっぱい。
21/11/26 18:42:26.89 WcUKl0Tn.net
実際、jpeg xlって軽いの??
ちゃんとしたベンチマーク結果ないのかよ
360:名無しさん@お腹いっぱい。
21/11/27 19:27:45.54 iGTR3xze.net
>>347
URLリンク(cloudinary.com)
361:名無しさん@お腹いっぱい。
21/11/27 22:34:45.32 Y5qsK6MJ.net
avifの限界サイズ厳しいな
362:名無しさん@お腹いっぱい。
21/11/30 04:09:57.40 38+mCXoN.net
JPEG XLのWikipediaの記述間違ってね?
URLリンク(ja.wikipedia.org)
> JPEG XLエンコーダは拡張メタデータを追加した下位互換性のあるJPEGファイルを生成することができる。
> このファイルはJPEGデコーダでデコード可能であり、JPEG XLデコーダの場合は拡張メタデータを使用して画質を向上させることができる。
こんなのないよね
363:名無しさん@お腹いっぱい。
21/11/30 05:06:03.09 Pr6bUpi1.net
ん?どの部分が??
そういう機能あったような気がするが
364:名無しさん@お腹いっぱい。
21/11/30 08:24:27.77 lCQg0CWn.net
>>350
>>348のlegacy friendlinessの部分のことじゃね
365:名無しさん@お腹いっぱい。
21/11/30 09:37:58.14 38+mCXoN.net
>>352
それは既存のJPEGを無損失でJPEG XLに変換する機能であって、既存のJPEGデコーダーが読めるような形のJPEG XLを出力する機能ではなくない?
366:名無しさん@お腹いっぱい。
21/11/30 09:42:14.74 38+mCXoN.net
これさえあれば今からでもJPEG XL使えるからやりたいんだけど、どうにも英語の文献を漁る限り見当たらなくてな
367:名無しさん@お腹いっぱい。
21/11/30 09:48:24.46 EqbsaAi/.net
間違えてるね
wikipediaってそんなもん
368:名無しさん@お腹いっぱい。
21/11/30 09:50:35.80 4bfyX09v.net
>>353
To me, legacy friendliness is an important feature that facilitates a smooth transition from JPEG to a successor format without requiring a transition period in which two versions of every image—the old JPEG file and the new “successor-format” file—must be stored to satisfy the long tail of users who haven’t upg
369:raded yet.
370:名無しさん@お腹いっぱい。
21/11/30 16:44:57.52 ktNdH4Ro.net
>>354
URLリンク(jpeg.org)
の2段落目くらいに書いてない?
371:名無しさん@お腹いっぱい。
21/11/30 17:17:03.67 KFnanVzO.net
jpeg xlって紛らわしいんだよな
jpegだから既存のブラウザで互換表示出来るかと思ったら
新規で対応しないといけないんならもう別フォーマットじゃねーか
372:名無しさん@お腹いっぱい。
21/11/30 18:00:08.29 Pr6bUpi1.net
Existing JPEG files can be losslessly transcoded to JPEG XL, significantly reducing their size. These can be restored into the exact same JPEG file, ensuring backward compatibility with existing JPEG-based applications
2二段目のこれか
373:名無しさん@お腹いっぱい。
21/11/30 18:03:11.51 Pr6bUpi1.net
URLリンク(res.cloudinary.com)
JPEG bitstream with app markerってやつか
374:名無しさん@お腹いっぱい。
21/11/30 20:39:49.72 38+mCXoN.net
>>360
おーなんかそれっぽいな
ちょっと調べてみるわサンクス
375:名無しさん@お腹いっぱい。
21/11/30 21:24:27.04 OEJ8hZMQ.net
てかもうここは15年半のスレなんだな…
376:名無しさん@お腹いっぱい。
21/11/30 21:57:50.02 Ujq/SEEL.net
はやいとこJPEG XLパイセンに覇権を取ってもらわないと
377:名無しさん@お腹いっぱい。
21/11/30 22:05:06.59 EqbsaAi/.net
>>360
その機能、仕様はあるけど実装がないんじゃないの?
378:名無しさん@お腹いっぱい。
21/11/30 22:12:30.50 Pr6bUpi1.net
それは可能性ありそう
リファレンスエンコーダが実装してるのかは謎
379:名無しさん@お腹いっぱい。
21/12/01 00:04:44.39 A5h6Sx7r.net
ここのExpert SettingsにJPEG transcodeってあるけどそれとは別?
URLリンク(jpegxl.io)
380:名無しさん@お腹いっぱい。
21/12/01 00:12:49.41 S/W9bKMr.net
>>366
それは >>360 の図の一番左端のパスでしょ
381:名無しさん@お腹いっぱい。
21/12/02 20:23:38.66 ogyvh4nM.net
>>360
左から右がそのまま移行の流れなんだな
こういう風にスムーズに変わっていけたらいいな
382:名無しさん@お腹いっぱい。
21/12/08 18:28:29.63 UMJnBCdD.net
次世代JPEG規格「JPEG XL」に対応した「IrfanView」v4.59
URLリンク(forest.watch.impress.co.jp)
> ただし、「IrfanView」で表示する際はJXLプラグインが既定では無効化されていることに注意。あらかじめプラグインを有効化しておく必要がある。
383:名無しさん@お腹いっぱい。
21/12/08 22:14:46.07 jj81+rlV.net
ゆっっくりだけど対応進んできてんのね
384:名無しさん@お腹いっぱい。
21/12/14 02:37:20.46 uGPE+vQ1.net
xnconvertはまだ対応してないんだよなあ
perfectviewerも
385:名無しさん@お腹いっぱい。
21/12/14 03:51:32.48 8FXYFVAQ.net
xnconvertは対応してなかったっけ
386:名無しさん@お腹いっぱい。
21/12/14 05:21:09.63 uGPE+vQ1.net
>>372
M1Macだけど対応してないな
387:名無しさん@お腹いっぱい。
21/12/14 12:09:36.50 JRyBatki.net
windowsだと出来るけどosによって対応違うんか
388:名無しさん@お腹いっぱい。
21/12/14 12:49:36.28 +0QF3W7g.net
M1がarmだからなんかね
実装ライブラリlibjxlパット見た感じMSVC未対応ってのも開発者にとってクソめんどいし
389:名無しさん@お腹いっぱい。
21/12/16 14:35:17.74 71DMDhdA.net
こういう新しい画像フォーマットってOS自体が対応するのはどれくらい先なんだろか
avifはどんくらいかかったっけ
390:名無しさん@お腹いっぱい。
21/12/16 20:24:44.12 H00CausJ.net
2019年2月、AVIFバージョン1.0.0策定
2021年10月、Android12でネイティブサポート
なので2年半程度掛かってるね
JPEG XLは先々月にPart 2: File formatが完成
Part 1: Core coding systemはFDIS承�
391:F見込みでIS発行は年明け頃になるらしいので まあ気長に待とう…
392:名無しさん@お腹いっぱい。
21/12/16 20:30:37.28 A+xehKYQ.net
JPEG XLは中の人の半分がGoogleだし、開発版Chromeには既に実装済みなので少し早まると思う
393:名無しさん@お腹いっぱい。
21/12/16 23:27:39.53 yrYYivSc.net
androidとかiOSはきついけどWindowsはWindows Imaging Componentなどで画像フォーマットを新規に追加しやすくなってるからな
394:名無しさん@お腹いっぱい。
21/12/17 04:58:51.66 5vCVWsG3.net
>>377
そういやまだそれもあったか…確かPart4まであるんよね
395:名無しさん@お腹いっぱい。
21/12/18 18:53:40.12 jnooucgR.net
The JPEG XL standard has now been formally approved: the Final Draft International Standard (FDIS) of ISO/IEC 18181-1 (the JPEG XL codestream spec) was approved unanimously; the International Standard will be published in January 2022. It's done!
JPEGXL規格が正式に承認されました。ISO/ IEC18181-1の最終ドラフト国際規格(FDIS)(JPEG XLコードストリーム仕様)が満場一致で承認されました。国際規格は2022年1月に公開されます。これで完了です。
URLリンク(twitter.com)
URLリンク(pbs.twimg.com)
(deleted an unsolicited ad)
396:名無しさん@お腹いっぱい。
21/12/18 20:09:46.43 DmbWKGs5.net
めでたい
397:名無しさん@お腹いっぱい。
21/12/19 04:00:13.08 7VmUZRVy.net
>>344
JPEG XLは可逆圧縮性能が滅茶苦茶優秀でスクショやイラスト保存形式のデフォルト候補として採用されるポテンシャルが普通にあると思う
写真保存形式はHW絡みでややハードル高いけど最近MediaTek Dimensity Open Resource Architecture、OPPO MariSilicon X、Xiaomi Surge C1、Vivo V1等々メーカー独自ISP開発ブームが来てるから我先に実装競争で採用チャンスありそう
398:名無しさん@お腹いっぱい。
21/12/19 05:29:27.23 2sGr01pT.net
JPEG XLの唯一にして最大の欠点は名前にJPEGがついてることだな
399:名無しさん@お腹いっぱい。
21/12/19 09:18:47.56 Gh4pf6M7.net
jpegがついてるのにjpeg対応のブラウザやビューアで表示出来ないって詐欺みたいなもんだろ
全く別のフォーマットのくせに互換性匂わしてんじゃねーよ
400:名無しさん@お腹いっぱい。
21/12/19 14:15:10.76 Ew8EzchD.net
>>358
>>385
何回同じこと書いてんだ
あとその勘違いは流石に情弱としか思えないからやめたほうがいいと思う
401:名無しさん@お腹いっぱい。
21/12/19 14:24:55.80 ZFEKZbCA.net
保存形式が完全に切り替わるのは3~5年以上要すると思うが
メジャーなソフトウェアが対応するのはもっと早く済むはず
このフェーズ差が功を奏するといいが
402:名無しさん@お腹いっぱい。
21/12/19 14:26:46.13 ZaPyF2I/.net
>>383
カメラの写真保存形式って今何が使われてるんだろか
403:名無しさん@お腹いっぱい。
21/12/19 14:31:56.33 ZYVBe/o5.net
>>388
撮って出しだと、普通にJPEGでは?
404:名無しさん@お腹いっぱい。
21/12/19 16:26:43.32 +c2VDCpq.net
URLリンク(chromestatus.com)
Chrome Platform StatusにFacebookがJPEG XLの使用を検討しているという一文が追加されているな
URLリンク(jpegxl.io)
実際にサポートテストが行われているらしい
上手く行けばInstagramとWhatsAppでも採用されるだろうな
405:名無しさん@お腹いっぱい。
21/12/19 16:51:24.30 bLaii480.net
JPEG XLはJPEG並に軽いのがうりの
406:一つなんだからなHEIFやAVIFと違ってCPUデコード、エンコード余裕..??
407:名無しさん@お腹いっぱい。
21/12/19 17:16:16.44 0/8pVu2z.net
>>391
余裕余裕
URLリンク(pbs.twimg.com)
408:名無しさん@お腹いっぱい。
21/12/19 20:24:30.27 2sGr01pT.net
肝心なのはデコード速度だろうな
そっちのグラフはないのかな
409:名無しさん@お腹いっぱい。
21/12/20 00:27:20.66 GS1Bca+O.net
Progressive decoding: JPEG vs JPEG XL vs AVIF
URLリンク(m.youtube.com)
Progressive loading: JPEG, JPEG XL, AVIF
URLリンク(m.youtube.com)
410:名無しさん@お腹いっぱい。
21/12/20 00:59:56.60 EgVB4r/3.net
>>394
すげー
一年前のver0.1時代のやつなのか
現在のver0.6?だと更に性能向上してるのかな
ver1.0リリースとその後の最適化が楽しみだ
411:名無しさん@お腹いっぱい。
21/12/20 01:31:33.15 skKlqw1C.net
>>392
avifがオチみたいで笑ってしまった
412:名無しさん@お腹いっぱい。
21/12/20 08:03:11.27 N0Ukn2Xx.net
作者のJon Sneyers氏が出してるベンチマークは凄そうなものばかりなんだけど
現時点のsquooshが出力するものだと、webpに勝ってるところが殆どないんだよなぁ
URLリンク(squoosh.app)
URLリンク(tshino.github.io) (画像比較ツール jxl対応)
413:名無しさん@お腹いっぱい。
21/12/20 11:18:08.10 /ewzGfXV.net
XLあちこちでステマしてるやついるけど
結局ブラウザやビューア対応少ないしwebpに劣ってるな
414:名無しさん@お腹いっぱい。
21/12/20 12:36:41.80 X81WMPW0.net
>>397
webpは赤色の劣化がな…
415:名無しさん@お腹いっぱい。
21/12/20 13:41:07.49 oQUUNyFv.net
>>390
インスタ対応来たらマジ大歓喜だわ
416:名無しさん@お腹いっぱい。
21/12/20 21:51:36.87 FyIqscqH.net
比較はこういうのもあるね、2021-12-15が一番新しいやつ
URLリンク(storage.googleapis.com)
417:名無しさん@お腹いっぱい。
21/12/20 23:00:14.59 TKR+saM8.net
>>398
そりゃ後発だから対応してないのが多いのは当たり前でしょうか
418:名無しさん@お腹いっぱい。
21/12/21 01:47:06.82 d23NtZH/.net
>>401
2番目の橋の夜空を見比べみた
mozjpegはブロックノイズが酷い
webp,webp2はカラーバンディングが結構目立つ
heif,avifは普通に綺麗。カラーバンディングも拡大しないとわからないレベル。星が若干滲むくらい
jxlは殆ど違和感ないな。強いて言うなら青色が微かに強くなる気がする程度かな
今回みたく淡いグラデーションがある画像に動画コーデック由来のやつは不向きなのかもしれん、と思った
419:名無しさん@お腹いっぱい。
21/12/21 02:21:51.86 Jy5JE+3v.net
やっぱり動画コーデック由来だとのっぺりする
ね〜
でも美顔効果もあるので女性は好みそう
AVIFはサムネイル画像やピクセルアートみたいな小さいサイズなら苦手なデコード速度の影響も減るし割と有りなんではと思った
一つ気になるのはWebP変換すると色彩がなんかおかしい。通行人のおじさんが不気味な土気色になってしまう
420:名無しさん@お腹いっぱい。
21/12/21 09:29:18.03 W/zBSTRN.net
結局Google主導のwebpが覇権だなこりゃ
421:名無しさん@お腹いっぱい。
21/12/21 11:19:23.86 pW6mjA38.net
XLって根幹がgoogleベースだろ
つまりwebpを捨てに来ているということ
422:名無しさん@お腹いっぱい。
21/12/21 12:52:14.94 5fW9OkYl.net
WebP・AVIFはGIFやAPNGの後継には適してるからなあ
423:名無しさん@お腹いっぱい。
21/12/21 13:23:39.75 P+A
424:DUvh5.net
425:名無しさん@お腹いっぱい。
21/12/21 13:31:37.14 /D58llPC.net
たしかJpegXL作った人もアニメーション画像はavifが最適ですって言ってたな
jpegとかpngの後継はJXL
GIFとapngみたいな動画像はAVIFって感じで分かれるんかね
426:名無しさん@お腹いっぱい。
21/12/21 13:39:16.13 Jy5JE+3v.net
未だ現存状態が続くレガシー無印JPEGをリプレースする為にJPEG XLが開発されているわけで
つまり逆に考えるとJPEG XLはWebP・AVIFの後継でもないんだよ
427:名無しさん@お腹いっぱい。
21/12/21 14:02:51.92 ZQTXt4OB.net
もともとWebPってGIF・APNGの競合規格じゃなかったっけ?
GoogleとMozillaが業界を二分してバチバチやってた記憶があるんだが
428:名無しさん@お腹いっぱい。
21/12/21 14:13:40.80 VuckbSzh.net
アニメーションはAVIFの方がいいって、AVIFは動画の技術がベースになってるからAVIFは時間軸に対しても圧縮する??から圧倒的に圧縮率がいいとか??じゃね
429:名無しさん@お腹いっぱい。
21/12/21 14:16:09.98 yy2hlIZ/.net
今、Web業界大手で最もJXLに冷淡なのがMozilla
430:名無しさん@お腹いっぱい。
21/12/21 15:00:29.32 xPAuomtb.net
URLリンク(jpegxl.io)
Nightlyでフラグ立てれば使えるらしいが
URLリンク(jpegxl.io)
フラグ立てれば使える
URLリンク(jpegxl.io)
webkitは対応するがiOS/MacはOS側で対応しないと無理
431:名無しさん@お腹いっぱい。
21/12/21 15:12:08.86 gYbBYiYi.net
>>412
多分そうかも
その辺は動画派生が強いんだろうね
432:名無しさん@お腹いっぱい。
21/12/21 15:15:50.94 yy2hlIZ/.net
>>414
BugzillaでJXL正式追加問題に対して冷たい態度取られてる
priorityも低い
433:名無しさん@お腹いっぱい。
21/12/21 15:24:14.55 wWGBUXJ8.net
appleの方が冷たくね
434:名無しさん@お腹いっぱい。
21/12/21 15:26:43.13 xPAuomtb.net
>>416
WebPも不満言いながら対応してたし
Webサイト側がFirefox無視して実装しちゃうからしぶしぶ対応とか?
435:名無しさん@お腹いっぱい。
21/12/21 15:51:43.45 W2rqE+Sl.net
URLリンク(bugs.webkit.org)
Facebookの画像インフラチーム中の人の投稿あるやん
>新しい画像形式(AVIF、JPEG XL、WEBP2など)のコンテキストでのJPEG XLに関するチームの見解と、ブラウザの採用によってテスト計画をどのように進めることができるかについて少しお話ししたいと思います。
過去5ヶ月間、パフォーマンスと品質の両面からJPEG XLの調査と評価を行った結果、JPEG XLはJPEGの後継となる新世代の画像フォーマットの中で最も可能性を秘めているというのが我々の意見です。
この意見は、以下のような知見に基づいています。
* スピード/エフォート6でのJPEG XLエンコーディングは、JPEGエンコーディング(Trellisエンコーディングを有効にしたMozJpegを使用)と同等の速度です。これは、JPEG XL画像をオンザフライでエンコードし、クライアントに提供することが実用的であることを意味します。これは、オフラインでエンコードする必要があるAVIFのエンコード速度と比較すると、動的なサイズと圧縮されたコンテンツを配信する際の柔軟性が低くなります。
* JPEG XLは、設定次第では非常に高速にデコードすることができます。モバイルベンチマークによると、複数のスレッドを使用してデコードした場合、JPEGと同等になることが確認されています。これは、他の新しい画像フォーマットのデコード性能と同等であり、多くの場合、それを上回っています。
* JPEG XL画像フォーマットは、プログレッシブデコードを柔軟にサポートしており、エンコード時に選択された固定スキャン(プログレッシブJPEGスキャン)に制限されることなく、DCコンポーネントのみ、または複数の中�
436:ヤ画像に基づいてクイックプレビューをレンダリングすることが可能です。 すべての主要なブラウザがサポートすることで、今後のWWW実験がより容易になり、プラットフォームやブラウザ間で一貫した体験を提供することができるようになるでしょう。
437:名無しさん@お腹いっぱい。
21/12/21 17:06:12.99 v+YFa4Cb.net
meta社つながりでinstagramとかにも影響あったら嬉しいねえ
あと日本はあんま関係ないけどWhatsAppも
438:名無しさん@お腹いっぱい。
21/12/21 18:03:41.65 sr+nCDfE.net
何故avifはwebpになれなかったのか
439:名無しさん@お腹いっぱい。
21/12/21 19:15:04.53 DNDwv5qQ.net
どっちもクソだからJPEG XLはよせい
440:名無しさん@お腹いっぱい。
21/12/21 19:27:02.67 uklylWxL.net
>>418
べつに利害関係ないし
普通に対応するでしょ
441:名無しさん@お腹いっぱい。
21/12/21 21:29:08.05 IjK+U4En.net
URLリンク(pbs.twimg.com)
442:名無しさん@お腹いっぱい。
21/12/22 19:16:32.48 hRadxewb.net
URLリンク(pbs.twimg.com)
URLリンク(pbs.twimg.com)
443:名無しさん@お腹いっぱい。
21/12/22 21:03:04.52 T4/Yty9X.net
>>425
slow lossless jxl がグラフに入ってないけどどうなんだ?
444:名無しさん@お腹いっぱい。
21/12/22 22:29:38.41 XcrQmWyq.net
fastしかグラフに入れてないのはfastでもoptipngくらい圧縮良くてめっちゃ早いですよって話のためじゃないかな
他の設定は>>424の画像の上の方にある
URLリンク(pbs.twimg.com)
445:名無しさん@お腹いっぱい。
21/12/23 05:13:30.75 Wo/tGu3p.net
>>420
Facebookインフラチーム(現Engineering at Meta)はQUICをFacebookのデプロイと同じストラテジーでInstagramにもデプロイした、とか言ってたから期待できそうやな
URLリンク(engineering.fb.com)
446:名無しさん@お腹いっぱい。
21/12/23 17:37:41.71 zQZzcKW8.net
>>428
はえー
こういう連携取れるの強いね
447:名無しさん@お腹いっぱい。
22/01/02 19:37:57.18 Jmt2Ke/E.net
今年はこれが変わると良いな
URLリンク(i.imgur.com)
448:名無しさん@お腹いっぱい。
22/01/03 02:07:47.26 SDHmhiJ0.net
今年は無理だな
来年は10パー未満勢が動くと思う
449:名無しさん@お腹いっぱい。
22/01/03 20:31:40.64 DsDZYz9O.net
大手CDNが採用したら結構動きそう
URLリンク(daniel.haxx.se)
URLリンク(daniel.haxx.se)
>2021年2月以降の成長は、Cloudflareが無料プランでもユーザーにHTTP/3を有効にしたことで説明できる可能性があることが示唆されています。
450:名無しさん@お腹いっぱい。
22/01/03 20:41:11.78 SDHmhiJ0.net
さすがにプロトコルと同列には語れないわ
451:名無しさん@お腹いっぱい。
22/01/03 20:52:30.36 jf/xCIEl.net
>>431
動くってのは増える方?減る方?
452:名無しさん@お腹いっぱい。
22/01/03 22:42:13.23 DsDZYz9O.net
>>433
10パー未満勢が動くという流れで大手CDNの影響力の話をしただけだが
件のHTTP/3を導入したCloudflareはAVIFサポートも早かったし
新規格に目敏いという点で注目に値すると思うね
453:名無しさん@お腹いっぱい。
22/01/03 23:14:17.55 p0Z0+aAO.net
イノベーション理論でいうアーリーアダプターだな
Facebookもそれよな一応GAFAの一角なだけある
つかhttp3ってまだRFCになってないのに
454:既に15%以上シェアあるの普通にすごいな
455:名無しさん@お腹いっぱい。
22/01/04 00:59:12.50 7GlyYldT.net
CloudflareといえばHTTP/2ストリーム多重通信とJPEGプログレッシブレンダリングで画像を並列表示させる実験してたし
最近だとInstagramがHTTP/3データグラム優先度制御で画像外よりも画面内の画像レンダリング速度を優先させる実装作ってたな
456:名無しさん@お腹いっぱい。
22/01/04 01:36:40.44 qweOF32n.net
インスタだけでWeb画像シェア5%くらいありそう
457:名無しさん@お腹いっぱい。
22/01/06 20:55:59.18 LKJL5JAk.net
webp2いいね
458:名無しさん@お腹いっぱい。
22/01/06 22:13:23.88 HQLvDYD6.net
LCPだけでは画像最適化に不向き、新しい指標が必要な理由
URLリンク(zenn.dev)
459:名無しさん@お腹いっぱい。
22/01/07 00:25:54.64 3pcz+wTu.net
>>438
Facebookはインスタの倍以上のユーザーいるしmetaのやる気は大事だねえ
460:名無しさん@お腹いっぱい。
22/01/07 21:06:32.31 eOlTZ4BL.net
gif使ってるウェブサイト
10年間でかなり減ったな
2012年68.4%→2022年20.9%
URLリンク(w3techs.com)
461:名無しさん@お腹いっぱい。
22/01/07 22:01:43.52 eOlTZ4BL.net
既存gifが何かにリプレイスされて絶対数が減ったというより新規サイトでgifが採用されなくなった、の方が正確か
いわゆる化石サイトの割合に近いかもしれん
462:名無しさん@お腹いっぱい。
22/01/07 22:05:09.71 M+TKjJvK.net
海外のgifまとめてますみたいなタイトルのサイトも開いて見りゃ音ありのmp4ばっかってのが増えた印象
463:名無しさん@お腹いっぱい。
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はどちらも先行技術であるように思われるため、関連する委員会は、そのような主張を行うために単に公開する必要があります。
コメント欄白熱しとるなw
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)