0

私はVisualC++を使用した画像処理にかなり慣れていません。白黒のTIFFファイルを読み取り、画像を0または1を表す配列の16進値として書き込み、0(黒)のいずれかの位置情報を取得する方法を探しています。または1(白)。

Googleとここにある記事について少し調べた後、https://www.ibm.com/developerworks/linux/library/l-libtiff/#resources次の簡単な質問があります。関連する記事を教えてください。頭を包むことができなかったほど多く、その間私は検索と読書を続けます。

LIBTIFFを使用してTIFFからピクセル位置情報を抽出することは可能ですか?

繰り返しになりますが、すべての画像形式に慣れていないので、画像が16進値の2D配列で構成されていると思わずにはいられませんでしたが、ビットマップ形式の方が適切ですか?そのように考えると、その高さから2D配列にマッピングされた「白」または「黒」の位置を書き込めるかどうか疑問に思います。「黒」または「白」のどちらかの場所が欲しいのですが、それは可能ですか?画像を表す0と1の配列は本当に必要ありません。必要かどうかはわかりませんが、

4 x 2 BW画像のTIFFの例:

  • 黒、白
  • 白黒
  • 黒黒
  • ホワイトホワイト

mappingNonPrint()という名前の関数の下でptLocArray[imageHeight][imageWidth]のようなものに出力します

  • 2 1
  • 4 4

またはmappingPrint()という名前の関数の下

  • 1 2
  • 3 3

LIBTIFFでは、TIFFファイルをどの方向/方法で読み取りますか?

理想的には、TIFFファイルを上から下に垂直に読み取ってから、次の列に移動してから、上から下にもう一度開始するようにします。しかし、私の腸はそれがおとぎ話であり、画像処理に非常に慣れていないことを教えてくれます。たとえば、単一のストリップのものなど、TIFFがどのように読み取られるかを知りたいです。

追加情報

ピクセル位置が必要な理由を追加する必要があると思います。位置フィードバックを提供する光学式ロータリーエンコーダーを使用して、円筒形のロールプリンターを作成しようとしています。ドキュメントの高さはロール面の円周を表し、ドキュメントの幅は回転数を表します。

以下は、私のENC_reg()の非常にテストされていないロジックであり、画像処理部分とはほとんど関係ありませんが、これは、読者がtiff画像の処理された配列で何をしようとしているのかを理解するのに役立ちます。iは0からimageHeightまでのインデックスが付けられますが、各要素は0からimageHeightまでの任意の数であり、tiff画像の黒を含む場所に対応する112、354などです。jは0からimageWidthまでのインデックスが付けられ、そこにある各要素も0からimageWidthまで始まります。たとえば、ptLocArray [1] [2]は、列2に黒いピクセルがある最初の場所を意味し、そこに格納される値は231である可能性があります。列2の先頭から数えて231番目のピクセル。

array [imageHeight][]は代わりにarray[maxnum_blackPixelPerColumn]である必要があることに気付きましたが、1の数、つまり列ごとの0をカウントする方法がわかりません。先に述べたように、1と0は正しい順序で並んでいます。

void ENC_reg()

{

if(inputPort_ENC_reg == true) // true if received an encoder signal

{ 

            ENC_regTemp ++; // increment ENC register temp value by one each time the port registers a signal

                if(ENC_regTemp == ptLocArray[i][j])
                {
                    Rollprint(); // print it
                    i++; // increment by one to the next height location that indicates a "black", meaning print

                    if (ENC_regTemp == imageHeight)
                    {
                    // Check if end of column reached, end of a revolution
                    j++; // jump to next column of the image (starting next revolution)
                    i = 0; // reset i index to 0, to the top of the next column
                    ENC_regTemp = 0; // reset encoder register temp to 0 for the new revolution
                    };
                };



            ENC_reg(); // recall itself;
        };
    }
4

1 に答える 1

1

あなたの例を読んでいると、画像の各列に2つの配列が必要です。1つはその列に黒いピクセルを持つ行の数を含み、もう1つは白いピクセルを持つ行のインデックスを含みます。今のところ?

これは確かに可能ですが、大量のメモリが必要になります。圧縮されていない場合でも、グレースケール画像の1ピクセルは1バイトのメモリを消費します。ビットパッキングを使用して、8ピクセルを1バイトに詰め込むこともできます。一方、255行以下の画像に制限しない限り、各列インデックスを表すために複数のバイトが必要になります。また、列の終わりをマークするための追加のロジックが必要になります。

私のポイントは、「0と1の配列」を使用してみてください。これは、達成がより簡単で、メモリの面での要求が少なく、実行がより効率的であるためです。

于 2012-07-10T10:10:55.340 に答える