21/02/13 07:16:49.18 zYXytkTO.net
>>231
H.265の権利関係が複雑化してるのを嫌ってAV1を策定した経緯があるから
H.265由来のHEIFとAV1由来のAVIFって対立軸に見えるけど
AVIFって基本的にはWebPの代わりとして期待されてる
HEIFがミラーレスに採用されてるのをAVIFが代替することはないはず
そっちはJPEG XLが代わりに出てくる
AVIFはNetflixは動画配信会社だからAV1を最も主導してて、Webの画像もAVIFにしてトラフィック削ろうぜって主張してるけど
Googleは将来的にトラフィックをバカ食いするJPEG XL対策にAVIFでは力不足だからWebP2を開発してる
edgeとSafariが対応したらモダンブラウザ制覇だけど存在が中途半端すぎんのよ
239:名無しさん＠お腹いっぱい。
21/02/13 14:36:11.40 90iCrJjX.net
JXL(ジクセル)
240:名無しさん＠お腹いっぱい。
21/02/13 15:08:11.89 vVerFx9R.net
次世代画像フォーマット「JPEG XL」のススメ
URLﾘﾝｸ(news.yahoo.co.jp)
JPEG XL専門部会の共同議長を務めているスナイアーズ博士が考案したFLIF（Free Lossless Image Format）は、一部がJPEG XLのベースになっている。同博士の画像処理技術「Muscles from Brussels」は最適化された画像を超高速で配信するのに役立つ。
JPEG XLは、広い色域、高いダイナミックレンジ、深いビット深度、アニメーション、アルファチャンネル、レイヤー、サムネイル、ロスレス、プログレッシブコーディングなどの機能が含まれ、幅広いユースケースをサポートする。新しいアプリケーション向けには360度画像、画像バースト、大きなパノラマやモザイク、印刷をサポートする。
JPEGとは異なり、写真だけではなくそれ以外（イラスト、スクリーンショット、ゲームグラフィックス、地図など）も設計の対象になっている。
JPEG XLには、依然72％のWebサイトで使われているJPEG画像からの
241:変換機能も幾つか含まれている。これによりストレージ（単一のJPEG XLでJPEGクライアントとJPEG XLクライアントの両方にサービスを提供できる）とファイルサイズ（既存のJPEGファイルをロスレスでJPEG XLに変換できる）を削減できる。 JPEG XLは、計算効率の高いエンコードとデコード用に設計されている。JPEG XLはモバイル端末でもハードウェアアクセラレーションを必要としないソフトウェア実装を使用する。 このコーデックの次期バージョン「JPEG XL 0.2」のフリーズは目前に迫っている。フリーズの時点で、過去と将来の全てのJPEG XL画像は今後のバージョンのコーデックと互換性があることになる。JPEG XLを試すとしても、大規模な採用は2021年に最終草案国際標準が提出されるまで待つことをお勧めする。
242:名無しさん＠お腹いっぱい。
21/02/13 16:24:50.10 xzlNlqbf.net
WebPとJPEG XL、Googleが自社プロダクトで使用しているSPDYやgQUICと、IETFで標準化を行っているHTTP/2やiQUICみたいな塩梅か
QUICのRFCも今年中に出そうだな
243:名無しさん＠お腹いっぱい。
21/02/13 22:42:47.17 SHZ2iWYR.net
Cloudflare曰くJPEGのプログレッシブレンダリングとHTTP/2のストリーム多重化が相乗効果を発揮し更なるWeb高速化を実現すると
Web漫画廻りが捗るな
244:名無しさん＠お腹いっぱい。
21/02/13 23:52:48.14 P4EuGEwq.net
Chrome 90から対応するかもって感じかな
URLﾘﾝｸ(twitter.com)
(deleted an unsolicited ad)
245:名無しさん＠お腹いっぱい。
21/02/14 08:02:41.07 VREcgGyi.net
今時主流のCDN配信に適した画像フォーマットって感じだな、JXL
まあCloudinaryが規格設計に関わってるから当然か
246:名無しさん＠お腹いっぱい。
21/02/14 08:28:49.97 jX72PyEt.net
>>238
CDNプロバイダがJXLエコシステムに強い関心を持ってるっていうのは普及に向けて好材料だな
ウェブブラウザのサポートは大前提としてCDNプロバイダ側の移行アプローチも重要になるだろうから
247:名無しさん＠お腹いっぱい。
21/02/14 21:16:16.24 2FKpeOZ4.net
アニメーションのjxlがどんなものなのか気になる
248:名無しさん＠お腹いっぱい。
21/02/15 03:47:37.74 eE+kxRUk.net
少なくともapngより圧縮率優れてるはず
LINEスタンプの形式もapngからjxlに移行するといいなぁ
249:名無しさん＠お腹いっぱい。
21/02/15 06:10:08.64 BtXdsKy6.net
まだアニメーション形式で比べてみたみたいなの無い感じかな
個人的にはredgifも早めに綺麗な方に移行してくれると嬉しいな
250:名無しさん＠お腹いっぱい。
21/02/15 06:47:03.77 HBw7GNo8.net
>>238
>Multithreaded and SIMD-optimized decoding
前者はgoogle/pik、後者はgoogle/highway実装だそう
phoronix-test-suiteのベンチマーク結果ではマルチスレッド/マルチコアCPUデコード速度の効果がよく出ていた
251:名無しさん＠お腹いっぱい。
21/02/15 13:04:06.79 PUW74EKu.net
10bit/HDR撮影できるスマホカメラ然り
10bit/HDR表示できるスマホディスプレイ然り
10bit/HDR環境が汎用デバイスにも進出し始めたので撮って出しできる10bit/HDR対応静止画フォーマットの需要が今後更に高まってくると思うな
252:名無しさん＠お腹いっぱい。
21/02/15 13:45:21.57 nao/9rAN.net
ちなみにOPPO Fi
253:nd X3がAndroidスマートフォンとして初めて10bit/HDRのHEIFフォーマットを撮影、保存、表示まで全てのプロセスでサポートする模様 林檎製品もそうだけど現時点ではHEIFしか選択肢が無いのかもしれない
254:名無しさん＠お腹いっぱい。
21/02/15 15:17:10.59 PPfRrFRk.net
Qualcomm Snapdragon 888 の Spectra 580 ISP が 10-bit HDR HEIF photo capture をサポートしており、曰く
>It's also our first mobile platform with true 10-bit HDR photo capture
だそうな
255:名無しさん＠お腹いっぱい。
21/02/15 17:28:35.62 19/PpZjH.net
JPEGは設計が単純でSDKやAPIが揃っていたので様々なデバイスでも開発が容易だったが
HEIFは符号化方式の構造上複雑な処理を捌く強力な画像処理プロセッサが必要だったり特許料が必要だったりとにかくコストが掛かると聞いていたけど
ここにきてHEIF採用の兆しが
256:名無しさん＠お腹いっぱい。
21/02/17 05:37:31.98 NUGMNZ2g.net
>>233
webp2は名前のまんまwebpの後継で小さいサイズで活かすつもりでJPEG XL対策ではないと思うな、AVIFが半端なのは同意だけど
URLﾘﾝｸ(chromium.googlesource.com)
翻訳かけたら WebP2は現在、部分的にしか最適化されておらず、非可逆圧縮の場合、WebPよりもおよそ5倍遅くなっています。それでもAVIFより2倍速く圧縮しますが、解凍には3倍の時間がかかります。目標は、解凍速度の同等性に到達することです。
ってあるから気長に待とうかな
257:名無しさん＠お腹いっぱい。
21/02/17 08:20:56.08 FXqRfJ7/.net
webp v2はGoogleの数あるCoPプロジェクトの一つような気配がする(e.g. guetzli, pik, brunsli, etc)
10年前と違い今は独禁法問題で米当局の目が厳しくなってるから検索エンジン最適化の濫用は避けるべきでISO/IEC, IETF, AOMなどの標準化団体に技術提供するという近年の方針は理に適っていると思う
258:名無しさん＠お腹いっぱい。
21/02/17 08:50:06.53 EeFOSdDM.net
VP8やVP9はWebM使ってたけど
AV1はISOBMFF(MP4)なんだよな
もう自社独自規格に拘るような時代じゃないんやな
259:名無しさん＠お腹いっぱい。
21/02/17 10:21:41.16 P54kMoh9.net
>>250
自己レス訂正CoP→PoCだわ
素直に概念実証って書けばよかったorz
Googleは技術実証の結果デファクトを取った後もデファクトのまま終わらず標準化まで持っていく印象がある
独自規格の囲い込みで儲けようとするイメージも無いから個人的にはそこに関してevilな感じはしないと弁明しておく
260:名無しさん＠お腹いっぱい。
21/02/17 12:49:36.56 NUGMNZ2g.net
>>244
これか
URLﾘﾝｸ(openbenchmarking.org)
261:名無しさん＠お腹いっぱい。
21/02/18 03:54:47.33 4qY3qfYu.net
JPEG 2000の動向
Part 15(High Throughput JPEG 2000)では，EBCOTの弱点であった計算負荷の高さとそれに起因する低スループットおよびバッテリー消費量の問題を解決するべく，新しいブロック符号化アルゴリズムが標準化された．若干の圧縮効率の低下と引き換えに，10倍以上のスループット向上が達成されている．また，決して並列化向きのアルゴリズムではなかったEBCOTとは異なり，
262:GPUなどによる並列化を強く意識したアルゴリズムとなっており，並列化によるスループットのさらなる向上が期待できる． (ttps://ja.m.wikipedia.org/wiki/JPEG_2000) HTJ2Kは、コーディング効率をわずかに低下させますが、JPEG 2000を1桁高速化します。 HTJ2Kは、JPEG 2000の高度な機能を保持し、品質のスケーラビリティを低下させながら、従来のJPEGよりも高速で効率的です。 これは、パート1ブロックコーダーを今日のベクトル化されたコンピューティングアーキテクチャ用の革新的なブロックコーダーに置き換えることによって実現されます。 これにより、レガシーJPEG 2000との間で数学的にロスレスのトランスコーディングも可能になります。パート15は、ロイヤリティフリーを目的としています。 (ttps://jpeg.org/jpeg2000/htj2k.html) JPEG 2000は、劇場上映用のDCP、X線等の医療写真、日本の免許証とパスポートの画像データなどに使われている
263:名無しさん＠お腹いっぱい。
21/02/18 04:06:03.93 4qY3qfYu.net
JPEG XR標準化の経緯
WG1として方式募集をしていたわけでもない時期に Microsoft から提案されたため委員会の内部でも議論があったが，JPEG・JPEG 2000 とのパフォーマンス比較では装置の複雑さも画質も両者の中間に位置していたため，委員会の審議の中で方式の修正要望が生まれた場合はそれに応じること，特許を無償提供すること等を前提とし審議が開始された
(URLﾘﾝｸ(www.y-adagio.com))
JPEG XRはグラフの通り、JPEGとJPEG 2000の間に位置する、そのギャップを埋めるための規格です。……という建前なのですが、実はマイクロソフトから「Windows向けに作ったHDPhotoという方式を標準規格にしないか」という提案があったんです。なので、この規格だけほかのものと成り立ちの性質が異なります。
―JPEGが中心となって各社の技術で策定する、という流れとは逆のフローですね。
はい、そうです。ですから、この規格が使用されているのもほとんどWindows関係となっています。一部ハイエンドな画像編集ソフト(のWindows版)で使える、といったところではないでしょうか。
―JPEG XRの大規模な使用例はあったりするのでしょうか？
僕は聞いたことがないですね。ですが、チップメーカーとかでJPEG XRのチップを作れるようにしているところはいくつかあります。どこかから声がかかった時にすぐ対応できるように、IPコアとしてはもっているようです。あまり華々しい開発・導入の例は聞いたことがありません。
(URLﾘﾝｸ(news.mynavi.jp))
264:名無しさん＠お腹いっぱい。
21/02/18 04:22:38.76 SMqNCNeB.net
JXLはjpeg.GIF.PNGの置き換え狙ってるって書いてあったけどアニメーション対応のPNGとwebpきても特に大きく変わらなかったGIFはまた生き残りそうで嫌だな
256色しか使えないんだから真っ先に終わってくれよ…
265:名無しさん＠お腹いっぱい。
21/02/19 20:47:59.39 16J86dA8.net
>>249
WEBPのターゲット世代は8bitだからJPEGだけだ
WEBP2のターゲット世代は10bit以上だからJPEG XLでHDRのWEBコンテンツが前提
>>245
AndroidはともかくiPhoneはHEIFからJPEG XLにステップアップしそう
HEIFはロイヤリティがねぇ
>>256
GIFは早めになんとかしてほしいわな
APNGでもWEBPでもいいから
266:名無しさん＠お腹いっぱい。
21/02/19 21:04:30.19 16J86dA8.net
Android 12からOSレベルでAVIFのサポートをするんだな
iOSも空気を読んでAVIFをサポートしてくれたらWEBP化を飛ばしてAVIF化でホームページを軽量化出来るんだが
267:名無しさん＠お腹いっぱい。
21/02/20 00:02:05.03 dP8s5t5d.net
>>250
>>252
PIKと違ってWEBP/WEBP2はそこに当てはまらないのよ
Google社内のサービス、例えばGoogle検索/画像検索やGmailでトラフィック削減にWEBPを採用したし
HDRコンテンツの増加に併せてWEBP2を採用するつもりなんだろうけど
Google社外のサービス、例えばwebサイトやAndroidアプリにWEBPやWEBP2の採用を迫ることはない
Google PageSpeed InsightsでもJPEG2000、JPEG XR、WEBPの3つを推奨してくるでしょ
HDRコンテンツが増加したらHEIF、AVIF、JPEG XL、WEBP2あたりを推奨するだけで独占禁止法もクソもない
webマスターがWEBP対応を薦めてるのもGoogleから強制されたわけじゃなくて
ただモダンブラウザで一番サポートが進んでる軽いフォーマットがWEBPってだけなんだよね
268:名無しさん＠お腹いっぱい。
21/02/20 01:29:18.81 ZkaHc3uS.net
jpeg2000,jpegxr推奨といいつつchromeは非対応なんかい!って誰もがツッコミ入れる例のやつやん
結果的に事実上webp一択なんでぶっちゃけ詭弁だと思ってるわ
269:名無しさん＠お腹いっぱい。
21/02/20 02:02:28.65 0FD2xyMr.net
自社規格だけだと体裁が悪いから一応載せておきました感あるよな
270:名無しさん＠お腹いっぱい。
21/02/20 08:58:33.63 t3GEIuO1.net
フレーム間補正が効く動画形式じゃいかんのか
たしかtwitterはgifアニメ投稿するとmp4に自動変換される仕様だったが
271:名無しさん＠お腹いっぱい。
21/02/20 09:01:55.98 t3GEIuO1.net
chromeがjp2とjxrに対応しない理由はなんなんだろう
特許問題があるわけでも無かろうに
272:名無しさん＠お腹いっぱい。
21/02/20 11:35:51.50 yC62hxJv.net
グラフィックビューアは「単に画像を表示できればいい」けど
ブラウザは「Webページ」を「なるべく(他社ブラウザより)高速に」表示しないといけないし
脆弱性対応も必要だし、ブラウザが新たな画像形式に対応するのは
一般人が思っている以上に手間がかかるんだろう
有力企業が、「トラフィックを減らすためにこの形式を使いたい」って
ブラウザ作ってる企業に相談して、ようやく実装されるかどうかなんじゃね？
273:名無しさん＠お腹いっぱい。
21/02/20 12:34:28.14 02JrtNLR.net
>>263
その2つ大して使われないしわざわざ対応も手間、Google的にはwebp推したいし
274:名無しさん＠お腹いっぱい。
21/02/20 15:41:14.48 /1k3T3Vp.net
Googleだけに2000やXRも押し付けようとしてる状態が法的にアレなんだってのがわかんねぇのかな
今はなきIEにWEBP採用しろとかGoogleは言わなかったじゃん
視点がGoogle批判ありきの時点で公平性が担保されてないから独占禁止法なんて語れんのだよ
275:名無しさん＠お腹いっぱい。
21/02/20 15:58:22.15 U8XCe0zg.net
>>260
webp対応しつつその２つ省けばwebpに比べてサポートが進んでないフォーマット扱いできるからGoogleさんは強いね
276:名無しさん＠お腹いっぱい。
21/02/20 19:38:57.49 0FD2xyMr.net
Chrome Platform StatusにJPEG 2000、JPEG XR、HEIFのページは存在しないっぽい
この分だと対応する気は微塵も無さそうだ
277:名無しさん＠お腹いっぱい。
21/02/20 19:44:03.76 0FD2xyMr.net
WebP image format support
URLﾘﾝｸ(www.chromestatus.com)
WebPは、Web上の画像に可逆圧縮と非可逆圧縮を提供する画像形式です。 WebPロスレス画像は、PNGと比較してサイズが26％小さくなっています。 非可逆はJPEGより35％小さいです。
AVIF Image Decode
URLﾘﾝｸ(www.chromestatus.com)
AVIFは、Alliance for OpenMediaによって標準化された次世代の画像形式です。 この機能は、既存のAV1デコーダーを介してブラウザーにネイティブにAVIFコンテンツのデコードサポートを追加することをサポートします。
AVIFをサポートする3つの主な動機�
278:F 1.帯域幅の消費を減らしてページの読み込みを高速化し、全体的なデータの消費を減らします。AVIFは、JPEGやWebPと比較して、画像のファイルサイズを大幅に削減します。 完全に最適化する前に、Netflixはテストセットで結果を公開し、ユースケース全体でJPEGと比較して最大50％の節約を示し、4：4：4コンテンツでは60％を超えました。 2. HDRカラーサポート：AVIFは、WebのHDRイメージサポートへのパスです。 JPEGは、実際には8ビットの色深度に制限されています。 ディスプレイがますます高輝度、カラービット深度、および色域に対応できるようになるにつれ、Webの利害関係者は、JPEGで失われる画像データの保存にますます関心を持っています。 3.エコシステムへの関心：Facebook、Netflix、YouTubeなどは、AVIF画像をWeb上で出荷することに関心を示しています。 MicrosoftとAppleは、基礎となるMIAF仕様に関与していました。
279:名無しさん＠お腹いっぱい。
21/02/20 19:44:36.14 0FD2xyMr.net
JPEG XL decoding support (image/jxl) in blink
URLﾘﾝｸ(www.chromestatus.com)
JPEG XLは、ウェブ上で見られる画質を対象とした新しいロイヤリティフリーの画像コーデックであり、HDR、アニメーション、アルファチャネルなどの最新機能をサポートしながら、同じ知覚品質の元のJPEGと比較して約60％のサイズ節約を提供します。 無損失JPEG再圧縮、無損失およびプログレッシブモード。 これは、GoogleのPIKとCloudinaryのFUIFに基づいており、ISOによる標準化の最終段階にあります。
この機能により、blinkレンダラーでの画像/ jxlデコードのサポートが可能になります
Feature: jxl Content-Encoding URLﾘﾝｸ(www.chromestatus.com)
JPEGXLは次世代の画像形式です。
その機能の1つは、バイト単位のロスレスJPEG画像の再パックです。 平均して、エンコードされた画像は22％小さくなります。
このエンコーディングは、特にJPEG画像転送用のHTTP「コンテンツエンコーディング」として使用できます（このようなコンテンツは、BrotliやGzipなどの汎用フォーマットでは非圧縮性と見なされます）。
提案されたエンコーディング名： 'jxl'
動機
インターネットトラフィックをロスレスで削減します。 インターネットを高速化します。
280:名無しさん＠お腹いっぱい。
21/02/20 20:32:45.67 LZQAkaMx.net
常識的に考えてブラウザ非対応な画像フォーマットを推奨しちゃアカンやろ
いたずらに混乱を招くだけや
281:名無しさん＠お腹いっぱい。
21/02/21 00:31:36.40 rG9lkTl5.net
これからがんば
URLﾘﾝｸ(caniuse.com)
282:名無しさん＠お腹いっぱい。
21/02/21 06:40:53.02 lEHfMoIT.net
＞常識的に考えてブラウザ非対応な画像フォーマットを推奨しちゃアカンやろ
これが独占禁止法に引っ掛かるって話なんだよ
マイクロソフトはXRを、アップルは2000を推してるからそっちもあるよと並べないと
むしろちゃんと選択肢を提示したGoogleが一番まともなんだよ
283:名無しさん＠お腹いっぱい。
21/02/21 08:11:08.40 GiIbaszU.net
アップルはうざがられてもiOSで.heicをデフォルトにしたけど、
グーグルは.webpをAndroidでデフォルトにしないから嫌い。
Android 12で.avifをサポートするけどデフォルトにしないから.heicや.webpみたいにうざがられるのを繰り返すのがが目に見えてる。
284:名無しさん＠お腹いっぱい。
21/02/23 03:45:40.06 iPp3sFSa.net
URLﾘﾝｸ(twitter.com)
(deleted an unsolicited ad)
285:名無しさん＠お腹いっぱい。
21/02/23 04:00:12.90 CbgBQrLy.net
画像フォーマットの単純比較ってあんま意味ないんだよね
用途別に比較しないと求められるスペックが変わるわけだから
クオリティ設定が50くらいで破綻の少ないフォーマットがないと
そう考えたらほんまAVIFつかえねーわ
286:名無しさん＠お腹いっぱい。
21/02/23 06:42:20.60 toaRh6oo.net
>>276
用途別にってのも分かるけどこれは単純にそれぞれがどういう用途に向いてるか考えねって表だと思うよ
そういう意味でここにないgifが生き残りそうで恐ろし
287:名無しさん＠お腹いっぱい。
21/02/24 08:29:47.85 kKgBscch.net
URLﾘﾝｸ(pbs.twimg.com)
288:名無しさん＠お腹いっぱい。
21/02/24 10:58:17.75 ixwtPnF8.net
撮って出しのJPEGとHEIFをWEBP Lossless変換して
ホームページにはWEBPの65、JPEGの60に圧縮してるけど
自分がAVIFを試した範囲だとそんな縮まらないんだよな
JPEG XLに期待してるのは高いクオリティ設定で破綻がないことだから低いクオリティ設定で破綻してもいいんだけど
WEBP2はAVIFより低いクオリティ設定で破綻せず容量減らせるなら何でもいいぞ
289:名無しさん＠お腹いっぱい。
21/02/26 10:35:17.15 /PMSrCTz.net
JPEG XLの比較動画上げてる人( URLﾘﾝｸ(www.youtube.com) )
単なる技術ヲタだと思ってたけど、FLIFの作者だったんだな
290:名無しさん＠お腹いっぱい。
21/02/26 11:55:34.22 iT364BdT.net
>>280
あとjpeg xlにも関わってるよ
URLﾘﾝｸ(sneyers.info)
291:名無しさん＠お腹いっぱい。
21/03/07 23:15:23.26 QAUSVM/O.net
JPEG XLは用途が異なるのにJPEG 2kと機能被ってるから
ROIやpart 9やらが不要ならデコードの早い2kとして使えそう。
near losslessの圧縮率が2kより上がるなら良さそう。
292:名無しさん＠お腹いっぱい。
21/03/20 02:43:43.92 MnnuEyRQ.net
>>279
カメラのこと知らんけどそもそものJPEG HEIFのとこがJPEGXLになったらもっと楽そう
293:名無しさん＠お腹いっぱい。
21/03/20 22:58:25.42 K+RmyWjQ.net
>>283
rawからJPEG XLを作るならともかく
撮って出しにJPEG XLなんて重くて使えん
294:名無しさん＠お腹いっぱい。
21/03/21 01:01:32.00 NE1sIyLy.net
>>284
あれそんな重いんだっけ
295:名無しさん＠お腹いっぱい。
21/03/22 15:09:58.19 rsxwCi06.net
207750 – AVIF decoding support
URLﾘﾝｸ(bugs.webkit.org)
WebKit Bugzilla見てたら最近のナイトリービルドでAVIFデコードが追加されてんのな
JPEG後継画像フォーマットとしてAVIFをiOS15のSafariでサポートしたいんだろうか
AppleもAOMメンバーだしNetflixやらがトラフィック削減にAVIF導入を進めてるからそっちへの対応が目的だろうけど
Android12からそこまで遅れて対応することはなさそう
あとlibavifのバージョンがまだ古いっぽい
296:名無しさん＠お腹いっぱい。
21/03/23 09:56:20.95 bsGVyemy.net
>>285
デジタルカメラの画像処理エンジンってCortex-A7やA9だからね
600MHz程度のデュアル/クアッドコアでエンコードだけじゃなくて、スマートフォンのSoC的役割まで処理しないといけない
だからといって必要以上に処理能力を向上させると、消費電力も増えるから撮影可能枚数が減ってしまう
エンコードの負荷が高くなれば画像処理エンジンの処理能力も上げないといけないんだが
数が出ないデジタルカメラ用の画像処理エンジンを5nmのプロセスルールで作れるわけもなく
JPEG XLに変換しながら10連写や20連写を処理するスペックの画像処理エンジンなかなかハードルか高い
HEIFでさえ自社で画像処理エンジンをやってるキヤノンとソニー以外まだ実現してないんだぜ
297:名無しさん＠お腹いっぱい。
21/03/23 19:10:57.01 VaWqxnxI.net
カメラだと一番使えないのがHEIF
CanonやSONYのHEIFは.hifだけどそのままだとWindowsやMacOS上でまず扱えない
拡張子を.hifから.heifに変えても無理だったりする
JPEGへの変換もCanonならCanonの、SONYならSONYのソフト上でしか行えない
HEIFはライセンスの問題でこんな感じだからライセンスフリーのAVIFが待たれてる
298:名無しさん＠お腹いっぱい。
21/03/23 19:13:57.33 VaWqxnxI.net
URLﾘﾝｸ(dc.watch.impress.co.jp)
この記事が分かりやすい
JPEGの後継画像フォーマットはこういう問題が起きないものじゃないと
299:名無しさん＠お腹いっぱい。
21/03/23 19:28:17.70 VaWqxnxI.net
カメラメーカーはユーザーが数千ドル損失するJPEGを止めるべ�
300:ｫ時だ https://www.dmaniax.com/2019/12/03/heic-kill-jpeg/ カメラに求めるJPEG後継画像フォーマットはまさにこの記事そのまま 報道カメラマンはミリ波5Gスマホと連携させて撮って出しをそのままサーバに送り続ける方向性になってきた だから低クオリティ設定でも破綻しないWEBP2が望まれてる 風景やポートレートカメラマン、スタジオカメラマンは撮って出しよりもRAW現像でゆっくりレタッチするからJPEG XLの高いクオリティ設定が真価を発揮する いままで8bitのJPEGだったから全てのカメラマンを賄えてたけど今後は要望聞いてたら色々対応しないと売れないカメラになる ミラーレス化して電子シャッターで30連写とかの世界に入ったからね
301:名無しさん＠お腹いっぱい。
21/03/24 00:02:24.98 OA+n5Ceq.net
>>287
はえー
HEIFよりjpeg xlのが軽いイメージだったわ>>278見てたから
302:名無しさん＠お腹いっぱい。
21/03/24 01:33:37.39 Yho7/Zj+.net
設定次第では速度はでるな縮まないかもしれんが
URLﾘﾝｸ(docs.google.com)
URLﾘﾝｸ(www.google.com)
303:名無しさん＠お腹いっぱい。
21/03/24 23:58:48.22 GZyYzRpg.net
報道とワールドカップを例にあげるなら
カメラマンの仕事はゴールの瞬間を撮影したらそのまま本部のサーバに画像を転送する事
本部の仕事は予め用意してあるテンプレートに時間や選手名等を書き加えて、サーバに届いた写真を貼り付けたら記事を配信する事
速報記事を配信するまでのワークフローを各社が競ってて、5分とか3分とかどんどん速くなってるのよ
こういう速報記事に求められるスペックは高画質じゃなくて高ワークフローになるわけ
だからJPEGよりエンコード負荷やファイルサイズが大きい時点でHEIFやJPEG XLは向いてない
速報記事だから12bit 444は要らないからJPEGでいいと割りきれるのも大きい
広告やポートレートはより良くより美しく見せないといけないから
10bitや12bitを扱えるHEIFやJPEG XLが求められてるけどね
まあこれはこれでraw現像コースだからバックアップ的な意味合いになるけど
304:名無しさん＠お腹いっぱい。
21/03/26 03:27:47.97 +lgbM6Ht.net
Time誌だっけかな、ドキュメンタリーや密着取材など担当しているカメラマンに対して提出する写真はJPEGのみという決まりを発表してた。 これは写真加工による捏造事件が度々続いたことも原因にあったようだけど、そういう業界ならそのHEIFとか重宝されるのかもしれないね。
305:名無しさん＠お腹いっぱい。
21/03/26 07:35:34.11 H4TbKXin.net
URLﾘﾝｸ(twitter.com)
(deleted an unsolicited ad)
306:名無しさん＠お腹いっぱい。
21/03/26 07:36:18.35 fSg7f8zI.net
URLﾘﾝｸ(twitter.com)
(deleted an unsolicited ad)
307:名無しさん＠お腹いっぱい。
21/03/28 13:18:16.40 O7BoMSD5.net
漫画みたいにモノクロの画像なら多少品質落としてもwebpの方がノイズ少ない？
308:名無しさん＠お腹いっぱい。
21/03/28 23:00:05.19 1KSQwzl+.net
pngで良いんでね？αチャンネル無いともうきついな
309:名無しさん＠お腹いっぱい。
21/03/29 09:59:54.75 rJof7+u7.net
webpってアルファチャンネル使えるやん
310:名無しさん＠お腹いっぱい。
21/03/29 10:54:50.37 XR/RdgiH.net
>>297
311: webpの方が少ないってのは何と比べて？
312:名無しさん＠お腹いっぱい。
21/03/29 10:59:26.72 6lTlCgpe.net
webpは対応画像編集＆CGソフトがまだ少なすぎ。まだまだとても使えない
313:名無しさん＠お腹いっぱい。
21/03/29 12:39:34.26 pogkfgwX.net
>>297
元々大した画質じゃないweb漫画(JPEG)を
画質50のwebpにすると元のJPEGより多少きれいに見える
JPEG特有のもやもやした感じが平均化されるせいだろうな
314:名無しさん＠お腹いっぱい。
21/03/30 17:35:29.61 UG47sKcJ.net
URLﾘﾝｸ(twitter.com)
(deleted an unsolicited ad)
315:名無しさん＠お腹いっぱい。
21/04/01 05:52:35.56 uRSqoRFU.net
It started with all the JPEG-XL fanboys coming in whenever AVIF was mentioned, it being one of the competitors for the title of JPG dethroner. And now that AVIF is getting mainstream support, XL has become the fun underdog story.
草
316:名無しさん＠お腹いっぱい。
21/04/01 09:13:17.25 gnyqT9Co.net
『キングダム ハーツ』一部作品のPC版セーブデータが“PNGファイル”に格納されているのではないかと注目集める
URLﾘﾝｸ(automaton-media.com)
317:名無しさん＠お腹いっぱい。
21/04/01 15:51:57.46 WwgZ+18s.net
一瞬びっくりしたわ
URLﾘﾝｸ(twitter.com)
(deleted an unsolicited ad)
318:名無しさん＠お腹いっぱい。
21/04/05 14:03:25.84 I/Kw5XMP.net
jpeg2000とは何だったのか
319:名無しさん＠お腹いっぱい。
21/04/08 10:03:16.16 H1g44YCn.net
URLﾘﾝｸ(twitter.com)
(deleted an unsolicited ad)
320:名無しさん＠お腹いっぱい。
21/04/17 10:50:16.80 0ZDNCYei.net
大量のスクリーンキャプチャがあって、pngだと容量食うから不可逆webpにしてるんだけど
画像によっては驚くほど容量が減るのな
500KBの画像を50KBにしてもほとんど劣化を感じない
URLﾘﾝｸ(squoosh.app) でjxl化も試してみたけど
不可逆でwebpと同じ容量にしようとすると
webpに負けてるかな
321:名無しさん＠お腹いっぱい。
21/04/17 18:33:15.30 +AGXR7pb.net
いつになったらwindowsのフォトビューワーはwebp対応するんだろうか
322:名無しさん＠お腹いっぱい。
21/04/18 00:53:03.33 XiQj34Ig.net
>>310
「WebP Codec 0.19.9」で検索するとWIC(Windows Imaging Component)用のプラグインがいくつか出てくるが
どこが開発元なのかよく分からんな
323:名無しさん＠お腹いっぱい。
21/04/18 01:29:45.28 XiQj34Ig.net
いや違うか
WebP Image Extension: URLﾘﾝｸ(www.microsoft.com)
を入れればWIC対応アプリならどれでも開けるようになるけど
windowsのフォトビューワーは何故か動きが異なる
324:名無しさん＠お腹いっぱい。
21/04/18 14:44:10.02 fd72RIdG.net
JXR(JPEG XR)はもうこの先ないですかね？
HDRで撮れるのは大きいのですが。。。
325:名無しさん＠お腹いっぱい。
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)
の２段落目くらいに書いてない？
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はどちらも先行技術であるように思われるため、関連する委員会は、そのような主張を行うために単に公開する必要があります。
コメント欄白熱しとるなｗ
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非準拠のパチモンってこと