6

私はlibharuに基づくc++でいくつかのpdf生成ソフトウェアに取り組んでおり、最初にMagick ++を使用して画像を操作し、次にlibharu関数を使用してメモリから画像をロードできるようにしたいと考えています。

HPDF_LoadRawImageFromMem()

ドキュメントによると、これは基本的にいくつかのvoid *バッファから画像をロードします。

私の目標はvoid*、インスタンスからこのデータを取得し、このデータMagick::Imageに基づいてこの画像をharupdfにロードできるようにすることです。

void*またはに書き込んでみましたMagick::Blobが、これまでに達成した唯一の成果は、期待している画像ではなく、黒い長方形でした。

あるライブラリから別のライブラリにRaw画像データを変換した経験はありますか？

私がメモリからこれを行おうとしている理由は、これまでのところ、Magick :: Imageインスタンスをファイルに書き込んでから、このファイルから読み取ってharuにロードするためです。これは、アプリケーションのコンテキストで大きなパフォーマンスヒットです。

4

3 に答える 3

2

答えるのが少し遅れたと思いますが、これが実際の答えです。

LibHaru を使用して itk::Image を PDF に正常に追加したので、ほぼ同じように動作するはずです。まず、使用するライブラリが行優先か列優先かを知る必要があります。LibHaru (および私が知っているすべてのライブラリ) は行優先で動作するため、ライブラリも同様に動作するか、データを「転置」する必要があります。

// Black and white image (8 bits per pixel)
itk::Image<unsigned char, 2>::Pointer image = ...;
const unsigned char *imageData = image->GetBufferPointer();
const HPDF_Image image = HPDF_LoadRawImageFromMem(m_Document,
    imageData, width, height, HPDF_CS_DEVICE_GRAY, 8);

// Or color image (24 bits per pixel, 8 bits per color component)
itk::Image<RGBPixel, 2>::Pointer image = ...;
const RGBPixel *imageData = image->GetBufferPointer();
const HPDF_Image image = HPDF_LoadRawImageFromMem(m_Document,
    reinterpret_cast<const unsigned char *>(imageData),
    width, height, HPDF_CS_DEVICE_RGB, 8);

// Usual LibHaru code. EndText, Position, Draw, StartText, etc.
// This code should not be dependant on the type
InsertImage(image);

唯一の複雑な部分は reinterpret_cast だと思います。白黒画像はすでにバイトとして定義されているため、必要ありません。例えばこんな画像があれば

102 255 255
 99 200   0
255   0 100
imageData == {102, 255, 255, 99, 200, 0, 255, 0, 100};

しかし、このカラー画像があれば

(  0,   0, 255) (0, 255, 255) ( 42, 255, 242)
(200, 200, 255) (0, 199, 199) (190, 190, 190)
imageData == {0, 0, 255, 0, 255, 255, 42, 255, 242, 200, 200, 255, ... }

HPDF_CS_DEVICE_RGB を使用するように指示したため、LibHaru はこれを理解します。つまり、データを (R、G、B) でグループ化します。

もちろん、ImageMagick を使用して、最初のピクセルにアクセスする方法を見つける必要があります。おそらく、data()、begin()、pointer() などのメソッドです。

于 2013-06-19T02:48:29.213 に答える
0

残念ながら、私は ImageMagic も libharu も使用していませんが、画像処理の経験はあります。問題はおそらく生の画像フォーマットが多すぎることであり、両方のライブラリがこれらを同じように理解していないことは確かです。さらに悪いことに、libharu の生の画像の解釈は事実上文書化されていません。しかし、「HPDF_LoadRawImageFromMem」のパラメーターから、libharu が生データを非常に簡単に処理するという結論を導き出すことができます。幅と高さはほとんど一目瞭然で、使用されているもの (おそらくピクセル) に関する唯一の問題があります。さらに興味深いのは、「bits_per_component」です。このパラメーターは、おそらく 1 つのピクセルを定義するために使用されるビット数を表します (一般的な値は 8 です: 256 個の値のパレットからインデックス付けされた、16: 65535 個の値のパレットからインデックス付けされた、24: 赤、緑、青の [RGB] それぞれに 1 バイト、32: 24 と同じですが、シアン、マゼンタにはアルファ チャネルまたは 8 ビットがあります。黄色、および黒 [CMYK]、36: 32 と同じですが、転置を容易にするために値ごとに 9 ビットを使用しています...)。問題は、type: HPDF_ColorSpace のお粗末なドキュメントです。おそらく、with: "bits_per_component" のカラー値がどのように解釈されるかが記述されているためです。ImageMagic では、まったく異なるアプローチが実装されているようです。画像オブジェクトには常に画像形式 (JPEG、PNG、GIF) があるように見えるため、画像オブジェクトはおそらく「単純な」メモリ表現を持たず、エンコードされます。私のお勧めは、ImagaMagic 画像を TIFF 形式に切り替えることです。それは圧縮を容認するため、libharu が想定する生の解釈と同様のアプローチをとっているためです。これが少しでも役に立てば幸いです...乾杯マーク。

于 2012-06-11T16:15:57.150 に答える