JPEGの後継画像フォーマットについて議論するスレ

**名無しさん＠お腹いっぱい。** · 2006/05/29(月) 07:21:12

JPEG 2000は心じゃったの？
Windows Media Photoの可能性は？
動画フォーマットがどんどん進歩している中、取り残された
静止画フォーマットの将来について語るスレです。

**名無しさん＠お腹いっぱい。** · 2022/06/26(日) 14:53:11.25

>>648
いやなんでそこ切るんだよ
あとさっきのデータには4コアでやってるって書かれてる

**名無しさん＠お腹いっぱい。** · 2022/06/26(日) 15:10:38.67

え?
jpegxlはだけマルチコア使って速いって主張だったの??
別に他も使えるならご自由に使っていいよって条件かもしれんが
そうだったならびっくり

**名無しさん＠お腹いっぱい。** · 2022/06/26(日) 15:26:20.90

詳しくは言及されてないけど、実験してみてそうだったならそうなんじゃね？
マルチコア有効化してどうなるかやってみると分かるかもね

**名無しさん＠お腹いっぱい。** · 2022/06/26(日) 15:34:48.28

今時マルチスレッド使わないという選択肢はない
JPEG XLはわざわざマルチスレッド向きのデータ構造にしてあるんだから

**名無しさん＠お腹いっぱい。** · 2022/06/26(日) 15:37:37.76

jpgxlはビットストリーム自体の仕様見ると、画像をブロックごとのグループに分割して、並列処理できるぽっくなってたから、その場合はマルチスレッド有効にすれば速くなるのはおそらく確かだと思う

俺はそういうの抜きに計量量自体が少ないから速いのかと思ってた

**名無しさん＠お腹いっぱい。** · 2022/06/26(日) 15:42:51.52

他がマルチスレッド対応してないのにずるいぞ！平等に競争だ！ってしたくなる気持ちはまあわからんでもないが…

**名無しさん＠お腹いっぱい。** · 2022/06/26(日) 16:02:16.36

今時、マルチスレッド対応は当たり前で、マルチスレッド対応してないフォーマットでも、画像を複数枚をマルチスレッドで同時にデコードしたりするわけど

そういう場合においてはjpegxl自体が軽いわけじゃないから、jpegxlに変えたところでトータルとしては変わらないってことだよな..

画像1枚だけをデコードする場合はすばらしいということね
元からマルチスレッドで複数枚を同時にデコードするケースでは...

こういうことか

**名無しさん＠お腹いっぱい。** · 2022/06/26(日) 16:50:52.73

複数画像並列読込時こそマルチスレッドとプログレッシブレンダリングが効果を発揮すんじゃないの

**名無しさん＠お腹いっぱい。** · 2022/06/26(日) 16:58:48.91

プログレッシブ機能も切ってそう

**名無しさん＠お腹いっぱい。** · 2022/06/26(日) 17:01:55.14

>>648
こんなとこにいないでqiita にでも結果を投稿して思う存分論弁してくれ

**名無しさん＠お腹いっぱい。** · 2022/06/26(日) 17:14:05.15

基本的に圧縮率と計算量はトレードオフだからな～
だから皆クッソ難しい並列処理実装の効率化高速化で血反吐はいてるわけで

**名無しさん＠お腹いっぱい。** · 2022/06/26(日) 18:32:01.30

PNGは忘れたしWebPは知らないけどJPEGはブロック単位で圧縮してなかったっけ？
そっちも並列処理できそうな気がするけどライブラリにその機能はないのかね
あるいはできないのか

**名無しさん＠お腹いっぱい。** · 2022/06/26(日) 21:20:15.96

>>655
>元からマルチスレッドで複数枚を同時にデコードするケースでは...

それも試してみたら？

**名無しさん＠お腹いっぱい。** · 2022/06/27(月) 01:03:28.19

4枚の画像を1枚毎に4スレッド割り当てて1枚ずつ順番にデコードするならJPEG XLが速いけど
4枚の画像を1枚毎に1スレッド割り当てて4枚同時にデコードするならWebPやAVIFの方が速いってことでしょ
だいぶ前に自分で実験してみたらそうなった

**名無しさん＠お腹いっぱい。** · 2022/06/27(月) 06:45:43.75

