DropboxがJPEG画像をロスレス圧縮できるツールを公開、平均22％サイズを縮小できると主張 100
ストーリー by hylom
mozjpegで圧縮後これで圧縮するとどうなるのだろう 部門より
mozjpegで圧縮後これで圧縮するとどうなるのだろう 部門より
insiderman 曰く、
DropboxがJPEG画像をロスレス圧縮するツール「Lepton」をオープンソース（Apache License 2.0）で公開した（OSDN Magazine）。
LeptonはJPEG形式画像ファイルを圧縮するツールで、圧縮後は「.lep」という拡張子の独自フォーマットファイルに変換される。.lep形式に変換することで、平均22％ファイルサイズを縮小できるという。また、.lep形式ファイルからJPEG形式に復元した場合、オリジナルのJPEG画像とバイト単位でまったく同じものが生成されるという。
技術的な詳細についてはDropboxのTech Blogで紹介されているが、8×8ピクセルのブロック単位で処理を行うというJPEGのエンコード方式に注目し、その端をうまく処理することで圧縮を行うという技術のようだ。
JPEGよりも圧縮率が高いとうたう画像フォーマットはいくつか提案されているが、普及しているJPEGを置き換えるには至っていない。そのため、こういったアプローチでストレージ容量の削減を狙うというのは良いアイデアだと感心した。
BPGが世の中で全然相手にされなかったのが悲しい (スコア:4, 参考になる)
「Fabrice Bellard氏、JPEGの置き換えを目指す新画像フォーマット『BPG』を開発 [opensource.srad.jp]」
高圧縮にしてもブロックノイズやモスキートノイズが出ないなど、すごく優秀なフォーマットだったのに。
あれが次世代の画像圧縮フォーマットとして、デジカメなどにも搭載されるようになってほしかった。
Re: (スコア:0)
画質と圧縮性能は優秀だけど、エンコード速度がちょっとね……。
デジカメに搭載は厳しいでしょうHEVCとか、
Re: (スコア:0)
JPEGやmp4だってハードウェアアクセラレーションがあるから載せられるんで、
HEVCのハードウェアアクセラレーションが載るようになれば、そこのところは心配しなくていいと思う。
将来4K動画が一般的になってくると、H.265じゃないとやってられんでしょ。
Lossless JPEG や JPEG-LS とはいったい何だったのか (スコア:3, 興味深い)
JPEG 2000 もロスレス圧縮をサポートしていたはず。
GIF や MP3 にもいえることだけど、広く普及してしまったフォーマットは、より優れた後継規格が登場しても、滅ぼすのがあまりにも難しい。
# MNG は死んだ。APNG はいっこうに普及しない。未だ滅びぬ GIF アニメーション。どうしてこうなった
Re:Lossless JPEG や JPEG-LS とはいったい何だったのか (スコア:5, すばらしい洞察)
「JPEGのフォーマット形式に着目すると、画像品質を落とすことなくデータをさらに削減できる」というだけで、Lossless JPEGのように「もともとの画像に対してのロスレス圧縮」とはまた違う話ですよね、これ。
（普及するとは限らない、という点については同感です）
Re:Lossless JPEG や JPEG-LS とはいったい何だったのか (スコア:3, 興味深い)
.lepは普及しなくてもDropBox内で適用するだけでも効果有るんじゃないですかね
1. DropBoxにupした.jpgは強制的に.lepに変換
2. ユーザーからは.jpgとして見せる（ユーザーは.lepになったことには気付かない
3. ユーザーには.jpgのまま見せているので、圧縮前のサイズだけストレージ消費していることにする
4. ユーザーがダウンロードするときは.jpgに戻したものを送信
ってやるとDropBox側のストレージが軽減されると
Re:Lossless JPEG や JPEG-LS とはいったい何だったのか (スコア:5, 参考になる)
Dropbox社内ではオンラインストレージに保存されている160億件の画像の圧縮に使われており、 [osdn.jp]
すでにペタバイトレベルで容量の削減を実現しているという。
ということなので、すでにやっているようですよ。
というか内部でずっと使っていた技術を、このたび切り出して独立したツールにして公開したという話じゃないかな。
Dropboxはこの公開で何の得があるんだろう。
GoogleはAndroidにこれを組み込んで、スマホのストレージを節約できるようにしてくれないだろうか。
Re: (スコア:0)
Re:Lossless JPEG や JPEG-LS とはいったい何だったのか (スコア:2)
実はAndroidでGoogle Playを開いたときの画像フォーマットに使われてたり、Android版Chromeでデータセーバーを有効にするとproxyで画像がWebPに変換されてたりと、Androidユーザーは知らず知らずのうちに使ってる。
Re:Lossless JPEG や JPEG-LS とはいったい何だったのか (スコア:2)
WebMもだけど、結局マルチフォーマット用意しているから、
容量削減にまったくなっていないってゆう。
Re: (スコア:0)
WebPはSDカードで容量を増やせないNexusで重宝している。
JPEGだと容量が足りなくなって、WebPで作り直した。
Re: (スコア:0)
要するに提案者のGoogleがゴリ押ししてるだけってことなのでは。提案者が使っているのを普及例に挙げられてもなあ。
Re: (スコア:0)
> 要するに提案者のGoogleがゴリ押ししてるだけってことなのでは。提案者が使っているのを普及例に挙げられてもなあ。
世界の8割のスマホがそれで動いてる以上はその論調には無理がある
Re:Lossless JPEG や JPEG-LS とはいったい何だったのか (スコア:1)
ロスレスJPEGはDNGやキヤノンCR2などデジカメRAWファイルの内部フォーマットとしてちゃんと使われているよ。
Re:Lossless JPEG や JPEG-LS とはいったい何だったのか (スコア:1)
意外と病院とかでCTとかの画像形式として採用されてたりもします
Re:Lossless JPEG や JPEG-LS とはいったい何だったのか (スコア:1)
> 未だ滅びぬ GIF アニメーション
滅んでいないのは名前だけで、Twitterでは無音のMP4動画に変換されてたりするけどね。
Re: (スコア:0)
○ 十分な機能を持ったフォーマットは、意味もなくより優れた後継規格が登場したところで、滅ぼされるわけがない。
今さら静止画の圧縮率が上がったところで、何だというのだ。
Re:Lossless JPEG や JPEG-LS とはいったい何だったのか (スコア:1)
新しいフォーマットが古いフォーマットと同じくらい気軽に使用できれば十分
JPEG2000が普及しないのはJPEG2000をデコードできる環境が普及してないのが原因
まさに鶏玉ではあるけどね
Re: (スコア:0)
Gifのリプレースは.mp4だろ。ツイッターがやってる。
サーバサイドから見ればJpegでも積もれば山になるから容量の削減には意味がある。
アプリケーションならアプリで復元処理を行えばいいしブラウザ向けのページもJsでやればいいな。
Re: (スコア:0)
JPEG2000はとびついたけど、表示が遅い・エンコードが特定ソフトのみなんかで結局使わなくなったな。
まだストリーミングはRealプレイヤーなんて時代だった頃のはずで記憶もあやふやだが。
とはいえ今はPNGで保存してJPEGは使わんけど。
Re: (スコア:0)
JPEGの登場当時に一般に普及していたパソコンで展開するには
JPEG2000と比較できない位展開が遅かった
あまりにも遅くて、デコード専用の拡張カードが10万円以上で発売もされた
しかもJPEGで扱える色数を表示できる環境を個人で持ってるのは一部の金持ちだけだった
それでも爆発的に普及したのは、ほぼ同時にWebが普及しだしたのと
記憶媒体や回線が貧弱だったため、他の可逆圧縮と比較しても選ぶメリットがあったからだろう
これから新フォーマットを普及させようと思うと、当時と同じレベルのインパクトが必要なのかも知れない
Re: (スコア:0)
懐かしいｗ
当時は圧縮率いろいろ試しながら「目的の画質を損なわない範囲でどこまで削れるかユーザーが試してみるソフト」とかあったなぁ
Re: (スコア:0)
まあ、バックアップとかストレージサービス用とかだろね、これは。
自分の写真なら、もっと良い感じにロッシーな別の形式で、おおむねクオリティはそのままで、より圧縮するという選択肢もあるけど。
ストレージサービスだとそういうわけにはいかないので。
既にロッシーな物をロスレス圧縮という発想はなかった。おもろい。
Re: (スコア:0)
MASL!MASL!
Re: (スコア:0)
MNG/APNG(的なもの)は欲しくなる
GIFじゃ256色ディザリングが掛かってどうしても汚くなるしな
まあ上にあるようにMP4でもいいんだけど出来れば専用がいい
Re: (スコア:0)
画像のロスレス圧縮技術じゃないよ。JpegファイルをZipしただけだよ。
Jpegの特徴を掴んで、より高圧縮のZipができたよ！ ってのが趣旨だよ。
ちなみに、Jpegの代替になろうとしてる技術が追い求めてるのは、ロスレス圧縮ではない。
単にロスレス使いたいだけならPNGで間に合ってる。
各色8bitを越えるダイナミックレンジ、ブロックノイズが生じず、高周波領域(細かい部分)がシュワシュワしない品質、ってのを求めてる。
ついでに圧縮率も高ければ良いね、って具合で、圧縮率は副次的なものだな。Jpeg後継はロスレスを求めてないし。
でも正直、ここまでjpegが普及しちゃうともう駄目だろね。
一応の共通フォーマットであるDNGのRAWを使うか、jpeg使うかって具合じゃない？
jpegに差分ファイル(あるいは別チャンク)つけて高ダイナミックレンジにするようなのがあってもいいとは思うしあった気もするけど、全然だね。
既存アーカイブ形式への組み込みを希望 (スコア:3)
例えば、jpgファイルを含むデータをzipに圧縮するというとき、対応アーカイバでは、jpgファイルをlep形式で圧縮して格納する。
これを、対応アーカイバで解凍すれば元通りのjpgになり、非対応アーカイバで解凍すればlepファイルが出てくる、というような。
結局lepへの対応が必要になるなら、あえて互換性を持たせる必要もないのかな。
Re: (スコア:0)
zipにはcompression methodってのがあるから前者は容易でも後者はむしろやってほしくないだろ
私の頭が悪いせいなのか (スコア:0)
>>オリジナルのJPEG画像とバイト単位でまったく同じものが生成されるという
JPEG画像の復元率ではなくてバイト数が同じだからロスレスと言っているように聞こえる。
Re:私の頭が悪いせいなのか (スコア:2)
ふつーに
『JPEGなファイルをデコードした画像データ』
と
『lepなファイルをデコードした画像データ』
が一致するというだけだと思う。
それで、jpgよりもlepは小さいですよっていう。
Re:私の頭が悪いせいなのか (スコア:2)
．．．と思ったけど、
『元の*.jpg』
と
『元の*.jpgを*.lepにして、その*.lepを*.jpgに戻したモノ』
が一致するような書き方をしてある。
Re:私の頭が悪いせいなのか (スコア:1)
悪いせいです
Re: (スコア:0)
ビット単位でならOK?
Re: (スコア:0)
単に全く同じものでいいんだけど、
確認するときに「１バイト単位で」差分チェックしたからじゃないかな。
画像を見て「全く同じに見える」と言う曖昧なのに対して、こういったのかと。
Re: (スコア:0)
1ドットが1バイト？
Re: (スコア:0)
何を言っているのかわからん。
Re:私の頭が悪いせいなのか (スコア:1)
というか元記事 [osdn.jp]で、
圧縮された画像は、ビットレベルで完全に同一の画像に復元できるという。
と書かれているのに、なぜにタレコミ人は「バイト単位で」などという謎の表現に書き直したのか。
Droboxのブログ [dropbox.com]でも
Lepton preserves the original file bit-for-bit perfectly.
と書かれている。
「JPEGファイルとしては違ってくるけど、それをビットマップ画像に展開すると、ビット単位で元の画像と一致する」という可能性もあり得るのか。
上記のようなことなので、ファイルとして同一性が保証されているようですよ。
一つのページにたくさんの画像があればあるほど効果はありそう (スコア:0)
元々のJPEG画像にZIP圧縮のようなものをかけて、そのまま閲覧できる規格ということでいいのかな？
年々ブラウザの食われるメモリは増えてるからせめて展開前のデータ量は安くしたいね
価値がないわけではないと思う
記録メディアとデジカメの解像度から考える (スコア:0)
記録メディアはすでにGとかTの単位、デジカメの解像度はデフォルトでもう適正印刷サイズA2とかザラ。
保存されるメディアも保存する人も容量とか考えずに大雑把に使ってるのに、「容量二割削減」とか言われても。
正直需要ないと思います。
// このファイル開けないんですけど、って質問が溢れるほうがよっぽど嫌。
Re: (スコア:0)
画像倉庫やさん
(いんすたなんとかとか いんすたなんとかとか いんすたなんとかとか)
は歓喜すると思うぞ
(もう独自にやってるかもしれないが)
Re: (スコア:0)
深い階層のストレージに落ちる前にふつうにやってるだろう。
Re: (スコア:0)
ストレージ容量が減っても
デコードがクッソ重かったら
画像ストレージ屋なんてそれこそ画像を表示するのが仕事なんだから
その分の超大多数処理が発生してパンクしそう。
ローカル側でやるなら別段問題無いだろうけど
少なくともローカルでやるならそっちのPCにエンコード・デコードのDLLなりいるよね。
サーバでやるならユーザーは意識しないから大変結構、でもサーバが大変。
ローカルでやるならユーザーに何らかのソフトなりを入れてもらわないとで没。
Re:記録メディアとデジカメの解像度から考える (スコア:1)
＞少なくともローカルでやるならそっちのPCにエンコード・デコードのDLLなりいるよね。
jpgへのデコードくらいなら JavaScript でできるんじゃないか？
普及が難しい理由 (スコア:0)
現像ソフト, photoshop, illustrator, ブラウザ がPC,スマホ（タブレット）でそれぞれ対応しないと…
OS標準ファイラーのプレビュー対応も。
色んな言語でライブラリが出れば普及する？
Re: (スコア:0)
オープンソースにすることで普及やフィードバックに貢献するだろうが、Dropboxが内部で使う分には普及など必要ない。
Re: (スコア:0)
”十分な目ん玉”を期待しているのでは？
WebPと何が違う (スコア:0)
DCT済んだのをハフマンじゃなくてVP8 の算術符号で詰めたら小さくなりましたって
いうのをさも新しそうに言うのはいかがなものか。
あんまし使い道がない代表例 (スコア:0)
ビジネスでいえば、
ストレージで2割なんて1年で意味がなくなるようなもので
そのために将来に渡り圧縮/展開のための処理を食うものに依存して保存して保守してくほうが無駄が多い
しかもオンラインストレージなどでは
利用者間を超えて重複排除しまくりつつ
類似コンテンツ検索をガンガンかけてビッグデータ（笑 を作ってナンボなのに
それをやりづらくするような真似してどうすんのって感じですね
作ってみたけど自分のところでは使い道がなかったから無償公開したってほうが正しい言い方なんでしょうけど
こんなの使うより (スコア:0)
素直に算術符号使った方がいいんじゃないの？
どのブラウザがデコードできるかどうかはともかくとして
Re:こんなの使うより (スコア:1)
ごめんなさい、測りなおしたら、14%程度でした。
jpegtran で239個のファイルを変換しました。
-copy none:
73082054 byte
-progressive -arithmetic -copy none:
63838851 byte
# 以前もっと大きな差が出たのは、画像処理ソフトがexifにくっつける領域がカットされた影響かも