從Magick ++圖像中加載內存（libharu）中的圖像

Question

我正在研究基於libharu的 c ++中的一些pdf生成軟件，我希望能夠首先使用Magick ++操作圖像，然后使用libharu函數從內存加載它們：

HPDF_LoadRawImageFromMem()

根據文檔本質上從一些void *緩沖區加載圖像。

我的目標是能夠從Magick::Image實例中獲取此void*數據，並根據此數據將此圖像加載到我的haru pdf中。

我曾嘗試寫過一個void*或一個Magick::Blob但到目前為止我唯一的成就是一些黑色矩形而不是我期待的圖像。

有沒有人有將Raw圖像數據從一個庫轉換為另一個庫的經驗？

我試圖從內存中執行此操作的原因是因為到目前為止，我正在將Magick :: Image實例寫入文件，然后從此文件中讀取以加載到haru，這在我的應用程序的上下文中是一個巨大的性能影響。

Answer 1

我想我回答得有點遲，但這是一個現實生活中的答案。

我使用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, ... }

LibHaru將會理解，因為你告訴他使用HPDF_CS_DEVICE_RGB，這意味着它會將數據分組到（R，G，B）。

當然，使用ImageMagick，您需要找到如何訪問第一個像素。 它可能是一個像data（），begin（），pointer（）等的方法。

Answer 2

不幸的是我既沒有使用ImageMagic也沒有使用libharu，但是我有一些圖像處理的經驗，因為沒有人回答，也許我可以提供一些幫助。 問題可能是存在大量原始圖像格式，我很確定兩個庫對這些格式都沒有相同的理解。 更糟糕的是，libharu的原始圖像解釋幾乎沒有記錄。 然而，libharu處理原始數據非常簡單的結論可以從以下參數中得出：“HPDF_LoadRawImageFromMem”。 寬度和高度幾乎是不言自明的，唯一的問題是使用（可能是像素）。 更有趣的是：“bits_per_component”。 此參數可能描述了用於定義一個像素的位數（常用值為8：從256個值的調色板中索引，16：從65535值的調色板中索引，24：分別用於紅色，綠色和藍色的一個字節[ RGB]，32：24，但是使用alpha通道或8位用於青色，品紅色，黃色和黑色[CMYK]，36：為32但每個值為9位，以便於轉換......）。 問題是類型的糟糕文檔：HPDF_ColorSpace，因為它可能描述了如何解釋with：“bits_per_component”的顏色值。 ImageMagic似乎實現了一種完全不同的方法。 圖像對象似乎總是具有圖像格式（JPEG，PNG，GIF），因此圖像對象可能永遠不會具有“直接”的存儲器表示但是被編碼。 我的建議是將ImagaMagic圖像切換為TIFF格式，因為它寬恕了壓縮，因此與libharu假設的原始解釋有類似的方法。 希望這至少有點幫助...干杯馬克。

Answer 3

回答永遠不會遲到。

我使用PNG blob作為中間步驟：

Image image;
image.read("file.jpg");

Blob blob;
image.write(blob, "PNG");

HPDF_Image pdfImg = HPDF_LoadPngImageFromMem(doc, (const HPDF_BYTE*)blob.data(), blob.length());
HPDF_Page_DrawImage(doc, pdfImg, 0, 0, image.columns(), image.rows());

為簡潔起見，省略了PDF文檔和頁面創建。