結構試してる人いるんだな
デコード関係は全然比較上がってないからどっかで見れたらいいなあ

**名無しさん＠お腹いっぱい。** · 2022/06/27(月) 06:53:19.08

この手のチューニングって大体機能が揃ったあとに行われると思うから1.0.0が出るまでは参考程度にしたほうが良さそう

**名無しさん＠お腹いっぱい。** · 2022/06/27(月) 07:19:40.63

なんだ、jxlってゴミやん

**名無しさん＠お腹いっぱい。** · 2022/06/27(月) 07:26:40.25

対立煽りにしても流石に雑すぎるぞ

**名無しさん＠お腹いっぱい。** · 2022/06/27(月) 18:32:17.62

MozJpegでエンコードされたjpegファイルを使って
MotionJpegファイルを作ったのですが、
VLCやMPC-BEであれば再生出来たのですが、
WindowsMediaPlayerで再生する事が出来ませんでした。
(エラーとかは出ずに再生時間分黒画面)

WindowsMediaPlayerで再生可能なMozJpeg製MotionJpegを
作る事は出来ないのでしょうか？

**名無しさん＠お腹いっぱい。** · 2022/06/27(月) 18:40:32.16

>>667
スレチ

**名無しさん＠お腹いっぱい。** · 2022/06/28(火) 13:12:04.44

>>668
jpeg関係だからイケるかなと思いましたかダメでしたか
すみませんでした

**名無しさん＠お腹いっぱい。** · 2022/06/29(水) 08:35:35.68

結局圧縮率も高くデコードも早いwebp最強なんだな

**名無しさん＠お腹いっぱい。** · 2022/06/29(水) 13:14:59.70

webpってプロ仕様に耐えられないウンコ野郎じゃないか?
色深度8bitのみ?
lossyはyuv 4:2:0のみ?

**名無しさん＠お腹いっぱい。** · 2022/06/29(水) 13:19:15.79

次世代としてさすがにこれはひどいだろ??

**名無しさん＠お腹いっぱい。** · 2022/06/30(木) 01:42:24.67

web用途ならwebpで十分なんだよなぁ

**名無しさん＠お腹いっぱい。** · 2022/06/30(木) 03:02:43.27

web用途しかないとも言える

**名無しさん＠お腹いっぱい。** · 2022/06/30(木) 03:19:46.15

ていうかweb用の画像フォーマットを話すスレじゃないからwebpは単純にスレチじゃね

**名無しさん＠お腹いっぱい。** · 2022/06/30(木) 03:52:42.51

web用途に限ればwebpは後継になり得るな
すでに普及してるし

**名無しさん＠お腹いっぱい。** · 2022/06/30(木) 03:58:49.98

ぶっちゃけweb用途でなければ保存容量を気にしないから、いままでどおり高画質jpegでいいわw

**名無しさん＠お腹いっぱい。** · 2022/06/30(木) 08:06:47.68

JPEGはビット深度が24 bitしか使えないからダメ
HDRに対応してない

**名無しさん＠お腹いっぱい。** · 2022/06/30(木) 10:07:43.67

https://pbs.twimg.com/media/Eu2CYsgXEAM0BlF.jpg

**名無しさん＠お腹いっぱい。** · 2022/06/30(木) 11:34:49.55

>>679
よく見るとスピード欄にsingle coreの文字が
流石にこれは嘘や
webpもデコード遅いけどjpegxlと同じくらい
jpeg>png>webp=jpegxl(1コア)

ただ、jpegxlはマルチコア利用すればjpegすら越えられる

**名無しさん＠お腹いっぱい。** · 2022/06/30(木) 11:43:45.91

ハイエンドのiphoneのディスプレイはとっくにDisplay P3だかの広色域になってるのに、それを生かせないのはないだろ
>>679でwide gamutのところ

これからはチャネルあたりの色深度は最低10bitはないと
jpegとwebpは脱落

**名無しさん＠お腹いっぱい。** · 2022/06/30(木) 11:52:47.88

シングルコア=シングルスレッドと勘違いしてそうなキチガイおるw

**名無しさん＠お腹いっぱい。** · 2022/06/30(木) 11:55:53.90

>>682
ちがうの？意味は一緒でしょ？

**名無しさん＠お腹いっぱい。** · 2022/06/30(木) 12:05:45.32

