2016-05-14 20 views
1

Linux用のドライバがなく、wifi経由で通信をしようとしているEpson Ex5220があります。私は、Windowsマシンからパケットトレースを介してキャプチャした画像をドライバで接続して送信することはできますが、受け入れ可能な画像を作成することはできません。ここに問題がある場所があります:Epsonプロジェクタに画像を直接送信すると、jpeg画像のデコードに問題が発生する

データ送信では、jpegイメージがこのようにヘッダーを付けて送信されます。

00:00:00:01:00:00:00:00:02:70:01:a0:00:00:00:07:90:80:85:00 

00:00:00:04 - Number of jpeg images being sent (only the first header) 
00:00 - X offset 
00:00 - Y offset 
02:70 - Width of Jpeg image (624 in this case) 
01:a0 - Height of Jpeg image (416 in this case) 
00:00:00:07:90 - Unknown (I believe it's a version number perhaps) 
80:85:00 - (What I'm after) Some count of data units? 

ヘッダーに続くのは、通常のjpegイメージです。ヘッダーをはがすと画像が見えます。ここでは3バイトの部分キャプチャのスクリーンショットが強調表示されています:私は80:85:00にそれらの最後の3つのバイトを設定することにより、ベースラインであると思われるものを発見した

Partial capture showing header

。それ以下であれば、イメージは投影されません。また、私がプロジェクタに送ることができる最小の画像サイズは、以下に示す最初の2つの画像と相関する3w×1hです。ここ

は、いくつかの例である:

1A - 全白(RGB565)画像1024×768 - ファイルサイズ12915から4ブロック

#1a - All white image 1024x768

2A - カラー(RGB565)画像1024×768 - ファイルサイズが58577 - のみ3つのブロック

#2a - Color (RGB565) image 1024x768

Iは次に00に3つのバイトを変更:B5:80(インクリメント0x30で中央を編集)

1b - すべての白(RGB565)イメージ1024x768 - ファイルサイズ12915 - 22完全な行と4ブロック。

All white (RGB565) image 1024x768

2B - カラー(RGB565)画像1024×768 - ファイルサイズ58577から7行と22個のブロック。

Color (RGB565) image 1024x768

だから、3バイトのデータ単位とは何かを持っているようです。私はjpegについてたくさんのことを読んできましたが、それでもまだ大部分を消化していますが、データ単位を計算するために何が必要なのか分かっていれば、私の謎は3バイトだと思います。

ADDITIONAL INFO:

プロジェクターのみのデータ送信の内側RGB565 JPEG画像の使用をサポートしています。

+0

ここには参照点を使用するためのJPEGマーカーはありません。 – user3344003

+0

マーカーに関連して9Dが起こるのはどこですか? – user3344003

+0

9Dだと思います。マーカーとの相対的な位置はどこですか? – user3344003

答えて

1

(OPの代わりに掲示)

私はこれを解決できましたが、なぜこれが機能するのか知りたいのですが。ここでは、これらの最後の3バイトの式は次のとおりです。

int iSize = bImage.length; 
baHeader[17] = (byte) ((iSize) | 0x80); 
baHeader[18] = (byte) ((iSize >> 7) | 0x80); 
baHeader[19] = (byte) ((iSize >> 14)); 

私はそれをいじりにうんざりし、単に複数の画像を見て、すべてのファイルサイズと魔法のバイトを書き留めたバイナリにすべてを変換し、離れて打たました私が正式な仕事を強制するまで、ORingのビットシフトをANDingしています。私はこれがjpegデータ単位を計算することに関連しているかどうかを知りたいと思います。私はまだJpegを研究していますが、単純なものではありません!

1

SOSマーカーの仕組みを誤解しているようです。ここでは、あなたの例のいずれかで表示されているバイト:

SOS = 00 0C 03 01 00 02 11 03 11 00 3F 00 F9 FE 

これは誤って圧縮されたデータの2バイト(F9 FE)はSOSに含まれています。 12(00 0C)の長さには2バイト長のバイト自体が含まれているため、実際にはこのマーカーのデータは10バイトしかありません。

F9 FEの前の00バイトは「逐次比較」ビットフィールドであり、プログレッシブJPEGイメージに使用されます。実際には4ビットのフィールドのペアです。

イメージ間で変化するバイトは、最初の2つの圧縮データバイト(最初のMCUのDC値をエンコードします)です。

+0

あなたはこれについて間違った方法をとっています。使用しているデータがJPEGイメージの場合、データにエンコードされたMCUカウントはありません。あなたは間違った情報を追いかけています。 MCUカウントは、画像サイズとカラーサブサンプリングから決定されます。 MCUサイズの倍数でない画像の場合、最後の行/列MCUには未使用のピクセルがあります。データバイトを変更すると、エンコードされたデータが破損し、再同期するまで(間違いなく)不良ピクセルが発生します。バイトをどのように解釈するかについては、JPEG仕様を確認してください。 – BitBank

+0

カラーとサブサンプリングなしの場合、指定した画像サイズ(624 x 416)は78 x 52 MCUになります。 MCUカウントは、イメージの次元から計算するため、明示的に指定する必要はありません。あなたが見ているバイトはチェックサムかもしれません。イメージをデコードできますか? Epsonのドキュメントがなければ、バイトが何であるかを決して知ることはできませんが、あなたの推測はあなたを間違った方向に導いています。 – BitBank

+0

私はあなたのファイルを見て、あなたが知る必要があるすべてを持っているように見えます。各JPEG画像の前の最後の数バイトが、それらを正しくデコードすることを止めることはありません。 「最後の3バイトを減らす」と、画像データが破損し、その時点でデコーダがデコードを停止します(MCUを失う原因となります)。 – BitBank

関連する問題