Загрузка изображений из памяти (libharu) от Magick ++ изображений

Question

я работаю на некоторой генерации PDF программного обеспечения в C++ на основе libharu, и я хотел бы, чтобы иметь возможность первые манипулировать изображения с помощью Magick++, а затем загрузить их из памяти с помощью libharu функции:

HPDF_LoadRawImageFromMem() 

Который по существу documentation загрузки изображений из некоторого void * буфера.

Моя цель состоит в том, чтобы получить данные void* данных из примера Magick::Image и загрузить это изображение в мой haru pdf на основе этих данных.

Я пробовал писать до void* или до Magick::Blob, но единственным достижением, которое я имел до сих пор, был черный прямоугольник вместо изображения, которое я ожидаю.

Есть ли у кого-либо опыт преобразования Raw данные изображения из одной библиотеки в другую?

Причина, по которой я пытаюсь сделать это из памяти, заключается в том, что до сих пор я пишу экземпляры Magick :: Image в файл, а затем читаю из этого файла для загрузки в хару, что является огромным хитом производительности в контексте моей заявки.

Answer 1

Я немного поздно, чтобы ответить. Думаю, но вот реальный ответ.

Я успешно добавил itk :: Image to my pdf, используя LibHaru, поэтому он должен работать примерно так же для вас. Во-первых, вам нужно знать, является ли используемая вами библиотека строкой или столбцом. 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 будет inderstand, потому что ты ему использовать HPDF_CS_DEVICE_RGB, что означает, что она будет группировать данные в (R, G, B).

Конечно, используя ImageMagick, вам нужно найти, как получить доступ к первому пикселю. Это, вероятно, такой метод, как data(), begin(), указатель() и т. Д.

Answer 2

К сожалению, я не работал с ImageMagic или libharu, однако у меня есть некоторый опыт обработки изображений, и пока никто не ответил, может быть, я могу помочь. Проблема, вероятно, в том, что существует множество форматов необработанных изображений, и я вполне уверен, что обе библиотеки не имеют одинакового понимания. Что еще хуже, так это то, что интерпретация сырого изображения либрау практически не документирована. Однако выводы о том, что libharu обрабатывает необработанные данные довольно просто, можно сделать из параметров: «HPDF_LoadRawImageFromMem». Ширина и высота в значительной степени понятны, с единственным вопросом использования (вероятно, пикселей). Более интересно: «bits_per_component». Этот параметр, вероятно, описывает, сколько битов используется для определения одного пикселя (общие значения 8: индексируются из палитры из 256 значений, 16: индексируются из палитры 65535 значений, 24: один байт для красного, зеленого и синего с уважением [ RGB], 32: 24, но с альфа-каналом или 8 бит для голубого, пурпурного, желтого и черного [CMYK], 36: 32, но с 9 бит за значение для упрощения транспостирования ...). Проблема заключается в паршивой документации по типу: HPDF_ColorSpace, поскольку она, вероятно, описывает, как интерпретировать значения цвета с помощью: «bits_per_component». Совершенно другой подход, по-видимому, реализован ImageMagic. Кажется, что у объекта изображения всегда есть формат изображения (JPEG, PNG, GIF), поэтому объект изображения, вероятно, никогда не имеет «простого» представления памяти, но кодируется. Моя рекомендация заключалась бы в том, чтобы переключить образ ImagaMagic в формат TIFF, поскольку он допускает сжатие и поэтому имеет аналогичный подход к предполагаемой исходной интерпретации libharu. Надеюсь, это помогло хотя бы немного ... Cheers Mark.

Answer 3

Никогда не поздно ответить.

Я использовал PNG блоб в качестве промежуточного шага:

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 документ и создание страницы опущена для краткости.