厳密には違うけど、このコンテキストそんな細かいこと気にしないだけ
アホがどうでもいいことで騒ぎ立ててるだけ

**名無しさん＠お腹いっぱい。** · 2022/06/30(木) 19:44:36.57

適当に調べてみたけど、
確かに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)

**名無しさん＠お腹いっぱい。** · 2022/06/30(木) 23:00:29.22

>>685
さんくす
ソースもあって有能

**名無しさん＠お腹いっぱい。** · 2022/07/02(土) 09:32:51.41

macOS VenturaとiOS 16でAVIFサポート
https://github.com/WebKit/WebKit/commit/59d774a32243ae8ba59de9178f3b029fd28c4477

**名無しさん＠お腹いっぱい。** · 2022/07/06(水) 17:44:48.36

>>617
今 63% complete

**名無しさん＠お腹いっぱい。** · 2022/07/17(日) 16:02:37.47

69%

**名無しさん＠お腹いっぱい。** · 2022/07/19(火) 11:11:15.87

JPEG XL Part 4 FDIS通過

**名無しさん＠お腹いっぱい。** · 2022/07/20(水) 04:09:39.88

Part3.4が公開まで行くのとv1.0どっちが先だろう

**名無しさん＠お腹いっぱい。** · 2022/07/20(水) 12:26:03.23

cjxlが大幅改修されとる

**名無しさん＠お腹いっぱい。** · 2022/08/06(土) 13:28:03.23

JPEG XL Part 4 IS発行
https://www.iso.org/standard/80619.html

**名無しさん＠お腹いっぱい。** · 2022/08/09(火) 03:39:09.42

>>540
75%まで来たか

**名無しさん＠お腹いっぱい。** · 2022/08/10(水) 00:52:30.95

RC版来た

0.7 release candidate
We expect to have v0.7 release soon.

**名無しさん＠お腹いっぱい。** · 2022/08/10(水) 05:36:06.70

え??次は1.0に一気に行くんじゃなくて
0.7リリースすることしたの??

**名無しさん＠お腹いっぱい。** · 2022/08/10(水) 08:40:38.91

libjxlは生真面目にv1.0までのマイルストーン設定してるし飛び級せんやろ
ちなlibwebpはver1.0になるまで8年以上掛かってて
libavifはv0.9.3からv0.10.0に進級してる（現在v0.10.1が最新）

**名無しさん＠お腹いっぱい。** · 2022/08/10(水) 10:23:05.78

この時点で0.7かと思ってた

