Q&A
なるほど、そうなんですね
前回の質問で、ファイルをイインポート、表示、出力を行うには、ライブラリというのがあって、それを作ることで、本来は扱えなかったファイルさえも扱えてしまうという事がわかって、今回はjpeg(.jpg、.jpeg)の入出力ライブラリを作ってライブラリについて勉強しようと思い、色々調べました。
###調べたこと
- JPEG（ジェイペグ、Joint Photographic Experts Group）という名前
- 平成4年に誕生
- 非可逆圧縮
- 非可逆圧縮
- 符号化方式
- ファイルの構造
先頭:SOIマーカ 最後：EOIマーカ で挟まれている。
- フォーマット
ヘッダ+画像データ+フッタ で構成されている。
Jpegファイルの開始FFD8(16進数)（確認済）
Jpegファイルの終了FFD9(16進数)（確認済）
FFD8以降はヘッダ
ヘッダはFFDA(sos)で終わるみたいです。（多分確認:ヘッダの量が少ないため、本当にあっているのかが心配）
###本題
前回 Bongo さんに「その中身は他のファイル同様バイト列で、フォーマットによって何バイト目は画像のサイズ、何バイト目は圧縮方式、何バイト目以降は各ピクセルの色...といった具合に様式が定められております。」と教わって、おそらく、調べたFFD8で始まっていたら、Jpegファイルで間違いない、FFD8以降はヘッダ、FFDA(sos)でヘッダの終了 これが決められている事であっていますか？
そして、実際このデータをどのようにして、読み込んで表示をしたらいいのですか？
回答5件
0
書籍「JPEG―概念からC++での実装まで」をおすすめしておきます。
投稿2017/07/01 13:30
総合スコア6191
0
はっきり言いますが、相当な理解が要求されます。
というのも、JPEGは画像をできるだけ小さくするために、DCT（離散コサイン変換）という処理を行っているのですが、画像にデコードしようと思えばもちろんこのDCTも逆変換が必要になります（数学的なバックグラウンドの理解が要求されます）。
そして、既存のライブラリがある以上、自作しても実用的には（既存ライブラリを使えばいいので）あまり意味がありません。残るは自分自身の学習という目的ですが、DCTまで考え出すとなると、「自分で新たな画像フォーマットを作る」ぐらい高度なことをしない限りは、その学習が役立つ場面もそうそうなさそうです。
投稿2017/07/01 10:05
総合スコア145184
0
ベストアンサー
Red, Green, Blueの画素値を8bitずつ並べるといった素朴なフォーマットであれば、画像フォーマットを調べてなんとか自分で解析することも可能ですが、JPEGについてはかなり難しいと思います。
JPEGファイルは離散コサイン変換(DCT)を用いて情報を圧縮しています。大雑把にいうと、画像を構成する個々のピクセル間で画素値がどのように変化するかを「波」として捉え、波の周波数成分のみを記録するという方式です。
従ってこのフォーマットを自前で解釈するようなプログラムを書くためにはDCTの理論から学ぶ必要があります。このキーワードで調べるといくつかの解説ページがあると思います。
Independent JPEG Groupという組織がC言語で実装したJPEGエンコーダーとデコーダーを公開していますのでその内容も参考になるかも知れません。が、離散コサイン変換やJPEGがどこをどのように圧縮する工夫をしているかを学ばずに中身を見てもチンプンカンプンだと思います。自分はかなり昔にこのソースをチラ見したことがありますが、チンプンカンプンでした orz
投稿2017/07/01 10:00
総合スコア18394
jpegsr6.zip というファイルをダウンロードして、ソースコードを手に入れたんですが、さっぱりです・・・
多分一番わかりやすいのがDCTやっているところではないかと思うぐらいややこしい内容だと思います。8x8の画素をある順番でスキャンしてそれをDCT変換で周波数にして、さらに画像としての劣化が少ないように周波数成分を圧縮するためのハフマン符号の作り方とか・・・もう複雑すぎてわけがわからないと思います。でも考え方の解説記事なんかをみるのは面白いと思いますよ。
http://d.hatena.ne.jp/kuriken12/20100115/1263566612
とか・・・
cjpegとdjpeg - JPEGと、他の一般的な画像フォーマットとの変換を行う。
rdjpgcomとwrjpgcom - JFIFファイル内にあるテキストの読み書きを行う。
jpegtran - JPEGファイルに対し、以下のような変換を行う。
ハフマン符号化テーブルの最適化による圧縮率向上。
プログレッシブ形式と非プログレッシブ形式の変換。
一部のアプリケーションが付加する、非標準の固有データの削除。
画像のグレースケール化
反転、回転(90度単位)
クロッピング(切り取り)
という情報と、ソースコードがあるので、もうすこし見てみたいと思います。
0
まずは
- ITU-R BT.601
- ITU-R BT.709
- ITU-R BT.2020
について調べて、JPEGで用いられる色空間であるYCbCrと普段よく使われるRGB空間との変換を勉強されてはいかがでしょうか？
ref:
なおJpegは難しいからBITMAPを、という話が出ていますが、それも十分難しいのでppm(P6)をやってみるのがいいと思います。
投稿2017/07/01 14:10
編集2017/07/01 14:13
総合スコア5850
Jpeg ＞ BITMAP ＞ ppm(P6) という順番ですか？
また、PNG、TIFF を含めるとどのような順番の難しさになりますか？
TIFFは知らないのでスルーして、
ppm(P3) < ppm(P6) << BITMAP <<<< PNG <<<(越えられない壁)<<< JPEG <<<<(越えられない壁)<<<<MPEG4(動画)
PNGならなんとか勉強すればできるって感じですか？
JPEGなども、世の中にはいくつかソースでているので、それを真似てみるのも一つですかね？
可逆圧縮ならまだ比較的理解しやすいと思います(画像の前にzlibの勉強をしましょう)。DCTやらが必須知識になる非可逆圧縮のものは全般に難易度が極めて高く、非可逆圧縮の動画はこれに加えてblockごとの圧縮制御やI,P,B-frame、インターレース、音声同期、CFR/VFR、動き予測などなどと、undocumented な独自拡張との戦いが始まり人間をやめているのでつらいです。
今主流な動画圧縮がh.264なんですが、その後継のh.265のさらなる後継を開発しているという話を去年(2016)NHK技研の公開で聞いたときは唖然としたものだ。奴ら人間をやめてやがる・・・
http://rigaya34589.blog135.fc2.com/blog-entry-788.html
分かる人には分かる世界という事ですか・・・・
↑になるには、何度か人間をやめないと入れない世界だと言うことですよね？
少なくとも私にはついていけない。PNGはなんとなくわかるけど自分で触りたくない、libpngすら触りたくないのでOpenCVから扱う怠け者です。
なんにせよ数学的な知識を大いに要求されるので(行列演算、統計数学を始めかなり深く広く)辛い。
なるほど、ありがとうございます。
0
まずはWindowsの基本フォーマットであるビットマップの入出力処理を自作してみてはどうでしょうか？
JPEGに比べると単純なフォーマットだと思いますが、インデックスカラーからフルカラーの32bit αチャンネル付き画像まで幅広く対応していて、インデックスカラーのみRun Length Encodingと言う比較的簡単な圧縮も行なうことが出来るので、非可逆圧縮以外の画像入出力の基本はおさえてあると思います。
投稿2017/07/01 11:45
退会済みユーザー
総合スコア0
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/07/01 13:37
2017/07/01 14:01