Windows Media Photoの可能性は？
動画フォーマットがどんどん進歩している中、取り残された
静止画フォーマットの将来について語るスレです。
探検
JPEGの後継画像フォーマットについて議論するスレ
レス数が1000を超えています。これ以上書き込みはできません。
Windows Media Photoの可能性は？
動画フォーマットがどんどん進歩している中、取り残された
静止画フォーマットの将来について語るスレです。
(*‘ω‘ *) ちんぽっぽ
( )
v v
ぼいんっ
川
( ( ) )
最近はタルガばっか使ってますよ、えぇ
＼ __ ／
＿ （ｍ） ＿ﾋﾟｺｰ
|ミ|
／ ｀´ ＼
('A`) ＜そうだ！！
ノヽノヽ
くく
＼ ／
＿ ｀ﾞ｀･;`' ＿ﾊﾞﾁｭ--ﾝ
｀ﾞ｀･;`
／ ｀´ ＼
('A`)
ノヽノヽ
くく
('A`) ＜何だっけ
ノヽノヽ
くく
あとはそれを自動でやってくれるような、仕様を考えればいいんじゃないの？
将来はきっとＪＰＥＧアニメが実現する。
つmpeg
はっはっはっ、この釣り〆っ
a
a
Explorerでサムネイル表示しないけど
どうすればいいの？
デジタル静止画ファイル・フォーマットの標準化組織Joint Photographic
Expert Group（JPEG）は，米Microsoftの「HD Photo」を標準化するかどう
かの検討を開始した。Microsoftが米国時間7月31日に明らかにしたもの。JP
EGは検討作業の是非を問う投票を 10月初めに実施し，作業推進が承認され
た場合は「JPEG XR」（仮称）として標準化に取り組む。
現在広く使われているJPEGの仕様に比べ，画質劣化が少ないにもかかわら
ず最大2倍の圧縮が可能という。可逆圧縮のほか，高画質な非可逆圧縮にも
対応する。複数の解像度に対応し，画像の一部領域を処理対象にできるデコ
ード機能を備える。カラー・バランスや明度などを調整しても元の情報を捨
てないため，調整をやり直せる。
http://itpro.nikkeibp.co.jp/article/NEWS/20070801/278800/?L=top5
JPEG2000がいろいろと駄目すぎたからな……
ＩＥとＰｈｏｔｏｓｈｏｐが対応しないかぎり普及しないんだろうな。
http://www.microsoft.com/japan/whdc/xps/WMPhoto.mspx
これで実装できるん？
ttp://msdn2.microsoft.com/ja-jp/library/system.windows.media.imaging.wmpbitmapencoder(VS.80).aspx
標準化決定らしい
透明・半透明が簡単にhtmlで実現できるし。
でも、実際はこの先当分jpegでずーと行くのはほぼ確実な余寒がするが。
かなり変わると思うがな
その先はCanvasとかSilverLightとか混沌としてるけど
あと10年は確実にjpegのままだな。
デザインする側からするとpngが標準化すれば楽なんだけど、IEは何故に実装しないのかね。
自社製にこだわってるとsilverみたいにドボンするわ〜
圧縮率1/100のときのみjpegより高画質だが、
2/100では同程度、3/100ではjpegのほうがいい。
jpegは注意して見るとモザイクが見えるが質感は保たれる。
jpeg2000はモザイクが無いかわりにのっぺりして質感が失われる。
つ可逆圧縮
JPEG XR，未決定のRAWの取り扱いを今月，東京で議論
2009/02/03 09:06
次世代のJPEGのと期待されている画像符号化規格「JPEG XR」。
その中で未定となっているRAW画像に関する規格策定の議論が，
2009年2月18〜19日に東京で開催されることになった。
JPEG XRにおける中核部分は，2009年1月19〜23日にサンフランシスコで
開催された会合で固まった。既にFCD（委員会最終案）になっており，
2009年後半には，ISO/IECのIS（International Standard）になる予定だ。
ただし，現行のFCDでは先送りとなったのが，RAW画像の取り扱いである。
RAW画像とは，撮像素子が出力した映像信号を，A-D変換した後に
ほとんどそのまま記録した画像のこと。
撮像素子メーカーやカメラ・メーカーなどの意見を，
2月の東京会合で広く募った上で，RAW画像の取り扱いを決めたいと，
JPEG委員会は考えている。（以下略）
IRCかなんかでやれよ
<sasaki> : おいすー
<Sullivan> : オイスー
<sasaki> : みんな来てる？
<Sullivan> : マダ
２、Motion JPEGXR
３、JPEG2000
４、Motion JPEG2000
５、MPEG7
６、MPEG21
IE10、サファリ5、ファイアーフォックス5、オペラ13あたりで対応か？
JPEG XRはMSのとは別のオープンな実装がでてこないと
本格的には広まらんのだろうなあ。
www.itscj.ipsj.or.jp/sc29/open/29view/29n10430c.htm
のZIPファイルをみると、
「コードの大部分はMSが書いたけど、
ITU/ISO/IECがお前にコピーする権利をやろう(ｷﾘ」
って書いてあるんだが。
Makefileの中身見た感じだとUnixでもmake通るんじゃない？
http://gigazine.net/index.php?/news/comments/20101001_jpeg_google_webp/
英語読めないのでよくわからないけど、どうも
http://en.wikipedia.org/wiki/JPEG_XR#Licensing
を見る限り、GPL系のライセンスとは相性が悪いみたい。
こういうあいまいな状況だと、フリーソフトウェア界隈の人たちは近づかないかも。
>>49
2000とXRに加えてさらにWebPまで加わって乱立か。
結局どれも使われなくて……ってオチになりそう。勘弁してほしいわ。
Googleのアナウンスを見る限り、なぜ2000やXRではだめなのかよくわからない。
何も変わらないよ
強いて言うならWebPはJPEGからの再圧縮が優れているかも、ということか。
海外で優劣を検証する人がいるだろうからとりあえずそれ待ちだな。
つまりはWebPも普及しない
MP3の方は永久に無くならないだろうけどJPEGはいつかは置き換わらなければならない日がやってくる
MPEG1だけはようやく消えてくれたんだが････
JPEGは今後20年も主流であり続けるだろう。
MP3は100年たっても主流のまま。
MPEG1は去年あたりに事実上の消滅を迎えた（デジカメの一部に残っていた）
フォーマット的には制限ありまくりのGIFですら
あんだけ大きな特許問題で駆逐されなかったからな
https://sites.google.com/site/dlimagecomp/
とか。
そろそろ対応させるべき時
いよいよ来年に一眼レフデジカメ限定でJPEG XR対応の物が出てきそうな気配
会社HPによる用途として一眼レフとハッキリと書かれているみたいだし
http://internet.watch.impress.co.jp/docs/news/20111122_492827.html
Google、画像フォーマット「WebP」に可逆圧縮と透明度を追加
GoogleがWeb高速化を目的に開発している画像フォーマット「WebP」に、PNGよりファイルサイズを小さくできる可逆圧縮モードと、アニメーションに必要なアルファチャンネル機能が追加された。
http://www.itmedia.co.jp/enterprise/articles/1111/21/news020.html
２、Motion JPEGXR
３、JPEG2000
４、Motion JPEG2000
５、MPEG-4（4k2k対応）
６、HEVC（MPEG5？）
７、MPEG7
８、MPEG21
９、MPEG-A
１０、MPEG-V
１１、MPEG-M
１２、MPEG-U
１３、FTV
１４、HEVC対応オーディオコーデック
IE13、サファリ7、ファイアーフォックス50、オペラ16、Chrome50あたりで対応か？
http://code.google.com/intl/ja/speed/webp/docs/webp_codec.html
http://webp.googlecode.com/files/WebpCodecSetup.exe
RAWがオープンソース化されて各社の互換性が高まればそれでいい。
現状でもPNGがあるので必要ではない
ため、さまざまな編集効果を微調整することができます。元
の RAW ファイルは安全に保管したまま、赤目補正、ノイズ除
去、または詳細な画像の調整を行うことができます。
少なくとも今年は無いであろう。
−最高32bitで保存。JPEG互換性維持
JPEG-HDRと呼ばれるもので、通常のJPEGでは8bitの記録になるが、新フォーマット
では16bitから最高32bitでの保存が可能。同時にJPEGとの互換性を維持しており、
従来のJPEGビューワーでは8bitの静止画として表示できる。
http://av.watch.impress.co.jp/docs/news/20120227_514884.html
と言う高性能で搭載されたデジカメは2013年半ば以降に出るかもしれない。
今年・・・いや今年度はまたしてもJPEG XR対応デジカメは出ないと予想される。
今から一年強先を期待して待ちましょう。
動画圧縮は進歩しているのに、なぜ画像圧縮は進歩していないのか？
画像はスペックを要求されることを良しとしないからでしょ。ネット上では。
CPUに負担をかけない圧縮解凍技術が進めば話は別だけど。
その程度だと変わるよりそのままの可能性高いでしょ
しかもjpegの主戦場は200k〜1.5Mとなると変化と諸々考えると中々厳しい
仮に圧縮率20%ダウンで解凍負荷同じか10%程度下がるのでは厳しい気が。
圧縮率40% 負荷は70%軽い位じゃないと厳しいだろうけど圧縮率が厳しいので無理。
そうなるとjpegはそのまま放置で 高解像度向けか可逆がターゲットにしかならん気がする。
jpeg 2kって結局中途半端で消えかかってるのか・・。、、
驚くべき事に今現在でも重い
この規格を作ったのは誰だと雄山が怒鳴り込むレベル
動画圧縮を流用したWEBPや、動画圧縮そのもののH.264のIフレーム圧縮と、JPEGを比較する時に
そういう画像を使うと差がわかりやすくなる
JPEG2000? あ、うん…。
画像の圧縮率を高めようという要求が弱いのかもわからんね
しかし、デジカメの画素数もどんどん増加しているし、いつまでも旧い規格のままでいいとは思えないんだが
圧縮解凍技術の需要は高まるはずなんだけどね。
ベクタートレースがもっと進歩すればなあ〜FLASH衰退しちゃったからな
今なんかかなりフォトリアルなトレースできるようになったのに…
３Dトレースみたいな流れになるには10年は掛かるだろうし
jpgで95くらいにした時の3倍くらいになる
これはでかい
jpgあるいはpngの高効率化が求められる
ハードウェアは進歩しているのだからできないはずはない
一応pngは改善出来る
とは言ってもpngはbig gifみたいもんだが
jpegは十分小さいって事も有り進化する必要が無いが痛い所。
非可逆pngが内包されればついでに高圧縮化はありそうだと思うけど
代わりって無い気が・・・する気も。
次世代jpeg=jpegを廃止(更新されない状態)なんじゃないですかね。
今すでにそうな気もしますがw
どうしてそれが普及しないの？てのが謎なの
納品の諧調を増やしたくないということ。
劇的に容量が減らない限りjpegは駆逐出来ないカメラにはrawが有る
認知度が凄まじい。
「jpeg=ジャンプ」 みたいもんで取り敢えず安心感みたいな物が有るんだろう。
取り敢えず面倒なことも事実として少ない訳で。
xr win標準だとしてもmacに渡せば標準では無いしlinuxでもそうでしょ
ニッチosに渡すとは言え完結した世界では無いならその点は足を引っ張る。
カメラがニッチとは言ってもそれは完結出来るから有りな訳ですから。
おかしいよ
JPEGとMP3はしぶとい
web静止画がモニター上同サイズで4倍の解像度って時代が来るならより高圧縮と言う道が有るだろうけど
1M以下を主戦場にもって来ている関係互換がどうの考えなくて良い強みがどうしても付きまとうもんなのかと。
可逆png/gifにやや大きいjpegってセットでwebは固まっているからそれ以上必要ないって所が大きいのかもね。
ただニッチ方向では解像度有る訳なのでそちらがわからはjpeg以上の規格って作られていくべきだとは思うんだよね。
メガ単位になれば10%でも当然変化が大きいし
jpeg2000 xrがすっかりコケたのは不思議な話。
確かにまぁ・・・手軽では有るしこの大容量の時代だと手軽なサイズなんだがね。
しかしjpegとmp3は質が高くない割にしぶといね。
ましてやこれ以上情報量増やして回線パンクさせたら世界中で従量制移行がマジ話になる。
PCに限らず、カメラとかだってそうだろうし
今は最安のコンデジでもH264のリアルタイム録画できるんだから
>ましてやこれ以上情報量増やして回線パンクさせたら世界中で従量制移行がマジ話になる。
と言うなら逆に新しいフォーマットが居るよな。
その他=jpeg カメラ=XRってだけで10年位たってようやくXRもそこそこ標準だよねって未来だと思う。
海外じゃブラウン管が現役ばりばりで使われてる所なんてザラだし
回線もほとんどkbpsレベルだからな
どうであれ、機器のスペックが足りないというのが画像圧縮の進歩を阻んでいる主因ではないよね？
まあ確かに画像フォーマットの趨勢にはあんま関係ない話か
高圧縮の画質はjpegよりかなりよくなってる
けど低圧縮だとあまり変わらない感じ？
jpegと比べるとモスキートノイズは少ないけど低周波がぼやける
２、ファイアーフォックスがJPEG 2000とTIFFとPNGに対応する事
３、オペラがTIFFとPNGに対応する事
これだけでかなり改善できる
ファイアーフォックスはPNGは対応済みJPEG 2000とTIFFはまだ
１、SafariがJPEG XRに対応する事
２、ファイアーフォックスがJPEG 2000とTIFFとに対応する事
３、オペラがTIFFに対応する事
これだけでかなり改善できる
動画ファイルの最初の1フレーム目を画像として表示する機能を
ブラウザが付ければ、それであらゆる問題が解決するのに。
>イントラフレームを利用する静止画用の「Main Still Picture profile」
フェードインがあると真っ黒になるだろ
http://jp.techcrunch.com/archives/20130207google-now-uses-its-own-webp-format-instead-of-pngs-in-the-chrome-web-store/
FirefoxがH.264に対応決定
次はAACとドルビーデジタルAC3、そして、TIFFとPNGとJPEG 2000対応の番だな。
Firefoxは昔から対応コーデックが全てにおいて少なすぎだ。
Safariなんかは逆にすべて対応しているんだし。
でもJPEGなんて確か80年代の技術だろ？
それよりはマシ
ミドルレンジのコンデジはJPEG XRとJPEG 2000の両対応
ハイエンドのコンデジはJPEG 2000
一眼レフはJPEG 2000とRAWの両対応
JPEGはスマホからもさっさと消えてほしい
JPEG 2000
RAW（DNG含む）
H.265のMain Still Picture profile
の4つが普及するのが望ましい
他はPNGとTIFFとBMPだけは生き残ってもいい
でもJPEGやGIFは消えるべき。
さらに、標準APIで読み書きできるようにして。
GIFのせいだけどな
普及しないのはほとんどアドビのせい
ロスレスはWebPがよさげ
Freesoftでレタッチ（サイズ修正）して保存できるソフト名というか
対応表ないの？
最低でもFreesoftで対応していない（特定のみ対応じゃ糞）んじゃ議論以前の問題だよ。
気のせいなのだろうか?…PNGだと感じないけど容量がでかいんだよねー…
何でエンコしてるの？
http://uproda.2ch-library.com/8260026D2/lib826002.png
同じ絵だけど、ツイッターに上げた時初めて違和感を感じた
エンコードが悪かったって事なのかな?
しかし色空間を4:4:4にすればjpgでも色の劣化は起きないよ
圧縮設定を変えられないソフトなら別のソフトで圧縮しよう
4:4:4で保存するとなるとPhotoshopとかになりそうだな
数値はいじれないよなぁー
あと凄く劣化に気づいたのがツイッターに上げた時だから、ツイッターにエンコードでさらに劣化したのかも
twitter側で強制的に4:2:0ダウンサンプリングしているのかも
元画像→ttp://f.st-hatena.com/images/fotolife/a/animencode/20140920/20140920065114.jpg
結果→ttp://pic.twitter.com/hcrjEqllKB
twitterにjpgで上げるとすさまじい低画質にされるから
できればpngで上げたほうがいいよ
もしかしてツイッターってピクセルが小さいと無理やり引き延ばしたりする?
もとは変えないよ
解像度の低い画像ではサイズ小さくならない上に劣化が目立つのね。
jpegで再圧縮かけるよりはマシなんだろうけど。
メインの環境がlinuxだから本当はwebp使いたいんだけど、imagemagick(とその仲間)でしか
開けなかった(なぜかxnviewでも開けない)し、jpeg 2000はimagemagick以外でも表示はできるけど
デコードが重いしで、jpegXRでやってみることにした。
iso規格になってるのにほとんどのトリで開けないのには笑ったが。どんだけマイクロソフト嫌い
なんだよ。
better portable graphic BPG
h-265の静止画向けプロファイル使ったやつ。
susieで変換できる？
susieでできるかは知らないけど、windowsならhoneyviewとかいうビューアー
ソフトでguiを使って閲覧･変換できる。
ありがと、早速使ってみるお
GIFのこと忘れたのか?
いまのところmpeg-laが黙ってるのが気味悪いな。
流行るの待ってるのかもしれないね。流行ってからドーンと。
bpgの開発者のページには、心配ならh265に対応してるハードウェアと一緒に使えと
書いてあるな。
ハードウェアにアルゴリズム実装する段階でライセンス料は支払われてるよね?って
スタンスのようだ。
あとは自分の周囲だけで世界が完結してるからとか。
ネットワークではトラフィックの削減のために必要なんだよな
動画に比べたら誤差みたいな差の為にフォーマット移行とかめんどくさすぎ
可逆、アルファ、アニメーションが出来るようになったし
不可逆ではjpegより圧縮率はいいし、
可逆ではpngより圧縮率がいい。
それにもともと動画の技術の転用なら、デコード負荷も問題ないはず
多量のページの電子書籍なんかだと
プリロードが追いつかないとめくりでもたつくんだから
すべての電子書籍で目次がついていればいいけど
目次がついているものばかりじゃないからね
ハードウェア再生支援はiosだとvp9・webpには効かなかったようだから
デコード速度が気になるんだ
Time to read input: 0.149s
Time to encode picture: 1.493s
非可逆デコード
Time to decode picture: 0.136s
Time to write output: 0.666s
可逆エンコード
Time to read input: 0.151s
Time to encode picture: 25.095s
可逆デコード
Time to decode picture: 0.279s
Time to write output: 0.694s
なお低スペ
展開時間より読み込み時間のほうが長いわ
同一ファイルを元に、最新のエンジンを使って作られた、jpeg、jp2と比較したデコード速度比較でないと
単独の数字じゃ早いのか遅いのかわからないね
jpeg xrとwebpだとややwebpが速いくらい。
でもどちらもjpegに比べると体感できるレベルで遅い。
bpgはhoneyviewで試した限りは速い。
jpeg 2000レベルで画質に不満はないのだけど、デコードが遅すぎるので
使う気が失せたくらい。
ちなみに、以下ページで利用されてるpsb(PhotoShopBigdocument)
だと最大300,000x300,000pxまでしか対応してないから困るんだよな…
(´・ω・`)
http://www.eso.org/public/images/eso1242a/
JPGE 2000で写真撮影をする金星探査機あかつきが金星周回軌道に到達した。
これから公開される写真はJPGEじゃないんですJPEG 2000で撮影した物になるんですよ。
赤外線カメラと紫外線カメラしか搭載されておらず可視光カメラは搭載されていませんので
カラ―画像じゃないですけど・・・・
http://jda.jaxa.jp/category_p.php?lang=j&;page=&category1=256&category2=306&category3=308&page_pics=50
見事にすべて白黒です・・・金星に可視光カメラ持って行っても仕方ないけどJPEG 2000の実力を見せてもらいましょう
お世話になります。
私、責任者の加茂と申します。以後、宜しくお願い致します。
http://homepage2.nifty.com/e-d-a/scurl/ays.html
http://homepage2.nifty.com/e-d-a/scurl/SW-pos.html
http://homepage2.nifty.com/e-d-a/scurl/SW-sp.html
http://homepage2.nifty.com/e-d-a/scurl/SW-BB8.html
浪速建設様の見解と致しましては、メールによる対応に関しましては
受付しないということで、当初より返信を行っていないようで、今後につい
てもメールや書面での対応は致しかねるというお答えでした。
http://www.o-naniwa.com/
このように現在まで６通のメールを送られたとのことですが、結果一度も
返信がないとう状況になっています。
http://homepage2.nifty.com/e-d-a/scurl/ia-1-3.html
http://homepage2.nifty.com/e-d-a/scurl/ia-2-1.html
http://homepage2.nifty.com/e-d-a/scurl/ia-3-1.html
私どものほうでも現在までのメール履歴は随時削除を致しております
ので実際に１１通のメールを頂戴しているか不明なところであります。
●クリスタル通り122号室の入居者
●浪速建設 女事務員 南野 東条 ●アパマンショップ八尾店 加茂正樹
!!!!!!!!!!!!!!!
http://gigazine.net/news/20170815-jpeg-xl-call-for-draft/
参考までに、
⇒ 『半藤のブブイウイウレレ』 というサイトで見ることができます。
グーグル検索⇒『半藤のブブイウイウレレ』
T97QMMLPDD
AV1とAVIF（エイヴィフ）
後者はロイヤリティフリーで賛同企業も多そうだし、これが普及するかもね
編集ならほかの形式でやりゃいいんだから
変換だけでいいんだからなんとかどっか対応してほしい
Androidで2MBくらいのwebpの写真を読み込ませると、細部までくっきりするのに10秒以上かかる。jpegなら5MBでも一瞬でくっきりするのに
容量削減のためにデコード時間が伸びるなんて本末転倒もいいとこだわ
同じだよ
スキャンした1200dpi 2L判の写真をq=80にしてgalaxy s9+で表示させてる
だからHEIFに統一しようと思ったけど
heic to jpeg コンバータあるのに逆はないのね
どうしよう
今後はウェッピーからエイビフって流れになりそう
無料でロスレス圧縮＆プログレッシブ表示もサポートしPNGより40％以上も高圧縮な画像フォーマット「FLIF」
https://gigazine.net/news/20160308-flif/
この技術がJPEG XLに採用されている
https://www.reddit.com/r/AV1/comments/fjddcj/comment/fkowjqf
https://pbs.twimg.com/media/EgbuWJYUYAEs7YJ.png
https://mevius.5ch.net/test/read.cgi/avi/1581244349/
>794 名無しさん＠編集中 (ﾜﾝﾄﾝｷﾝ MM23-U561) sage 2020/08/24(月) 22:22:20.54 ID:R5XaRWk7M
>次世代画像フォーマット 〜 AVIF と JPEG XL 〜
>https://docs.google.com/presentation/d/1Vuq1WclKNBxiRd6znT7g-XyugwQA4FwqsyHRL8FlEFw
>なんかJPEG XLの方が本命っぽいんだよな
>・JPEGと相互互換性あり
>・エンコードもデコードも速い
>・プログレッシブ対応やレスポンシブウェブデザインのWebと相性良い
>・バックにGoogleがいる
>Googleは検索エンジン最適化(SEO)という最強の生殺与奪権を持っている
>今はSEO対策でWebPを採用してPageSpeed insightsの評価点数を上げることが重視されている
>なおPageSpeed insightsの内部ロジックであるLighthouseに次世代画像フォーマットへの対応(Serve images in next-gen formats)という監査項目がある模様
>JPEG XLを最高得点に設定すれば世代交代を促進できる
>得点の低いであろうJPEG,GIF,PNG等々レガシー規格はインターネットの表舞台から姿を消すに違いない
こマ？
JPEG XL、普通のJPEGよりエンコードもデコードも早いってマジか
アニメーションやアルファチャンネルも扱えて無印JPEGからの無欠損再圧縮変換できてその逆変換もできる
ぼくがかんがえたさいきょうのJPEGだ…
https://jakearchibald.com/2020/avif-has-landed/
プログレッシブJPEGとWebPとAVIFのレンダリング速度比較が興味深い
Format : Maximum Image Dimensions
(in a Single Code Stream) Maximum Bit Depth,
Maximum Number of Channels
JPEG : 4,294 megapixels (65,535 x 65,535) 8-bit, three channels (or four for CMYK)
PNG : Theoretically 4 exapixels
(but no way to efficiently decode crops) 16-bit, four channels (RGBA)
WebP : 268 megapixels
(16,383 x 16,383) 8-bit, four channels (RGBA)
HEIC : 35 megapixels
(8,192 x 4,320) 16-bit, three channels
(alpha or depth as separate image)
AVIF : 9 megapixels
(3,840 x 2,160) 12-bit, three channels
(alpha or depth as separate image)
JPEGXL : 1,152,921,502,459 megapixels
(1,073,741,823 x 1,073,741,824) 24-bit (integer) or 32-bit (float),
up to 4,100 channels
https://youtu.be/UphN1_7nP8U
Appleが乗り気になったからWEBPが普及する道筋が出来たけど
Firefox 86でAVIFを正式サポート
Android版Chrome 89でAVIFを正式サポート？
AppleはAVIFにもやる気を出してほしいね
AVIFの先はJPEG XLに期待していない
WEBP2の方がまだ期待できる
イラスト用途ならいいんだけど
JPEG、GIF、PNGを終わらせてほしいとかどこの素人だよ
JPEG XL推しきっしょ
＞互換性あってデコードエンコード早いjpegXLにjpegを終わらせてほしい、ついでにgifとpngも
AV1スレやWebPスレでもこんなしょーもないノリでJPEG XL凄いを連呼してるのはきっしょいじゃん
S1とS2に分類して各規格の開発目的が異なる意味すらわからないただのバカだからね
やってることは荒らしと変わらん
特にJPEGはデジタルカメラやスマートフォンカメラの保存形式として一般的
最近ではiPhoneカメラ、デジタルカメラならソニーとキヤノンがHEIFを保存形式として採用してる
JPEG XLはJPEGやHEIFのユーザーフレンドリーな後継として策定されたものになる
WEBP、AVIFはウェブマスターフレンドリーな画像フォーマット
WEBPはモダンブラウザでのサポートが始まって、AVIFもAOmediaを中心にサポートの動きがある
こちらはユーザーフレンドリーな用途ではなく、WEBサイトや検索トラフィックの最適化がメイン
スマートフォンでもHDR対応ディスプレイが普及していくとWEBPでは十分な最適化が出来ないからWEBP2の策定を目指してる
JPEG XLがアルファードならWEBP2はカローラみたいなもんで用途が違う
他にもいるけど全世界の総トラフィックの8割近くが動画だからNetflixがAV1とAVIFに入れ込みすぎなんよー
The Joint Photographic Experts Groupが有名無実になる一方で元気すぎるAlliance for Open Mediaのパワープレイはそれはそれでつまらん
PILとかImageMagickとかで変換できるようになってくれればそれでいい
別にWebで普及しなくても一向に構わんし、
編集ソフトが対応してくれなくてもまぁ大きな問題はない
av1スレとwebpスレってどこ？
それなのにJPEGの後継語るスレでwebp2とかavifに期待してる人がいるの不思議
そういう方向性ならJPEG XLは普及すると思うよ
>>219
JPEGの後継フォーマット=JPEG策定の新フォーマットではないのに何言ってんだか
このエンジニアの説明がWebP画像の導入例として非常にわかりやすい
JPEG→WebPに変換して表示することでトラフィック削減による3列化を実現した
HDR10とか444とかリッチなコンテンツをJPEG XLで作成・編集→WEBサイトではWEBP2で表示してSEO対策みたいになるだけ
JPEG XLとWEBP2は一蓮托生
たられば無いものねだり
2.普通の人
既に有るものを有効活用
3.有能な人
無いものは自分で作っちゃう
4.社会から必要とされる人
業界で技術OEM売買案件を手がけ
3.の人に仕事と売上を作ってあげる
学生の皆さん
4.の人になれるよう頑張って下さい
1.はイカ臭い子供部屋の囚人になっちゃうよ？
AV1スレの荒らしｽﾌﾟｰ(Sd**-****)と同一人物っぽいなｗ
何が彼をここまで必死にさせたのだろう？
なんとでも言えばいいけど
俺は「ぼくがかんがえたさいきょうのJPEGだ…」とか論理の欠片もないJPEG XLを持ち上げを馬鹿にしてるだけだから
馬鹿にされてることを敵愾心だと思うなら君はそれでいいんじゃない？
フォーマットなんて使われて初めて意味があるわけで
俺は散々「WebP2は将来的にHDR画像がトラフィックを食うから、その対策として開発を進めてる」と言ってるわけで
JPEG XLがどんな目的で使われるかを明確に返せないのに最強最強と連呼してる奴は馬鹿じゃん
high-quality imagesでの圧縮効率が良好なのに対して
target qualityを下げたときの圧縮効率が思ったよりも良くない
だからtarget qualityが低めでページ表示速度を上げられるWEBP2が開発されてる
HDR画像が標準になるとJPEGとWEBPの関係以上にtarget qualityをどこに置いてるかが大事
例えばEOSやαのHDR画像がHEIFからJPEG XLに移行したとして
ホームページで使うにはJPEG XLのままでは重いからWEBP2に変換する
そもそもWEBPのロスレスとかJPEGが関係してるように
JPEG XLとWEBP2の補完関係が今より 強化されたわけ
iPhoneはそこまでのはいらんから.heicのままかな
WEBサイトも.webp2に食われる運命だろうから.avifが一番いらんかもな
その1行に効きすぎじゃないか
その程度のノリで書いたやつなんてもうこのスレのこと忘れてそうだから気にすんな
それ以外の未だにjpegとかpng使ってるとこ向けの後継にjpeg xl
って各々向かってるイメージだけどAVIFはライセンスが面倒なHEIFの代わり？
PNG(ピング)
GIF(ジフ)
WEBP(ウェッピー)
HEIF(ヒーフ)
AVIF ← こいつ
読み方はエイビフとかエービフでええんか？🦐🍤🦐🍤
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が対応したらモダンブラウザ制覇だけど存在が中途半端すぎんのよ
https://news.yahoo.co.jp/articles/bedb562e414372ad404561135abe4fcc629e1ba7
JPEG XL専門部会の共同議長を務めているスナイアーズ博士が考案したFLIF（Free Lossless Image Format）は、一部がJPEG XLのベースになっている。同博士の画像処理技術「Muscles from Brussels」は最適化された画像を超高速で配信するのに役立つ。
JPEG XLは、広い色域、高いダイナミックレンジ、深いビット深度、アニメーション、アルファチャンネル、レイヤー、サムネイル、ロスレス、プログレッシブコーディングなどの機能が含まれ、幅広いユースケースをサポートする。新しいアプリケーション向けには360度画像、画像バースト、大きなパノラマやモザイク、印刷をサポートする。
JPEGとは異なり、写真だけではなくそれ以外（イラスト、スクリーンショット、ゲームグラフィックス、地図など）も設計の対象になっている。
JPEG XLには、依然72％のWebサイトで使われているJPEG画像からの変換機能も幾つか含まれている。これによりストレージ（単一のJPEG XLでJPEGクライアントとJPEG XLクライアントの両方にサービスを提供できる）とファイルサイズ（既存のJPEGファイルをロスレスでJPEG XLに変換できる）を削減できる。
JPEG XLは、計算効率の高いエンコードとデコード用に設計されている。JPEG XLはモバイル端末でもハードウェアアクセラレーションを必要としないソフトウェア実装を使用する。
このコーデックの次期バージョン「JPEG XL 0.2」のフリーズは目前に迫っている。フリーズの時点で、過去と将来の全てのJPEG XL画像は今後のバージョンのコーデックと互換性があることになる。JPEG XLを試すとしても、大規模な採用は2021年に最終草案国際標準が提出されるまで待つことをお勧めする。
QUICのRFCも今年中に出そうだな
Web漫画廻りが捗るな
https://twitter.com/jonsneyers/status/1360524517244870660?s=20
https://twitter.com/5chan_nel (5ch newer account)
まあCloudinaryが規格設計に関わってるから当然か
CDNプロバイダがJXLエコシステムに強い関心を持ってるっていうのは普及に向けて好材料だな
ウェブブラウザのサポートは大前提としてCDNプロバイダ側の移行アプローチも重要になるだろうから
LINEスタンプの形式もapngからjxlに移行するといいなぁ
個人的にはredgifも早めに綺麗な方に移行してくれると嬉しいな
>Multithreaded and SIMD-optimized decoding
前者はgoogle/pik、後者はgoogle/highway実装だそう
phoronix-test-suiteのベンチマーク結果ではマルチスレッド/マルチコアCPUデコード速度の効果がよく出ていた
10bit/HDR表示できるスマホディスプレイ然り
10bit/HDR環境が汎用デバイスにも進出し始めたので撮って出しできる10bit/HDR対応静止画フォーマットの需要が今後更に高まってくると思うな
林檎製品もそうだけど現時点ではHEIFしか選択肢が無いのかもしれない
>It's also our first mobile platform with true 10-bit HDR photo capture
だそうな
HEIFは符号化方式の構造上複雑な処理を捌く強力な画像処理プロセッサが必要だったり特許料が必要だったりとにかくコストが掛かると聞いていたけど
ここにきてHEIF採用の兆しが
webp2は名前のまんまwebpの後継で小さいサイズで活かすつもりでJPEG XL対策ではないと思うな、AVIFが半端なのは同意だけど
https://chromium.googlesource.com/codecs/libwebp2/
翻訳かけたら WebP2は現在、部分的にしか最適化されておらず、非可逆圧縮の場合、WebPよりもおよそ5倍遅くなっています。それでもAVIFより2倍速く圧縮しますが、解凍には3倍の時間がかかります。目標は、解凍速度の同等性に到達することです。
ってあるから気長に待とうかな
10年前と違い今は独禁法問題で米当局の目が厳しくなってるから検索エンジン最適化の濫用は避けるべきでISO/IEC, IETF, AOMなどの標準化団体に技術提供するという近年の方針は理に適っていると思う
AV1はISOBMFF(MP4)なんだよな
もう自社独自規格に拘るような時代じゃないんやな
自己レス訂正CoP→PoCだわ
素直に概念実証って書けばよかったorz
Googleは技術実証の結果デファクトを取った後もデファクトのまま終わらず標準化まで持っていく印象がある
独自規格の囲い込みで儲けようとするイメージも無いから個人的にはそこに関してevilな感じはしないと弁明しておく
これか
https://openbenchmarking.org/test/pts/jpegxl-decode&;eval=e5f9d1dd0071b40ed42ed9ce4da29460ac63af4f
Part 15(High Throughput JPEG 2000)では，EBCOTの弱点であった計算負荷の高さとそれに起因する低スループットおよびバッテリー消費量の問題を解決するべく，新しいブロック符号化アルゴリズムが標準化された．若干の圧縮効率の低下と引き換えに，10倍以上のスループット向上が達成されている．また，決して並列化向きのアルゴリズムではなかったEBCOTとは異なり，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線等の医療写真、日本の免許証とパスポートの画像データなどに使われている
WG1として方式募集をしていたわけでもない時期に Microsoft から提案されたため委員会の内部でも議論があったが，JPEG・JPEG 2000 とのパフォーマンス比較では装置の複雑さも画質も両者の中間に位置していたため，委員会の審議の中で方式の修正要望が生まれた場合はそれに応じること，特許を無償提供すること等を前提とし審議が開始された
(ttp://www.y-adagio.com/public/committees/std/confs/std14/std14-3.pdf)
JPEG XRはグラフの通り、JPEGとJPEG 2000の間に位置する、そのギャップを埋めるための規格です。……という建前なのですが、実はマイクロソフトから「Windows向けに作ったHDPhotoという方式を標準規格にしないか」という提案があったんです。なので、この規格だけほかのものと成り立ちの性質が異なります。
――JPEGが中心となって各社の技術で策定する、という流れとは逆のフローですね。
はい、そうです。ですから、この規格が使用されているのもほとんどWindows関係となっています。一部ハイエンドな画像編集ソフト(のWindows版)で使える、といったところではないでしょうか。
――JPEG XRの大規模な使用例はあったりするのでしょうか？
僕は聞いたことがないですね。ですが、チップメーカーとかでJPEG XRのチップを作れるようにしているところはいくつかあります。どこかから声がかかった時にすぐ対応できるように、IPコアとしてはもっているようです。あまり華々しい開発・導入の例は聞いたことがありません。
(ttps://news.mynavi.jp/article/jpeg-5/)
256色しか使えないんだから真っ先に終わってくれよ…
WEBPのターゲット世代は8bitだからJPEGだけだ
WEBP2のターゲット世代は10bit以上だからJPEG XLでHDRのWEBコンテンツが前提
>>243
AndroidはともかくiPhoneはHEIFからJPEG XLにステップアップしそう
HEIFはロイヤリティがねぇ
>>254
GIFは早めになんとかしてほしいわな
APNGでもWEBPでもいいから
iOSも空気を読んでAVIFをサポートしてくれたらWEBP化を飛ばしてAVIF化でホームページを軽量化出来るんだが
>>250
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ってだけなんだよね
結果的に事実上webp一択なんでぶっちゃけ詭弁だと思ってるわ
たしかtwitterはgifアニメ投稿するとmp4に自動変換される仕様だったが
特許問題があるわけでも無かろうに
ブラウザは「Webページ」を「なるべく(他社ブラウザより)高速に」表示しないといけないし
脆弱性対応も必要だし、ブラウザが新たな画像形式に対応するのは
一般人が思っている以上に手間がかかるんだろう
有力企業が、「トラフィックを減らすためにこの形式を使いたい」って
ブラウザ作ってる企業に相談して、ようやく実装されるかどうかなんじゃね？
その2つ大して使われないしわざわざ対応も手間、Google的にはwebp推したいし
今はなきIEにWEBP採用しろとかGoogleは言わなかったじゃん
視点がGoogle批判ありきの時点で公平性が担保されてないから独占禁止法なんて語れんのだよ
webp対応しつつその２つ省けばwebpに比べてサポートが進んでないフォーマット扱いできるからGoogleさんは強いね
この分だと対応する気は微塵も無さそうだ
https://www.chromestatus.com/feature/6471725441089536
WebPは、Web上の画像に可逆圧縮と非可逆圧縮を提供する画像形式です。 WebPロスレス画像は、PNGと比較してサイズが26％小さくなっています。 非可逆はJPEGより35％小さいです。
AVIF Image Decode
https://www.chromestatus.com/feature/4905307790639104
AVIFは、Alliance for OpenMediaによって標準化された次世代の画像形式です。 この機能は、既存のAV1デコーダーを介してブラウザーにネイティブにAVIFコンテンツのデコードサポートを追加することをサポートします。
AVIFをサポートする3つの主な動機：
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仕様に関与していました。
https://www.chromestatus.com/feature/5188299478007808
JPEG XLは、ウェブ上で見られる画質を対象とした新しいロイヤリティフリーの画像コーデックであり、HDR、アニメーション、アルファチャネルなどの最新機能をサポートしながら、同じ知覚品質の元のJPEGと比較して約60％のサイズ節約を提供します。 無損失JPEG再圧縮、無損失およびプログレッシブモード。 これは、GoogleのPIKとCloudinaryのFUIFに基づいており、ISOによる標準化の最終段階にあります。
この機能により、blinkレンダラーでの画像/ jxlデコードのサポートが可能になります
Feature: jxl Content-Encoding https://www.chromestatus.com/feature/5678152091172864
JPEGXLは次世代の画像形式です。
その機能の1つは、バイト単位のロスレスJPEG画像の再パックです。 平均して、エンコードされた画像は22％小さくなります。
このエンコーディングは、特にJPEG画像転送用のHTTP「コンテンツエンコーディング」として使用できます（このようなコンテンツは、BrotliやGzipなどの汎用フォーマットでは非圧縮性と見なされます）。
提案されたエンコーディング名： 'jxl'
動機
インターネットトラフィックをロスレスで削減します。 インターネットを高速化します。
いたずらに混乱を招くだけや
https://caniuse.com/jpegxl
これが独占禁止法に引っ掛かるって話なんだよ
マイクロソフトはXRを、アップルは2000を推してるからそっちもあるよと並べないと
むしろちゃんと選択肢を提示したGoogleが一番まともなんだよ
グーグルは.webpをAndroidでデフォルトにしないから嫌い。
Android 12で.avifをサポートするけどデフォルトにしないから.heicや.webpみたいにうざがられるのを繰り返すのがが目に見えてる。
https://twitter.com/5chan_nel (5ch newer account)
用途別に比較しないと求められるスペックが変わるわけだから
クオリティ設定が50くらいで破綻の少ないフォーマットがないと
そう考えたらほんまAVIFつかえねーわ
用途別にってのも分かるけどこれは単純にそれぞれがどういう用途に向いてるか考えねって表だと思うよ
そういう意味でここにないgifが生き残りそうで恐ろし
ホームページにはWEBPの65、JPEGの60に圧縮してるけど
自分がAVIFを試した範囲だとそんな縮まらないんだよな
JPEG XLに期待してるのは高いクオリティ設定で破綻がないことだから低いクオリティ設定で破綻してもいいんだけど
WEBP2はAVIFより低いクオリティ設定で破綻せず容量減らせるなら何でもいいぞ
単なる技術ヲタだと思ってたけど、FLIFの作者だったんだな
あとjpeg xlにも関わってるよ
http://sneyers.info/
ROIやpart 9やらが不要ならデコードの早い2kとして使えそう。
near losslessの圧縮率が2kより上がるなら良さそう。
カメラのこと知らんけどそもそものJPEG HEIFのとこがJPEGXLになったらもっと楽そう
rawからJPEG XLを作るならともかく
撮って出しにJPEG XLなんて重くて使えん
あれそんな重いんだっけ
https://bugs.webkit.org/show_bug.cgi?id=207750
WebKit Bugzilla見てたら最近のナイトリービルドでAVIFデコードが追加されてんのな
JPEG後継画像フォーマットとしてAVIFをiOS15のSafariでサポートしたいんだろうか
AppleもAOMメンバーだしNetflixやらがトラフィック削減にAVIF導入を進めてるからそっちへの対応が目的だろうけど
Android12からそこまで遅れて対応することはなさそう
あとlibavifのバージョンがまだ古いっぽい
デジタルカメラの画像処理エンジンってCortex-A7やA9だからね
600MHz程度のデュアル/クアッドコアでエンコードだけじゃなくて、スマートフォンのSoC的役割まで処理しないといけない
だからといって必要以上に処理能力を向上させると、消費電力も増えるから撮影可能枚数が減ってしまう
エンコードの負荷が高くなれば画像処理エンジンの処理能力も上げないといけないんだが
数が出ないデジタルカメラ用の画像処理エンジンを5nmのプロセスルールで作れるわけもなく
JPEG XLに変換しながら10連写や20連写を処理するスペックの画像処理エンジンなかなかハードルか高い
HEIFでさえ自社で画像処理エンジンをやってるキヤノンとソニー以外まだ実現してないんだぜ
CanonやSONYのHEIFは.hifだけどそのままだとWindowsやMacOS上でまず扱えない
拡張子を.hifから.heifに変えても無理だったりする
JPEGへの変換もCanonならCanonの、SONYならSONYのソフト上でしか行えない
HEIFはライセンスの問題でこんな感じだからライセンスフリーのAVIFが待たれてる
この記事が分かりやすい
JPEGの後継画像フォーマットはこういう問題が起きないものじゃないと
https://www.dmaniax.com/2019/12/03/heic-kill-jpeg/
カメラに求めるJPEG後継画像フォーマットはまさにこの記事そのまま
報道カメラマンはミリ波5Gスマホと連携させて撮って出しをそのままサーバに送り続ける方向性になってきた
だから低クオリティ設定でも破綻しないWEBP2が望まれてる
風景やポートレートカメラマン、スタジオカメラマンは撮って出しよりもRAW現像でゆっくりレタッチするからJPEG XLの高いクオリティ設定が真価を発揮する
いままで8bitのJPEGだったから全てのカメラマンを賄えてたけど今後は要望聞いてたら色々対応しないと売れないカメラになる
ミラーレス化して電子シャッターで30連写とかの世界に入ったからね
はえー
HEIFよりjpeg xlのが軽いイメージだったわ>>276見てたから
https://docs.google.com/presentation/d/1Vuq1WclKNBxiRd6znT7g-XyugwQA4FwqsyHRL8FlEFw
https://www.google.com/url?q=https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/edit%23gid%3D1218217095&sa=D&source=editors&ust=1616520223756000&usg=AOvVaw3S4o2N0y4rqlqlU3gt4LX_
カメラマンの仕事はゴールの瞬間を撮影したらそのまま本部のサーバに画像を転送する事
本部の仕事は予め用意してあるテンプレートに時間や選手名等を書き加えて、サーバに届いた写真を貼り付けたら記事を配信する事
速報記事を配信するまでのワークフローを各社が競ってて、5分とか3分とかどんどん速くなってるのよ
こういう速報記事に求められるスペックは高画質じゃなくて高ワークフローになるわけ
だからJPEGよりエンコード負荷やファイルサイズが大きい時点でHEIFやJPEG XLは向いてない
速報記事だから12bit 444は要らないからJPEGでいいと割りきれるのも大きい
広告やポートレートはより良くより美しく見せないといけないから
10bitや12bitを扱えるHEIFやJPEG XLが求められてるけどね
まあこれはこれでraw現像コースだからバックアップ的な意味合いになるけど
https://twitter.com/5chan_nel (5ch newer account)
https://twitter.com/5chan_nel (5ch newer account)
webpの方が少ないってのは何と比べて？
元々大した画質じゃないweb漫画(JPEG)を
画質50のwebpにすると元のJPEGより多少きれいに見える
JPEG特有のもやもやした感じが平均化されるせいだろうな
https://twitter.com/5chan_nel (5ch newer account)
草
ttps://automaton-media.com/articles/newsjp/20210331-156456/
https://twitter.com/jonsneyers/status/1377508854024523778?s=21
https://twitter.com/5chan_nel (5ch newer account)
https://twitter.com/5chan_nel (5ch newer account)
画像によっては驚くほど容量が減るのな
500KBの画像を50KBにしてもほとんど劣化を感じない
https://squoosh.app/ でjxl化も試してみたけど
不可逆でwebpと同じ容量にしようとすると
webpに負けてるかな
「WebP Codec 0.19.9」で検索するとWIC(Windows Imaging Component)用のプラグインがいくつか出てくるが
どこが開発元なのかよく分からんな
WebP Image Extension: https://www.microsoft.com/store/productId/9PG2DK419DRG
を入れればWIC対応アプリならどれでも開けるようになるけど
windowsのフォトビューワーは何故か動きが異なる
HDRで撮れるのは大きいのですが。。。
XRは対応してるとこ少ないのがね…HDRならjpeg XLの方が推されると思う
jpeg XLってのがあるんですね。
まだ国際標準規格化されてないのがアレですが。。。
XLの方も現状は無理だろうけど、この先を考えると多分XRの方が分が悪いというか
https://twitter.com/jyzg/status/1390252388443897862?s=21
https://twitter.com/5chan_nel (5ch newer account)
これはPriority: Not set
Bug 1539075 (JPEG-XL) は Priority: P5
まるでやる気なしだな
WordPress 5.8でWebPに対応
日本だとシェアが高くてここが変わらなきゃ始まらないんだが、AVIFやJPEG XLに対応するのはいつになるやら
ついでにInternet Explorer 11サポートも終了するかもだって
>>313
圧縮効率の美味しいところが違うから基本的に比較は不可能
ハイクオリティならJPEG XLでロークオリティならWebPと使い分けるしかない
>>318
appleさんは突然やる気を出すから期待してていいよ多分
https://twitter.com/5chan_nel (5ch newer account)
chrome://flags/#enable-jxl
で有効化が必要
詳しく見てないがカラースペースバグはJPEG XLにも引きずっていると思われるので
こちらの有効化も当分できないだろう
しばらくリリースがないからどうなってんのかと思ったけど
AVIFのほうが小さくなるけどMicrosoft AV1 Video Extensionの仕様か白飛びするのが困る。
誰かJPEG XLのSusieプラグイン作ってくれないかな。
Microsoft AV1 Video Extensionおかしいね・・・うちは紫色になる
ていうか名前がxrと紛らわしい
自力で変更も出来ねぇし誰だよこんなクソみたいな拡張子作ったの氏ね
GoogleがブラウザやYouTubeで対応してiOSも対応したし
jpg2000とか出てたが自滅して空白期間が出来て結局jpgに変わるものが長らくなかったしな
その用途だとJPEG XLしかない
漫画とかイラストはavifの細かい部分を塗り潰しちゃう悪いとこが目立ちにくいから向いてるね
写真メインのとこは微妙だろうけどイラストメインのpixivとかと相性良さそう
でかい企業さん方が乗り気になれば早いだろうけどそうなるまでが長そう
https://pbs.twimg.com/media/FD9UCtNXEAYtxnS.jpg
https://twitter.com/5chan_nel (5ch newer account)
ちゃんとしたベンチマーク結果ないのかよ
https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs
ttps://ja.wikipedia.org/wiki/JPEG_XL
> JPEG XLエンコーダは拡張メタデータを追加した下位互換性のあるJPEGファイルを生成することができる。
> このファイルはJPEGデコーダでデコード可能であり、JPEG XLデコーダの場合は拡張メタデータを使用して画質を向上させることができる。
こんなのないよね
そういう機能あったような気がするが
>>346のlegacy friendlinessの部分のことじゃね
それは既存のJPEGを無損失でJPEG XLに変換する機能であって、既存のJPEGデコーダーが読めるような形のJPEG XLを出力する機能ではなくない？
wikipediaってそんなもん
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 upgraded yet.
https://jpeg.org/jpegxl/
の２段落目くらいに書いてない？
jpegだから既存のブラウザで互換表示出来るかと思ったら
新規で対応しないといけないんならもう別フォーマットじゃねーか
2二段目のこれか
JPEG bitstream with app markerってやつか
おーなんかそれっぽいな
ちょっと調べてみるわサンクス
その機能、仕様はあるけど実装がないんじゃないの？
リファレンスエンコーダが実装してるのかは謎
https://jpegxl.io/
それは >>358 の図の一番左端のパスでしょ
左から右がそのまま移行の流れなんだな
こういう風にスムーズに変わっていけたらいいな
https://forest.watch.impress.co.jp/docs/news/1372376.html
> ただし、「IrfanView」で表示する際はJXLプラグインが既定では無効化されていることに注意。あらかじめプラグインを有効化しておく必要がある。
perfectviewerも
M1Macだけど対応してないな
実装ライブラリlibjxlパット見た感じMSVC未対応ってのも開発者にとってクソめんどいし
avifはどんくらいかかったっけ
2021年10月、Android12でネイティブサポート
なので2年半程度掛かってるね
JPEG XLは先々月にPart 2: File formatが完成
Part 1: Core coding systemはFDIS承認見込みでIS発行は年明け頃になるらしいので
まあ気長に待とう…
そういやまだそれもあったか…確かPart4まであるんよね
JPEGXL規格が正式に承認されました。ISO/ IEC18181-1の最終ドラフト国際規格（FDIS）（JPEG XLコードストリーム仕様）が満場一致で承認されました。国際規格は2022年1月に公開されます。これで完了です。
https://twitter.com/jonsneyers/status/1471942556468584454?s=20
https://pbs.twimg.com/media/FG1i-qyWYAAQnVX.jpg
https://twitter.com/5chan_nel (5ch newer account)
JPEG XLは可逆圧縮性能が滅茶苦茶優秀でスクショやイラスト保存形式のデフォルト候補として採用されるポテンシャルが普通にあると思う
写真保存形式はHW絡みでややハードル高いけど最近MediaTek Dimensity Open Resource Architecture、OPPO MariSilicon X、Xiaomi Surge C1、Vivo V1等々メーカー独自ISP開発ブームが来てるから我先に実装競争で採用チャンスありそう
全く別のフォーマットのくせに互換性匂わしてんじゃねーよ
>>383
何回同じこと書いてんだ
あとその勘違いは流石に情弱としか思えないからやめたほうがいいと思う
メジャーなソフトウェアが対応するのはもっと早く済むはず
このフェーズ差が功を奏するといいが
カメラの写真保存形式って今何が使われてるんだろか
撮って出しだと、普通にJPEGでは？
Chrome Platform StatusにFacebookがJPEG XLの使用を検討しているという一文が追加されているな
https://jpegxl.io/tutorials/facebook/
実際にサポートテストが行われているらしい
上手く行けばInstagramとWhatsAppでも採用されるだろうな
余裕余裕
https://pbs.twimg.com/media/FAmfVjeWQAMuy1H.png
そっちのグラフはないのかな
https://m.youtube.com/watch?v=UphN1_7nP8U
Progressive loading: JPEG, JPEG XL, AVIF
https://m.youtube.com/watch?v=inQxEBn831w
すげー
一年前のver0.1時代のやつなのか
現在のver0.6?だと更に性能向上してるのかな
ver1.0リリースとその後の最適化が楽しみだ
avifがオチみたいで笑ってしまった
現時点のsquooshが出力するものだと、webpに勝ってるところが殆どないんだよなぁ
https://squoosh.app/
https://tshino.github.io/compare/compare.html (画像比較ツール jxl対応)
結局ブラウザやビューア対応少ないしwebpに劣ってるな
webpは赤色の劣化がな…
インスタ対応来たらマジ大歓喜だわ
https://storage.googleapis.com/demos.webmproject.org/webp/cmp/index.html
そりゃ後発だから対応してないのが多いのは当たり前でしょうか
2番目の橋の夜空を見比べみた
mozjpegはブロックノイズが酷い
webp,webp2はカラーバンディングが結構目立つ
heif,avifは普通に綺麗。カラーバンディングも拡大しないとわからないレベル。星が若干滲むくらい
jxlは殆ど違和感ないな。強いて言うなら青色が微かに強くなる気がする程度かな
今回みたく淡いグラデーションがある画像に動画コーデック由来のやつは不向きなのかもしれん、と思った
ね〜
でも美顔効果もあるので女性は好みそう
AVIFはサムネイル画像やピクセルアートみたいな小さいサイズなら苦手なデコード速度の影響も減るし割と有りなんではと思った
一つ気になるのはWebP変換すると色彩がなんかおかしい。通行人のおじさんが不気味な土気色になってしまう
つまりwebpを捨てに来ているということ
それってJPEGの後継規格じゃない…ってコト！？
jpegとかpngの後継はJXL
GIFとapngみたいな動画像はAVIFって感じで分かれるんかね
つまり逆に考えるとJPEG XLはWebP・AVIFの後継でもないんだよ
GoogleとMozillaが業界を二分してバチバチやってた記憶があるんだが
Nightlyでフラグ立てれば使えるらしいが
https://jpegxl.io/tutorials/chrome/
フラグ立てれば使える
https://jpegxl.io/tutorials/safari/
webkitは対応するがiOS/MacはOS側で対応しないと無理
多分そうかも
その辺は動画派生が強いんだろうね
BugzillaでJXL正式追加問題に対して冷たい態度取られてる
priorityも低い
WebPも不満言いながら対応してたし
Webサイト側がFirefox無視して実装しちゃうからしぶしぶ対応とか？
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コンポーネントのみ、または複数の中間画像に基づいてクイックプレビューをレンダリングすることが可能です。
すべての主要なブラウザがサポートすることで、今後のWWW実験がより容易になり、プラットフォームやブラウザ間で一貫した体験を提供することができるようになるでしょう。
あと日本はあんま関係ないけどWhatsAppも
べつに利害関係ないし
普通に対応するでしょ
https://pbs.twimg.com/media/FHEAej_WUAECqW3.jpg:orig
slow lossless jxl がグラフに入ってないけどどうなんだ？
他の設定は>>422の画像の上の方にある
https://pbs.twimg.com/media/FHHLNbMWQAIzXAU.jpg:orig
Facebookインフラチーム（現Engineering at Meta）はQUICをFacebookのデプロイと同じストラテジーでInstagramにもデプロイした、とか言ってたから期待できそうやな
https://engineering.fb.com/2020/10/21/networking-traffic/how-facebook-is-bringing-quic-to-billions/
はえー
こういう連携取れるの強いね
https://i.imgur.com/oIp1uHe.jpg
来年は10パー未満勢が動くと思う
https://daniel.haxx.se/blog/2021/04/02/where-is-http-3-right-now/
https://daniel.haxx.se/blog/wp-content/uploads/2021/04/Screenshot_2021-04-01-HTTP-2-vs-HTTP-3-vs-QUIC-usage-statistics-March-2021.png
>2021年2月以降の成長は、Cloudflareが無料プランでもユーザーにHTTP/3を有効にしたことで説明できる可能性があることが示唆されています。
動くってのは増える方？減る方？
10パー未満勢が動くという流れで大手CDNの影響力の話をしただけだが
件のHTTP/3を導入したCloudflareはAVIFサポートも早かったし
新規格に目敏いという点で注目に値すると思うね
Facebookもそれよな一応GAFAの一角なだけある
つかhttp3ってまだRFCになってないのに既に15%以上シェアあるの普通にすごいな
最近だとInstagramがHTTP/3データグラム優先度制御で画像外よりも画面内の画像レンダリング速度を優先させる実装作ってたな
https://zenn.dev/gunta/articles/64de0540bafb3d
Facebookはインスタの倍以上のユーザーいるしmetaのやる気は大事だねえ
10年間でかなり減ったな
2012年68.4%→2022年20.9%
https://w3techs.com/technologies/history_overview/image_format/all/y
いわゆる化石サイトの割合に近いかもしれん
SquooshはlibavifのWebAssembly実装
Cloudflareはcavif-rsというrav1eベースのRust実装を使ってるらしい
https://github.com/kornelski/cavif-rs/issues/20
はえーそうなのか
その辺も新しいフォーマットになれば便利そうだけど変えるハードル高そうだなあ
JXLに変えても大差はないから
英ガーディアン紙のエンジニアがBugzillaに寄稿しとるな
>ガーディアンの代表として、JPEG XLの採用に対する私たちのサポートを表明したいと思います。
・JPEG XLは現在標準化中で、私たちはウェブブラウザが標準を実装し、ウェブコンテンツ制作者がニーズに最適な標準化された形式を決定できるようにする必要があると考えています。新しい標準化されたフォーマットの一般的な採用は、ブラウザのロードマップに影響を与える能力よりも、むしろ使用法によって推進されるべきだと考えています。
・JPEG XLの後方互換性とJPEGでのエンコードおよびデコードの利点により、CDN（またはクラウド画像サービス）とコンテンツ制作者が迅速に採用すると考えています。自社サイトについては、CDNと一部のブラウザでサポートされ次第、採用する予定です。
・JPEG XLは現在最も強力な画像フォーマットだと思いますが、非常に低い画質ではAVIFの方がうまくいく可能性があるという条件が付いています。
・より効率的な圧縮フォーマット（JPEG XLやZstandardなど）を使用することは、持続可能性にプラスの影響を与えると考えています。
おっ地味に写真管理サイトSmugMug+FlickrのCEOの人もJXLサポートの意向を表明してるやん！
本気で対応頼むでまじで
https://pbs.twimg.com/media/FJSsyFsXIAAHP4o.jpg:orig
P5 → P3
https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#a88948208_505306
P3: Backlog
P2: Fix in the next release cycle or the following (nightly + 1 or nightly + 2)
リリース版に入れるつもりはないけど、やるつもりはあるみたいな優先度？
フラグの切り替えで有効化できるから、ただの形式的な表示だろ
P1だったHEVCは結局サポートされ無かったし
あんまり参考にならんな
圧縮の設定とか全然詳しくないんだけど何となく気になった
https://pbs.twimg.com/media/FJUuA3VXwAMNnDD.png
Twitterで本人にリプ送って訊いたら確実に正確な回答貰えそうやけどな
によると-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
https://encode.su/threads/3701-GDCC-21-T2-Multispectral-16-bit-image-compression
>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).
速さへの拘りを感じるオプションの数々
イイネ！
>>462
ありがとう
あとで翻訳して読んでみる
https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/
https://gigazine.net/news/20220125-webutils-compress-images/
jxlが0.7.0だから一番新しいやつか
>>32とか>>54とか
MP3はそろそろAACかOpusに置き換わってきたかな？
圧縮率PNG比33~58%ってすごいね
Susieプラグイン作ってる人居た
https://github.com/uyjulian/ifjxl
https://zenn.dev/gunta/articles/64de0540bafb3d
やっとゲームの分野でVorbisから置き換わったくらいなのを見たら土台無理なのくらい分かるでしょうよ
自分が所有する画像をjxlに変換してメリットがあるかどうかが重要
音声圧縮のopusが流行ってないから画像圧縮のフォーマットのJXLも流行らないってこと？
繋がりがよく分かんないや
jxlをどうgoogleが扱うかは知らないけど
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に負ける
https://twitter.com/5chan_nel (5ch newer account)
やっぱChromeとFirefoxが対応したのが大きい
あとはWindowsのAV1 Video Extensionがバグ修正してくれたら満足
なんでファイルサイズじゃなくてエンコーダのオプションで比べるの？
q95〜100あたりのロスレスでかすぎるからとりあえず圧縮しました的なとこでjpgに劣る事が多いのはwebpの欠点だと思うけど
それでもサイズはmozjpegよりだいぶ縮むぞ
画質も圧縮もwebpの方が余裕で上だったわ
小さいほど圧縮率が良い
計算間違ってた恥ずかし
jpeg系だと85以上ほしいし
逆にavifには過剰という塩梅
q最大値63という半端な数値ややこいわ
はえーありがとう、max100じゃないやつもあるんだな…
もうwebpに乗り換えちゃったんだけど
2年後くらいからJXLも視野に入りそう
JXLはデコード速度がまだ最適化されていない印象
PNG:15.0MB - 44MP/s (iftwic.spi)
WebP:11.3MB - 30MP/s (iftwebp.spi)
JXL:9.4MB - 8MP/s (djxl 0.6.1)
それってspeedいくつくらい？
>>496は1秒で何メガピクセル表示できるって値
1920x1080(約2MP)の表示だと
PNG 0.045秒
WebP 0.066秒
JXL 0.250秒
ぐらいかかるということ
WebP Losslessは微妙にイラッとする遅さだと感じる
あの微妙な速度を我慢するぐらいなら多少でかくてもPNGがいいかなって思う
けど思ってたほど速くならなかった
まだ実用的な段階ではないのか
ifavifx.spi
https://www.axfc.net/u/4049929.zip
ごめん、それはわかってるけど>>499的なことが聞きたかった
環境変わってしまって申し訳ないけど、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)
これはいいデータ
乙
ここに載ってるe3,e5,e7,e9E3のデータだとeffort値はデコード速度には殆ど影響しない様子だったけど
>>502の結果を見るとe3~9は概ね横並びでe1,2はかなり別格っぽい感じですな
Alarm raised after Microsoft wins data-encoding patent
https://www.theregister.com/2022/02/17/microsoft_ans_patent/
＞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をはじめ、写真や画像用の1992年のJPEGに取って代わるはずです。しかしMicrosoftの特許がJPEG XLの採用をより困難にする可能性があります」と語る。
一方、JPEG XL仕様のエディターであるJon Sneyers氏は「私の知る限りこの特許はJPEG XLに影響しないはずです。MicrosoftはISOに対して影響を与えるとは宣言していません。MicrosoftもJPEGに参加しているのでJPEG XLで使われている技術を認識しているでしょう」と述べた。
特許取得企業がインター○ジタルみたいなパテントトロールじゃなくてよかったな
これは良くない傾向
俺はIBMになりたいんだ！IBMになって1984するんだ！という表明だぞ
狭い範囲で使われる、カスタム仕様のQRコードを開発・販売する権利を得たことで儲けを出してるみたいな話を聞いた
画像フォーマットも多分そういうのがあるんだろう
MSはJPEG XLの発展製品で儲ける権利を狙ってるだけで、
JPEG XLは普通に世に出せるはず
JPEG XLで使ってるANSは、JPEG XLの元になったpikで使っていたのと同じ種類のANSである
pikが公開されたのが2017年で、MSが特許を申請したのは2019年だ
>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
てか表示速くてもメモリ食って負荷が高いとかならマイナス要素になるけど
表示速度比較してるサイトはまだなかったはず
デコード速度はJXLe5程度っぽい?
思っていたほど遅くはないけど、絶望的にエンコードが遅い…(JXLe9位)
画像サイズが120ピクセル前後の画像として読み込んでしまいます
設定の問題でしょうか？未対応なだけでしょうか？
普通に対応してたはずだし自分の環境だと問題なかったから多分設定かなんかの問題じゃないかな
https://github.com/tachiyomiorg/image-decoder
ありがとうございます
再インストール等を試しても不具合が続いたのですが、
インストーラーではなく"zipped program folder"の方を落として使ったところ問題なく動きました。
ご報告までに
https://gigazine.net/news/20220324-stephen-wilhite-passed-away/
Burn ALL GIFs day
https://www.iso.org/standard/77977.html
ArchLinuxでビルドできたよ
AvifとHeifは試してない
何か問題発生した？
https://qiita.com/nanakochi123456/items/e2550cabf890d85ba84e
何も参考にならん
https://gigazine.net/news/20200626-webp-cjpeg-mozjpeg-webp-avif-compare/
これをお手本に、書き直してから来なさい
https://apribase.net/2021/06/08/capture-one-encoder/
libjxlバージョン1.0へのマイルストーン
https://github.com/libjxl/libjxl/milestone/1
俺はあくまで客観的事実を述べているだけだ
今年こそJXLの時代になるならそう言うがどう見ても今年もWebP最高で終わる
webpかjpegかjxlのどれを使うかはユーザが決めることじゃないから、何が最高かだなんて心底どうでもいい
ただし、ブラウザやスマホ側は早くjxlを標準サポートしろとは思う
エンコードに時間かかりすぎるから
普及に限界ある
スレタイ的にもwebpはjpegの後継じゃない
Jpegは最大65,535 × 65,535ピクセル（2^16 -1）しか対応してないから写真資料の保存に困ったことがある
avif（65,536x65,536）やwebp（16,383 x 16,383）は論外
あとプログレッシブレンダリングが結構捗る
webpやavifのような細部塗り潰しは低解像度である程目立たなくて正にweb向けって感じだ
エンコードとデコードの遅さも低画像度なら大した問題にならないしほんと良く特化してると思うわ
avifは流石に遅過ぎてこれじゃ普及しないだろうなーってひしひし感じるけど
プログレッシブレンダリング良いよね
それあるからJXLはweb向きでもあると思う
がFDIS段階に入ったな
あと何で4パートで分けてるんだろう
しっかり校閲されるから互換性や特許等の心配が減る（ベンダーが嬉しい）
とかかな
標準化された仕様書が無いと皆オレオレ実装やり始めて収拾つかなくなるんや
Part 3: Conformance testingに違反してたらJPEG XL非準拠のパチモンってこと
その記事には使ってるlibjxlのコミットハッシュはついてないの？
・スペックは凄いっぽいけど、まだ使える実力ではない
・一般人は無料で使える
という点が似ている
https://res.cloudinary.com/cloudinary-marketing/image/upload/w_700,c_fill,f_auto,q_auto,dpr_2.0/Web_Assets/blog/Battle-of-the-Codecs_fnl.png
https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg
JPEG XLの製品実装も早よ
そんなのあるんか
https://jpeg.org/jpegai/
JPEG AIは、シングルストリームでコンパクトな圧縮領域表現を提供する学習ベースの画像符号化規格で、人間の視覚をターゲットとし、同等の主観品質で一般的に使用されている画像符号化規格よりも大幅に圧縮効率を高め、画像処理とコンピュータビジョンのタスクに有効な性能を実現し、ロイヤリティフリーのベースラインをサポートすることを目標としています。
JPEG AIは、クラウドストレージ、視覚監視、自律走行車やデバイス、画像コレクションの保存と管理、視覚データのライブモニタリング、メディア配信など幅広いアプリケーションを対象としています。その目的は、同等の主観品質で一般的に使用されている符号化規格よりも大幅に圧縮効率を向上させるとともに、機械学習ベースの画像処理およびコンピュータビジョンのタスクに対して効果的な圧縮領域処理を必要とする符号化ソリューションを設計することにあります。また、ハードウェア／ソフトウェアの実装に適した符号化・復号化、8ビット／10ビット深度のサポート、テキストやグラフィックスを含む画像の効率的な符号化、プログレッシブ復号化などの要件も重要です。
JPEG AIの最終提案募集は、第94回JPEG会議の成果として、「JPEG AIの使用例と要件」および「JPEG AI共通トレーニングおよびテスト条件」とともに発行されました。関心表明と登録の締め切りは、2022年2月25日です。また、テストデータセットのビットストリームとデコード画像の提出期限は、2022年5月2日です。
ダークシリコン化するエリアを有効活用できるし一石二鳥的な
https://github.com/mpv-player/mpv/pull/10126
30%か
つい一時間前に#1388がマイルストーンに追加されてパーセンテージが下がってるし
決して鈍化では無いね
スクリーンショット出力形式がJPEG XLに対応
JPEGよりも高品質で高速なスクリーンショットを撮ったり、PNGよりもファイルサイズが小さいロスレス高ビット深度のスクリーンショットを撮ったりすることが可能
まじか
へー、そうなんだ
WindowsならWICがあれば要らないのかも
マルチスレッド処理とかがデフォルトで組み込まれてる分他より手順多いのは仕方なさそう
対応してるはずなのにアニメーションjxlを未だに見ないから気になるー
https://www.phoronix.com/scan.php?page=news_item&px=FFmpeg-JPEG-XL-Lands
FFmpeg Lands AVIF Muxer For This Image Format Based On AV1
https://www.phoronix.com/scan.php?page=news_item&px=FFmpeg-AVIF-Muxing
https://qiita.com/unicodon/items/b7c1e1915c34d2f02e04
Support Animated JPEG-XL images
https://github.com/WebKit/WebKit/commit/3cddf74bb622d2cad2bd2220cd1f3b9cdab3dfd7
例えばFirefoxはAVIFの静止画形式に対応したがアニメーション形式には未だに非対応という落とし穴
EdgeとSafariに至っては静止画形式すら非対応なんで此処らの足並みが揃わぬ限り普及が進まん
>>586
ありがと
Bump version to v0.7 (#571)
https://github.com/libjxl/libjxl/pull/571
https://encode.su/threads/3397-JPEG-XL-vs-AVIF?p=74373&viewfull=1#post74373
https://encode.su/threads/3863-RANS-Microsoft-wins-data-encoding-patent
似たようなのがJPEG XLにも存在するみたいだ
と掲示板で書かれまくってます
違う、特許提出したMicrosoftが、っていうより、
欠陥だらけの特許を認可した米特許庁に問題あり、特許の再審査を私たちは求める、って感じかな
これでGoogleもWebP2に注力するだろうしJXLは終了かな
WebPとAVIFは実際使ってみると悪くない
軽さの定義もファイル容量だったり表示速度だったり人によって認識違うだろうし
別に二者択一ってわけでもないから方向性が異なるアプローチを同時進行させて最終的にjpeg,png,gifに引導を渡すことができれば何でも構わん
意味のない対立煽りだよ
ソフトウェアデコード特化で高速化を実現したjpegxlのほうがいいな
ただ単純に登場が遅いのでその分のハンデはあるし、環境が整いつつある今だからみんな期待してるんだ
もし使ってみて駄目なら使われないだけだし
実はjpegも使ってみるとそんなに悪くないぞ
googleは競わせる側として他の企業がどれに興味持つか気になる、どうせappleは遅れて動くだろうけど
これ、50%まで来たんだな
まあこれから課題増えたら下がりもするだろうけど
大体のSNS未だにjpegGIFだぞ
意外と使ってるサイトは多い
54%になってる、へっへっへ
特許とか色々と難題だろうけど、着々と出来上がってるのを見るだけで楽しいよ
で、何が分かったの？
それでも0.8ではほぼ同等みたいだけど
コーデックごとのサイズ容量も欲しいな
低容量ほど通信完了まではやくなるわけだし
横軸
書いてあった
多分jpegxlが1番良さそうだけど
(moz)JPEG vs WebP vs (Kakadu) JPEG 2000 vs (libaom) AVIF vs (libjxl) JPEG XL
って元のツイートに書いてあった、mozjpeg使ってたんだな
https://siipo.la/blog/whats-the-best-lossless-image-format-comparing-png-webp-avif-and-jpeg-xl
https://cdn.siipo.la/app/uploads/lossless-comparison-median-file-size.png
https://cdn.siipo.la/app/uploads/lossless-comparison-median-encoding-time-no-error-bars.png
これwebpやたら早いけど8bitまでだからとかそういう理由なんかな
がFDIS段階に入った
ワンチャン年内IS発行あるで
https://www.iso.org/standard/85066.html
https://www.iso.org/standard/77977.html
Part2
https://www.iso.org/standard/80617.html
Part3
https://www.iso.org/standard/80618.html
Part4
https://www.iso.org/standard/80619.html
何でパート1だけ2つあるんだろう
改定されたからだね
上がEdition 2
はえーありがと
https://gimp.org/news/2022/06/14/gimp-2-10-32-released/
libjxl API が安定化したらプラグイン作るとフォーラムに書いてる人がいた
Part2 Edition2
https://www.iso.org/standard/85253.html
そんなことないと思うけど
https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs#computational_complexity
Jpegより速い、MP/sはMegapixels/secondの略
こういう統計が出てるけど、きみのはどこ情報なの？
自分でlibjxlビルドして、小さなCプログラム書いて画像を読み込んでみた
で、似たようなサイズの画像のjpegやらwebp,pngやらと適当に比較してみた
他がおそらくマルチスレッド対応してなさそうなので、libjxlのマルチスレッド機能は使ってない
djxlはしっかりソース追ってないけど、マルチスレッド有効になってたりしないか?
いやなんでそこ切るんだよ
あとさっきのデータには4コアでやってるって書かれてる
jpegxlはだけマルチコア使って速いって主張だったの??
別に他も使えるならご自由に使っていいよって条件かもしれんが
そうだったならびっくり
マルチコア有効化してどうなるかやってみると分かるかもね
JPEG XLはわざわざマルチスレッド向きのデータ構造にしてあるんだから
俺はそういうの抜きに計量量自体が少ないから速いのかと思ってた
そういう場合においてはjpegxl自体が軽いわけじゃないから、jpegxlに変えたところでトータルとしては変わらないってことだよな..
画像1枚だけをデコードする場合はすばらしいということね
元からマルチスレッドで複数枚を同時にデコードするケースでは...
こういうことか
こんなとこにいないでqiita にでも結果を投稿して思う存分論弁してくれ
だから皆クッソ難しい並列処理実装の効率化高速化で血反吐はいてるわけで
そっちも並列処理できそうな気がするけどライブラリにその機能はないのかね
あるいはできないのか
>元からマルチスレッドで複数枚を同時にデコードするケースでは...
それも試してみたら？
4枚の画像を1枚毎に1スレッド割り当てて4枚同時にデコードするならWebPやAVIFの方が速いってことでしょ
だいぶ前に自分で実験してみたらそうなった
デコード関係は全然比較上がってないからどっかで見れたらいいなあ
MotionJpegファイルを作ったのですが、
VLCやMPC-BEであれば再生出来たのですが、
WindowsMediaPlayerで再生する事が出来ませんでした。
(エラーとかは出ずに再生時間分黒画面)
WindowsMediaPlayerで再生可能なMozJpeg製MotionJpegを
作る事は出来ないのでしょうか？
スレチ
jpeg関係だからイケるかなと思いましたかダメでしたか
すみませんでした
色深度8bitのみ?
lossyはyuv 4:2:0のみ?
すでに普及してるし
HDRに対応してない
よく見るとスピード欄にsingle coreの文字が
流石にこれは嘘や
webpもデコード遅いけどjpegxlと同じくらい
jpeg>png>webp=jpegxl(1コア)
ただ、jpegxlはマルチコア利用すればjpegすら越えられる
>>679でwide gamutのところ
これからはチャネルあたりの色深度は最低10bitはないと
jpegとwebpは脱落
ちがうの？意味は一緒でしょ？
アホがどうでもいいことで騒ぎ立ててるだけ
確かに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)
さんくす
ソースもあって有能
https://github.com/WebKit/WebKit/commit/59d774a32243ae8ba59de9178f3b029fd28c4477
今 63% complete
https://www.iso.org/standard/80619.html
75%まで来たか
0.7 release candidate
We expect to have v0.7 release soon.
0.7リリースすることしたの??
ちなlibwebpはver1.0になるまで8年以上掛かってて
libavifはv0.9.3からv0.10.0に進級してる（現在v0.10.1が最新）
Bump version to v0.7 (#571)
https://github.com/libjxl/libjxl/pull/571
つか、79%になってるな
もうちょいやん
リリースページ見ると0.7.0 Release Candidateがリリースされてるし
突然0.7をぶっこんできた意味がわからん
「可逆圧縮も非可逆圧縮も両方いけます！」ってのが良くないんだよ
ユーザーは拡張子によってその画像が劣化してるのかどうか概ね知りたいんだから
どっちも同じ拡張子じゃ判りにくくて不快なわけよ
だから明確にふたつに分けろって
可逆圧縮（PNG/GIFなど）の後継 .xxx
非可逆圧縮（JPEG）の後継 .yyy
みたいにな
この心理を理解しないと代替りなんて永久に無理だぞ
性能なんて重要じゃねんだわ
>>703スルーしていいよ
もうすでに.pngのふりした.webpとかかなりうざいわ＾＾；
保存しようとしてそれだった時の絶望感
個人的には
可逆圧縮.xxx
非可逆圧縮.yyy
とアニメーション画像.zzz の3パターン欲しい
あんま詳しくないけど同じコーデックの拡張子って後から増やせるのかな
https://9to5linux.com/krita-5-1-released-with-jpeg-xl-support-full-webp-support-psd-improvements-and-more
>“We haven’t yet enabled saving and loading of the HDR color spaces to JPEG-XL, but what we do have is saving and loading animations, making JPEG-XL the first file format that doesn’t require FFmpeg to allow exporting animations,” said the devs.
あんま見たことないけどアニメjxlってサイズはどんなもんなんやろ
https://bugs.chromium.org/p/chromium/issues/detail?id=1178058
Adobeの人とintelの人が一眼レフカメラで撮った写真のHDRサポートの為に
ChromeのJPEG XLデコードをフラグ無しで有効にしてよーって書いてる
もう製品レベルの話にしたいんだーみたいなノリ？
https://github.com/libjxl/libjxl-tiny
エンコーダのみ
ここ1年で400レスくらい進んでて笑う
てか16年も前に立ったスレなんだなここ…当時の人もういないだろうな
https://www.iso.org/standard/77977.html
Edition2
https://www.iso.org/standard/85066.html
Part2
https://www.iso.org/standard/80617.html
Edition2
https://www.iso.org/standard/85253.html
Part3
https://www.iso.org/standard/80618.html
Part4
https://www.iso.org/standard/80619.html
このチケット、今日も引き続き盛り上がってる
担当者っぽい人もコメントしてる
最新が2022-08-23になってる、何が変わったのかはわからんけど
https://pbs.twimg.com/media/FbJ1BNXVUAAiUCf.jpg
https://pbs.twimg.com/media/FbJ1bXcUUAALWP5.jpg
https://pbs.twimg.com/media/FbJ1bXwUcAAMcl2.jpg
https://pbs.twimg.com/media/FbJ1w5wUsAI3T84.jpg
その下くらいに名前出てるガーディアンってどっかの新聞だっけ
ニュースやってるとこも反応してんだね
あとはまあ漫画村みたいなところとかｗ
8か月前
https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c27
ffmpegのlibjxlラッパー製作者がJPEG XLデコーダの技術的な話を寄稿しとるな
曰くJPEG XLのアルファチャンネルの処理はAVIFよりも余分なオーバーヘッド発生が少なく、WebPやPNGといった既存のフォーマットよりもカラーマネジメントがずっとシンプルになっているとか
誰か先駆者いる？toolsのdjxl各種を見るのは億劫なんだ
ツイッターに責任者いるからそっちに聞いた方が良いかもよ
日本語でも対応してた記憶
スレッド数をJxlResizableParallelRunnerSuggestThreadsで決めてるから
マルチスレッドになるかどうかは画像サイズ依存なんじゃない
JPEG XLのHWコーディング用に作られた実装なのかこれ
ゆくゆくはスマホISPとかに搭載されたりするかもな
- J40 is an independent decoder reimplementation from spec (getting close to complete)
- fjxl is a fast lossless-only encoder implementation (complete but only uses a subset of the codec)
- libjxl-tiny is a simplified encoder implementation (forked from libjxl though, so doesn't really count)
- hardware coding is being investigated within the JPEG committee (in fact libjxl-tiny was created for that purpose)
- jxl-rs is an implementation in Rust (very incomplete)
- ffmpeg has its own parser and is considering to do their own implementation (work still needs to start afaik)
なんとかみんな完成してほしいわね
iso待ちなんか
https://pbs.twimg.com/media/FcXZi8bXEAIASny.jpg:orig
どこの論文のやつ？
これjxlはe4で見ても結構悪くないなと思った、早いし
twitterのやつでは？知らんけど
ほかはドキュメントの整備とか一部環境でのビルドバグとかUnicode問題だけだから早くver1出てほしい
https://matthias-buehlmann.medium.com/stable-diffusion-based-image-compresssion-6f1f0a399202
面白い検証
こういうナチュラルグラデーションはアニメ系の絵にもいいのよね
https://news.ycombinator.com/item?id=32885203
作者によると製作期間4ヶ月、うち主要な機能 (モジュラーとVarDCT) が機能するようになるまでに1, 2ヶ月かかったと。将来的にはRust版も構想してる模様
パブリックドメインライセンスなんだw
https://github.com/lifthrasiir/j4
これXLが一番ファイルサイズ小さくて綺麗なのか？
デコード速度も一番早く軽いのか？
rust版いいね
頑張ってほしい
お絵かきAIの圧縮をjpeg.webpと比較してる記事だからJXL関係無いと思うよ
Windows版バイナリもリリースページから落とせる
>数日前、libjxlのバージョン0.7がリリースされました
APIの他のいくつかの側面が改善、変更、または廃止となった。0.7 APIの廃止されていない部分はすべて、1.0 APIに残ると見込まれる。今回のリリースは主に1.0に向けた準備段階として機能し、1.0より前の最後のリリースとなる可能性が高い。今こそソフトウェアにjxlサポートを追加する良い機会だ！
https://twitter.com/5chan_nel (5ch newer account)
それだけで結構変わりそうなもんだけど
edgeもだね
そこの設定触る必要無くなってほしい的な話じゃないかな
https://www.iso.org/standard/80618.html
https://news.mynavi.jp/techplus/article/20220922-2459794/
>時期尚早というのが現時点で優勢な意見
寧ろ遅きに失した感あるような
AVIFも割と期待持てそうだよな
公開用なら徐々に移行してもいいかな
解像度インフレしてんのに未だJPEGは辛い
なのに他の後継フォーマットは揃いも揃って普及率クソザコナメクジばっかだったしなあ
jxlがブラウザで設定無しに見れるようになればjxl一択
普及してないナメクジどもは色んなソフトやサイトから見向きもされず未対応ばっかで何かと困るからなあ
やっとこWebPやAVIFが普及へ近づいてるかな？ってレベルよね
まぁ暫くJPEG PNG ド安定なんだろーけど（泣）
どれも期待してたのに結局JPEGを打ち崩すどころか殆ど見向きもされなかったナメクジっぷりに落胆もしますよ……
というかこのスレみてJPEG XLの存在始めて知った
何でもいいから普及進んでほしいわね
技術はあるのに特許だの規格争いだの人間ども足引っ張り合いすぎだろ
勝手に用途絞るなよw現状ならjpeg PNGだろ
可逆なWebPはもはやためらいなく使えるしavif,JPEG XLもいずれはそうなるだろう
heicはちょっと怪しいが
最新のlibaom使えばjxlと遜色ない程度にはなってる
ブラウザサポートだけで普及云々言ってるから中途半端なコーデック増えたんじゃないの
まず先発のWebPやAVIFが今後どれだけJPEGを切り崩せるか
実質avifとjpeg xlの一騎打ちでしょ
だが圧縮処理が凄まじい高負荷で遅い
JXLが熱望されるのもまぁまぁ分かるな
AVIFは…JPEG XLで良いよなぁ
APNGの二の舞いになりそう（対応ソフトが少ない、それ動画でよくねになる）
一般人からはGIFと呼ばれ続ける未来が見えるわ
10秒以上は普通は動画ファイルだし
連続で何枚か見ようとすると多少高解像度なだけで本気でイライラする遅さ
エンコードは放置でいいから大して気にならないけどデコードはそうはいかん
10秒以上は動画ファイルってのは同意だけど単純にGIFは画質がきつくない？
Googleさん頼むよ、、
割とマジで
同名じゃないだけマシ
ブラウザでも全然対応せずドマイナーフォーマットでしかないからな
そら4年のavifと10年のwebpならサポートに差はあるでしょ…
てかvp8の派生のwebpからしたらvp10を取り込んだav1の派生のavifは後継みたいなもんじゃないの
Chrome、Firefoxが既に対応してて
Safariも既にテスト段階だから主要ブラウザ全対応までもうすぐだよ
ChromiumなEdgeも後追いですぐ対応するだろうし
https://caniuse.com/avif
何を渋ってるのか分からん
ただappleは流石に遅すぎるだろって思っちゃうわ、自前のosで固めてる割に
最近の奴だと、abort()が入ってるせいで変なデータ喰わせるとプロセス自体が終了してしまうとか
そりゃ不味いな
https://helpx.adobe.com/jp/camera-raw/using/hdr-output.html
「テクノロジープレビュー機能」とは書いてあるが、割と快挙では？
この分野でのAdobeの影響力は大きい
今までの写真も現像し直そう
decodeのバグの個数が報告済のやつだけでも割とあってつらい
JPEG XRで実装済みの機能をJXLに切り替えてもらうのは難しいかも
https://zenn.dev/tan_y/articles/55f63a1d97495d
> Xbox Game Bar (Win + G で表示される) に静止画キャプチャ機能があり、これでキャプチャすると任意のウィンドウの映像をクリップボードではなく PNG ファイルとして直接ファイルに出力します。また、 HDR 出力になっているディスプレイ上のウィンドウは PNG に加えて JPEG XR (.jxr) ファイルにも出力されます。
普通にWebサイト上のHDRのJXL画像を表示できるんだね
HDRオフでも普通のjpeg写真みたいに違和感無く表示されるし
環境としては非常に土台が整ってはいるんだけど
ちょっとやそっとじゃ完全普及はしないんだろうなぁ…
この辺とかandroid iOSのスクショ機能がjxlになればかなり普及してると言えると思うけど当然表示する方もOSから対応しないといけないからサポートするのもかなり先のことだろうなあ
まったく人間同士で足を引っ張り合いやがって
まるで学習していない……
はやくJPEGをリプレースしてほしいわ
もはやJPEGによる資源浪費と環境破壊ヤバいんでないの
働いてたとしても給与もらう資格がないレベルのアホ
慈善活動じゃねーのにな
https://www.phoronix.com/news/Chrome-Deprecating-JPEG-XL
やる気が感じられて嬉しいな
2011年10月Android 4.0でWebPサポート
2020年8月Chrome 85でAVIFサポート
2021年10月Android 12でAVIFサポート
来年2月頃までChromeでJPEG XLサポートされたらAndroid 14でJPEG XLサポート来るかも？
逆にChromeが8月以降に遅れたらAndroid 15に持ち越しになりそう
およそ2ヶ月先の話やね。どうなることやら
ちなそのChrome 110でWindows 7/8.1がサポート終了するのでワンチャン大型アップデート説あるで
そうは言うがそもそも流行らなくて廃れたら元も子も存在価値も収益源もないゾ
ここのブログのコメント欄を見てると、Googleは自社のWebPを展開していきたいらしいぞ
Microsoftの息のかかったJpegXLではなく
このANS特許問題のせいでJpegXLが将来ロイヤルフリーでなくなる可能性がある
5chの方がまだマシなレベル
頼むぞGoogleはん…！
つべこべ言ってねえでさっさとlibjxl 1.0完成させろやオラァ！
これだよな
期待してるんだから1.0頑張ってくれ
>WebP 2 will not be released as an image format
>but is used as a playground for image compression experiments.
https://chromium.googlesource.com/codecs/libwebp2/
皆様には、JPEG XL に関するご意見・ご感想をいただき、ありがとうございました。以下の理由により、JPEG XLのコードとフラグをChromiumから削除することになりました。
- 実験的なフラグやコードを無期限に残すべきではありません。
- エコシステム全体から、JPEG XL の実験を継続するための十分な関心が得られていない。
- この新しい画像フォーマットは、既存のフォーマットと比較して、デフォルトで有効にすることを正当化するほどの十分な利点をもたらしません。
- M110のフラグとコードを削除することで、メンテナンスの負担を軽減し、Chromeの既存のフォーマットの改善に集中することができます。
メンテナンスって、、😅 お前らブラウザはlibjxlのラッパーを書くだけだろ
「デフォルトで有効にする十分な利点がない」参考文献も検証も示さずに何言うてんねん
誰がこの説明で納得するんだろうか
これ書いたのavif信者だろ
よくある勘違いをしているなw
例えChromeで非推奨化されようが俺はAndroid14でのJPEG XLネイティブサポートに一縷の望みを掛けるぜ！
おっ考え直せっていうコメントが殺到しまくってるぞｗ
民意の力で覆せ！
そしたら矛先がlibjxl側に向かってチンタラやってる開発者のケツにも火がつくだろう
chromiumはラッパーすら書いてないよ笑
ffmpegのjpegxlデコーダーを使ってるだけ
>私たちの多くはJPEG-XLが非推奨であることをPhoronixの記事から知りました。あなたの会社の会社のためにJPEG XL開発にここ数年を費やしてきたGoogleのエンジニアが「Twitterで共有されたPhoronixの記事」によって自身の仕事が採用されない可能性が高いことを知ることを想像できますか? ましてや非常に曖昧な言葉でその理由が自分たちの仕事が十分な進捗と業界の関心を得られなかったからだと非常に短い更新で告げられるなんて。
心情に訴えるのはええ作戦やなｗ
ジョンも性能に問題あるというなら計測結果出してみ？とか書いてるし
Chromiumのプロマネとかかな
JPEG XL設計者のスナイアーズ氏はlibjxlのセキュリティ性能やChromeの実装状態については問題なかったと言ってるな
https://twitter.com/jonsneyers/status/1587019540755611648
>To be honest, I don't think software development/maintenance is the real issue here. Libjxl as it is now is quite robust, and the Chrome integration of it is quite complete (including animation, HDR, progressive decode, etc) and does not really require additional work.
https://twitter.com/5chan_nel (5ch newer account)
マイルストーン見るとやばいのが結構あるよ
でもそいつがどのコーデック/フォーマットをサポートするかの影響力がありそうな人物でもあるっぽい
一応名は伏せるが流石に陰謀論的というか被害妄想が過ぎるんじゃないかなと思う知らんけど
真相はChromeにはフラグ状態を2年以上キープ出来ないという不文律があるとかそんなしょうもない理由だったら笑えるんだがなｗ
ライセンス的にGPL3のlibde265を開発に組み込めないから開発者泣かせでマジむかつく
マジavif死滅しろ
ググったらそいつOn2 Technologiesの元CTOらしくてかなりの権力者っぽいぞｗ
いくら優れていようと流行らなければ使われないってこった
しかしPik+FUIFに機能的に劣ると判断されて選考落ちしたこの世が現実である
といっても現状は本質での勝負どころか大した説明も無く権力で捻じ伏せてるだけでこんなんただのパワハラですやん
せめてロジハラしてクレメンス
そもそもそんなの誰も使わねえよ
最終的にAPNGもChromeでサポートされたしJPEG XLもいつかはサポートされるでしょ
まあしかし、APNG全然普及しなかったな笑
愚かな人類どもめぇ
一生JPEGを使ってろ～～～www
😇😇😇
でもまあChrome側もセキュリティ上の問題とか無難な回答しときゃよかったのに
あんな回答じゃもやり場のない怒りを誰かにぶつけたくなる気持ちは分かんでもない
怒りより向上心が沸き立つ少年漫画的展開も有り得た
数パーセントユーザーが流れてから、こんなもん大したことあらへんとか呟きながら
渋々実装する絵が見えるわ
Google Chromeが次世代画像規格「JPEG XL」形式のサポート廃止を検討、その理由とは？
https://gigazine.net/news/20221102-google-chrome-jpeg-xl-support/
ただのエアプ記事やん
ギガジン………
https://cloudinary.com/blog/the-case-for-jpeg-xl
ワイ結論、webpでよくね？
→avifで可逆圧縮すればいい
プログレッシブデコード
→4G5G環境で必要なし
無損失圧縮性能
→avifとほぼ同等
非可逆圧縮のパフォーマンス
→avifとほぼ同等
展開可能なエンコーダ
→普及してないからサード開発者が採用しない
ワークフロー全体で機能
→個々のサードライブラリを組み合わせるので問題なし
あれ？jxlのメリットどこ？
もっと酷いのもあるぞ。Googleは自社規格webp2を推進したいからとか出鱈目書いてるクソ記事
日本のWebライターもこれくらい調べて記事書けよな
Chrome Banishes Photo Format That Could Save Space on Your Phone
https://www.cnet.com/tech/computing/chrome-banishes-photo-format-that-could-save-space-on-your-phone/
webpはHDR写真無理だから、2も出ないし
avifと被ってて特許が不穏なのがjxlの弱み
お前chromeでHDR画像みるの？みないでしょ
見る見ないは人の環境によるでしょ…
あった方がいいって話よ
ゆうてAV1/AVIFもHEVC陣営の特許管理会社が勝手にライセンス契約プログラム発表して特許料請求してきてたやん？
あれどうなったんやろか
ms「ver1完成後にライセンス料吹っかけて総横取りしたほうがええやろ？」
MSは十数年前に自社規格を国際標準化して普及させようと頑張ってた先駆者だからな…VC-1然りJPEG XR然り
正直後発のAV1やJPEG XLに対して複雑な心境なんじゃないかな…
AVIFはAOM陣営？
https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg
こんなjpegxl自体の長所短所はわかってるから、マイクロソフトの取得した特許による影響の方を書いてほしかった
むしろ性能的に優れてるって反論なのだけど
なんで個々の性能では各フォーマットに劣るなんて要約になったの
その記事の趣旨は、JPEG XLが他のフォーマットと比較してデフォルトで有効化するほど利点があるわけではない、に対する反論だから
ちなみにChrome開発チームは特許関係は問題に上げていない
その後libjxl 1.0が出て暫くしたら再度サポートされる可能性も十分あると思う
AVIFはエンコードとデコードが冗談みたいに遅いっていう明確なデメリットがあるからそのAVIFと他が同等なら完全な上位互換なんだわ対応するメリットがなく切り捨てられるのはAVIFの方なんだわ
>jonsneyers 16 minutes ago | root | parent | next [–]
>とはいえ、私たちは合理的な期間、つまり2023年のどこか、できれば前半にlibjxl 1.0のマイルストーンに到達することを目標としています。
libjxl 1.0が今年中にリリースされることは無い模様
そりゃChromeも呆れてサポート外すわな
>I wonder what is the Mozilla's position on JPEG XL.
>JyrkiAlakuijala 2 hours ago | root | parent | next [–]
>MozillaのエンジニアはJPEG XLに熱狂的ですが、彼らのディレクターはそうではありません
>jonsneyers 9 minutes ago | root | parent | next [–]
>基本的に、Mozilla の立場は、Chrome が最初にそれを行うまで、この面では何もしないということのようです。 Mozilla の意思決定者は、Chrome コーデック開発者と同様に、非 AOM コーデック、特に JXL をブロックすることで、「AOM への忠誠を証明する」必要性を感じているとしか思えません
第一項の、実験的なフラグやコードを無期限に残すべきではありません。が理由の大部分だったと改めて思うよ
Chromeもまさかフラグ状態が2年以上継続するとは想定していなかったんだろう
かといって現在のlibjxl実装は正式サポートできるレベルに達してない→削除という塩梅な気がするわ
お㍗ル
それキミの実装が悪いのでは？
ちなみにFirefox側の同じようなチケットは数個の意見が書かれた後、ここで議論するなと怒られて
関係者以外書けないように変更された
libjpegみたいにエラー時にハンドラを渡してくれるだけでいいから
何様だよおまえ
カスみたいなお前のゴミアプリひとつjxl対応したところで誰も使わないから
自意識過剰過ぎる🤣
さすがに何も考えてないわけないだろうし
愚かで間抜けでハゲな人類の歴史を見ているようだ
o 採用する価値がない
もうハードウェアの進化もじょじょに鈍化してきて容量問題が深刻になってきてるんだからソフト屋はもっとハードウェアリソースを節約する方向へ努力すべきだと思うんだよね
マイクロソフトとかアップルとかアマゾンとか
正しく表示されなくて半ば害悪になっている側面もあるからなあ
以来HDR出力はゴミとしか思ってない
ウェブの進化を支援することは困難なことであり、私たちは難しい選択をすることを要求されます。
また、ブラウザやデバイスのパートナーから、フォーマットを追加するたびに（金銭的またはハードウェア的な）コストがかかると聞いており、これらのコストが Google 以外の人々によって負担されていることを強く意識しています。
新しいメディアフォーマットを評価するとき、まず問われるのは、そのフォーマットがウェブに最適かどうかということです。
たとえばJPEG XLのような新しい画像フォーマットでは、さまざまな要素を総合的に検討する必要があります。
たとえば、さまざまな画像の圧縮性能、小さな画像の高速レンダリングを可能にする高速デコーダ、大規模ユーザーにとってエンコーディング費用が妥当となるハードウェアサポートを備えた高速エンコーダ、新たなフォーマットのサポートを追加するのではなく、既存のフォーマットを最適化し新しいユースケースに対応できるか、他のブラウザやOSはサポートしているか、などです。
データを精査した結果、ChromeのJPEG XL実験を中止し、実験に関連するコードを削除することを決定しました。 今後、数週間のうちにデータを公開できるよう努力します。
ChromeでJPEG XLを使いたい人にとって、WebAssembly（Wasm）の実装はパフォーマンスも高く、前途洋々であると信じています。
サイト側が対応なんて、そんなことできるの？
cloudinary.comのJPEGXLコンバータはWASMで動いてるはず
ブラウザをavifに対応させるやつとかあるので
出来ないことはないが余計な読み込みが増えるからね…
https://github.com/Kagami/avif.js
https://jpegxl.info/fallbacklogo.jpg
＞たとえば、さまざまな画像の圧縮性能、小さな画像の高速レンダリングを可能にする高速デコーダ、大規模ユーザーにとってエンコーディング費用が妥当となるハードウェアサポートを備えた高速エンコーダ
これXLはエンコード遅くて対応する価値無いって事だよね
>数週間のうちにデータを公開できるよう努力します。
って書いてあるんだしそれ待つしかなくないか
にわかだけどあまりエンコード遅いって話聞かないけど
xlに変換した後の表示速度やスマホやPCへの負荷が他のフォーマットより重いって事じゃねーの？
ChromeはAVIFですらサポートしてるのにxlは消極的だからな
dav1dのデコードのがよっぽど速い
デコードはそうでもないのか
手元の環境では両者デフォルトのavif speed 6とjxl effort 7で同じぐらいの速度だった
デコードはlibaomを使うとJXLより重くdav1dを使うとJXLより軽いって感じ
もっとトラフィックの削減を気にした方がいいんじゃないですかね
みたいなスレを除いて、基本的に新しいものが好きだから普通
そもそもどっちが上位互換とかでもなく特徴の違うものを並べて特定要素で優劣つけるのは何の意味もなくて浅はかだけど
まあJPEG Xで想定されるWebのユースケースがすべて他で問題ないっていうデータをGoogleが出してくれたらある程度白黒つくよ
スレタイ通りの画像コーデックはjxlしか無かったからな
うちのロースペに片足突っ込んだマシンだとavifdec(libdav1d6)よりdjxlの方が速かった
特に大型ディスプレイ向けの壁紙なんかだと結構な差に
pngかavifでいいじゃん、なにか問題あるの？
公正な判断とは言えないし、今回のでChromiumはGoogleの所有物だと強く感じたな
ゑ？知らなかったの？
代わりがあります！我慢します！とか奴隷かよ…
専門版で無知晒して喜ぶ本物の知恵遅れなんてそうそういないし
現実で認められないから優しく相手してあげるほど喜んで増長する
なんでデコードがあんなに遅いんだよ
jxlは不利になる情報を出さないからしょうがない
これ言い訳にしてきたらAOMのご機嫌取りしたって自白と同義だ
https://mevius.5ch.net/test/read.cgi/cg/1668339156/
新しいスレッドを立ててください。
life time: 6012日 13時間 11分 48秒
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。
ニュース
- 政府、コロナワクチン啓発に「YouTuber起用動画9本・３２００万円支出」認める「接種の重要性など、正しい情報を知っていただくために」 [Hitzeschleier★]
- 【文春】M-1王者コンビ「ウエストランド」河本太、タクシー運転手に暴行トラブル「腕に噛みつき、前歯が欠け…」 [Anonymous★]
- 「ドンドンショボくなる」大阪万博にまたまた“ガッカリ”報道、軟弱地盤のため「乗り物型」展示ゼロ [バイト歴50年★]
- 【鉄道】女性「電車で隣に座ってくる男キモい」SNS“炎上”…男女で《賛否》真っ二つ、それぞれの言い分とは ★2 [ぐれ★]
- パリ五輪公式服装、業者は非公表 JOC [おっさん友の会★]
- 『平和堂』公式X、いなり寿司誤認逮捕事件「いなりずしを渡した知人もダメ」投稿2件に「いいね」 「誤った操作」と陳謝 [Hitzeschleier★]
- 【実況】博衣こよりと周防パトラのドキドキたこパ🧪 ★7
- 【実況】博衣こよりと周防パトラのドキドキたこパ🧪 ★5
- 【実況】博衣こよりと周防パトラのドキドキたこパ🧪 ★6
- 日本史上最高のアスリート「筋トレしてる奴、全員バカですwトラやライオンは筋トレしません」 [308389511]
- よしよしってレスしろｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
- お前らって会話が成立するから怖いわ…