Bump version to v0.7 (#571)
https://github.com/libjxl/libjxl/pull/571

**名無しさん＠お腹いっぱい。** · 2022/08/11(木) 17:30:47.44

マイルストーンって1.0しか設定してないやろ
つか、79%になってるな
もうちょいやん
リリースページ見ると0.7.0 Release Candidateがリリースされてるし
突然0.7をぶっこんできた意味がわからん

**名無しさん＠お腹いっぱい。** · 2022/08/11(木) 17:35:01.53

0.7からcjxlのspeedオプションが変わったんだな

**名無しさん＠お腹いっぱい。** · 2022/08/11(木) 20:53:37.45

標準化工程が一段落したしそろそろ更新来る頃合いだと思ってたから予定調和だったわ

**名無しさん＠お腹いっぱい。** · 2022/08/12(金) 19:38:49.17

WebPもAVIFもどんな次世代フォーマットも
「可逆圧縮も非可逆圧縮も両方いけます！」ってのが良くないんだよ

ユーザーは拡張子によってその画像が劣化してるのかどうか概ね知りたいんだから
どっちも同じ拡張子じゃ判りにくくて不快なわけよ

だから明確にふたつに分けろって

可逆圧縮（PNG/GIFなど）の後継 .xxx
非可逆圧縮（JPEG）の後継 .yyy

みたいにな

この心理を理解しないと代替りなんて永久に無理だぞ
性能なんて重要じゃねんだわ

**名無しさん＠お腹いっぱい。** · 2022/08/12(金) 21:15:05.79

拡張子で分けたらいいんじゃないの

**名無しさん＠お腹いっぱい。** · 2022/08/12(金) 21:17:04.11

ごめん昔のレスと混ざってそのまま誤爆した
>>703スルーしていいよ

**名無しさん＠お腹いっぱい。** · 2022/08/13(土) 01:49:07.03

不快かどうかは重要かもな

もうすでに.pngのふりした.webpとかかなりうざいわ＾＾；

**名無しさん＠お腹いっぱい。** · 2022/08/13(土) 02:13:06.41

そんなのあるのか…

**名無しさん＠お腹いっぱい。** · 2022/08/13(土) 02:34:10.49

WebPは最強だからしょうがない

**名無しさん＠お腹いっぱい。** · 2022/08/13(土) 02:45:38.03

>>705
保存しようとしてそれだった時の絶望感

**名無しさん＠お腹いっぱい。** · 2022/08/14(日) 00:54:38.39

>>702
個人的には
可逆圧縮.xxx
非可逆圧縮.yyy
とアニメーション画像.zzz の3パターン欲しい

あんま詳しくないけど同じコーデックの拡張子って後から増やせるのかな

**名無しさん＠お腹いっぱい。** · 2022/08/18(木) 00:44:25.18

81%

**名無しさん＠お腹いっぱい。** · 2022/08/18(木) 23:44:08.50

来月くらいにはワンチャン出るかもってペースなんかねv1.0

**名無しさん＠お腹いっぱい。** · 2022/08/19(金) 01:36:46.94

今年中にはおそらく

**名無しさん＠お腹いっぱい。** · 2022/08/19(金) 11:03:16.98

一段落ついたら、ひとまずv0.8が出るのではないかと

**名無しさん＠お腹いっぱい。** · 2022/08/20(土) 00:25:47.75

Krita 5.1 Released with JPEG-XL Support, Full WebP Support, PSD Improvements, and More
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.

**名無しさん＠お腹いっぱい。** · 2022/08/20(土) 07:02:53.15

HDRはまだだけどアニメーションには対応してる感じなのね
あんま見たことないけどアニメjxlってサイズはどんなもんなんやろ

**名無しさん＠お腹いっぱい。** · 2022/08/20(土) 08:30:47.63

SkiaのJXL対応はよ

**名無しさん＠お腹いっぱい。** · 2022/08/25(木) 23:35:43.43

ChromeのJPEG XLについて
https://bugs.chromium.org/p/chromium/issues/detail?id=1178058

Adobeの人とintelの人が一眼レフカメラで撮った写真のHDRサポートの為に
ChromeのJPEG XLデコードをフラグ無しで有効にしてよーって書いてる
もう製品レベルの話にしたいんだーみたいなノリ？

**名無しさん＠お腹いっぱい。** · 2022/08/26(金) 01:34:03.99

年末までには正式ローンチしそう

**名無しさん＠お腹いっぱい。** · 2022/08/26(金) 12:00:47.60

今のHDR写真はHEIFとか使ってんのかな

**名無しさん＠お腹いっぱい。** · 2022/08/26(金) 17:14:12.49

こんな化石みたいなスレが今になって賑わうとはな

**名無しさん＠お腹いっぱい。** · 2022/08/27(土) 10:50:23.56

XLって画像表示する時の速度や負荷ってwebpやAVIFよりいいの？

**名無しさん＠お腹いっぱい。** · 2022/08/27(土) 11:04:55.51

libjxl-tiny
https://github.com/libjxl/libjxl-tiny
エンコーダのみ

**名無しさん＠お腹いっぱい。** · 2022/08/27(土) 11:07:55.31

>>720
ここ1年で400レスくらい進んでて笑う
てか16年も前に立ったスレなんだなここ…当時の人もういないだろうな

**名無しさん＠お腹いっぱい。** · 2022/08/27(土) 11:11:03.24

JPEG XL Part 3 FDIS通過

**名無しさん＠お腹いっぱい。** · 2022/08/27(土) 17:18:00.59

>>635見た感じあとpart3だけなんだね

**名無しさん＠お腹いっぱい。** · 2022/08/28(日) 07:39:08.59

Part1
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/28(日) 09:05:35.47

>>717
このチケット、今日も引き続き盛り上がってる
担当者っぽい人もコメントしてる

**名無しさん＠お腹いっぱい。** · 2022/08/28(日) 11:54:34.15

>>399の比較のやつアプデされてるね
最新が2022-08-23になってる、何が変わったのかはわからんけど

**名無しさん＠お腹いっぱい。** · 2022/08/28(日) 13:21:32.74

https://pbs.twimg.com/media/FbJ0NvhVsAEDenW.jpg
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

**名無しさん＠お腹いっぱい。** · 2022/08/28(日) 13:31:48.10

やっぱavifは神だな

**名無しさん＠お腹いっぱい。** · 2022/08/28(日) 17:05:57.26

>>717
その下くらいに名前出てるガーディアンってどっかの新聞だっけ
ニュースやってるとこも反応してんだね

**名無しさん＠お腹いっぱい。** · 2022/08/28(日) 17:18:49.59

メディアサイトは画像を多用するからね
あとはまあ漫画村みたいなところとかｗ

**名無しさん＠お腹いっぱい。** · 2022/08/28(日) 18:43:51.41

ガーディアンの同じ人がFirefoxの同じようなチケットにも書いてるね
8か月前
https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c27

**名無しさん＠お腹いっぱい。** · 2022/08/29(月) 12:04:06.41

>>717
ffmpegのlibjxlラッパー製作者がJPEG XLデコーダの技術的な話を寄稿しとるな
曰くJPEG XLのアルファチャンネルの処理はAVIFよりも余分なオーバーヘッド発生が少なく、WebPやPNGといった既存のフォーマットよりもカラーマネジメントがずっとシンプルになっているとか

**名無しさん＠お腹いっぱい。** · 2022/08/29(月) 12:22:03.27

jxlのexamplesのdecoder_onshotを参考にデコーダー組んだけど、マルチスレッド処理してくれてないっぽいんだよなあ
誰か先駆者いる？toolsのdjxl各種を見るのは億劫なんだ

**名無しさん＠お腹いっぱい。** · 2022/08/29(月) 14:23:43.35

>>735
ツイッターに責任者いるからそっちに聞いた方が良いかもよ
日本語でも対応してた記憶

**名無しさん＠お腹いっぱい。** · 2022/08/29(月) 14:50:28.19

JxlThreadParallelRunner作ってJxlDecoderSetParallelRunnerでデコーダに渡したら普通に指定した分だけスレッド走るけどな

**名無しさん＠お腹いっぱい。** · 2022/08/29(月) 15:08:47.06

examplesを見るとこっちはJxlResizableParallelRunnerを使ってて
スレッド数をJxlResizableParallelRunnerSuggestThreadsで決めてるから
マルチスレッドになるかどうかは画像サイズ依存なんじゃない

**名無しさん＠お腹いっぱい。** · 2022/08/30(火) 10:44:58.89

>>722
JPEG XLのHWコーディング用に作られた実装なのかこれ
ゆくゆくはスマホISPとかに搭載されたりするかもな

**名無しさん＠お腹いっぱい。** · 2022/08/30(火) 17:15:09.80

rust実装のjxl-rsも気になってるけど全然動いとらんな

**名無しさん＠お腹いっぱい。** · 2022/08/30(火) 20:47:18.27

今、実装はこんだけあると例のチケットに書いてあるぞ

- 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)

**名無しさん＠お腹いっぱい。** · 2022/08/30(火) 22:21:29.03

rustのやつの(very incomplete)ちょっとウケる
なんとかみんな完成してほしいわね

**名無しさん＠お腹いっぱい。** · 2022/09/03(土) 23:36:03.91

jxlの対応はペイントソフトとかブラウザが優先だろうけど5ch使ってる者としてはimgurも早めに対応してほしいなあ

**名無しさん＠お腹いっぱい。** · 2022/09/09(金) 02:16:53.44

急に動き止まってんだな
iso待ちなんか

**名無しさん＠お腹いっぱい。** · 2022/09/12(月) 12:24:40.44

https://sneyers.info/trade-offs.html

https://pbs.twimg.com/media/FcXZi8bXEAIASny.jpg:orig

**名無しさん＠お腹いっぱい。** · 2022/09/12(月) 13:10:26.51

>>745
どこの論文のやつ？

**名無しさん＠お腹いっぱい。** · 2022/09/12(月) 14:53:16.11

>>745
これjxlはe4で見ても結構悪くないなと思った、早いし

**名無しさん＠お腹いっぱい。** · 2022/09/12(月) 16:42:14.12

>>746
twitterのやつでは？知らんけど