Load images from memory (libharu) from images Magick ++

Question

I am working on some software to create pdf files in C ++ based on libharu , and I would like to be able to first manipulate images using Magick ++ , and then load them from memory using the libharu function:

HPDF_LoadRawImageFromMem() 

Which, according to the documentation , essentially loads images from some void * buffer.

My goal is to be able to get void* data from Magick::Image and load this image into my haru pdf based on this data.

I tried writing in void* or Magick::Blob , but the only achievement I have had so far is a black rectangle instead of the image I expect.

Does anyone have experience in converting raw image data from one library to another?

The reason I'm trying to do this from memory is because so far I am writing instances of Magick :: Image to a file and then reading from this file to load into haru, which is a huge performance hit in the context of my expression.

Answer 1

I'm a little late to answer, I think, but here is the real answer.

I have successfully added itk :: Image to my pdf using LibHaru, so it should work about the same for you. First, you need to know if the library you are using is a row or column. LibHaru (and all the libraries that I know) works in strings, so your library should also be, or you will have to "transpose" your data.

 // 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); 

I think the only tricky part is reinterpret_cast. A black and white image is not needed because it is already defined as a byte. For example, if you have this image

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

However, if you have this color image

 ( 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, ... } 

which LibHaru will endure because you tell it to use HPDF_CS_DEVICE_RGB, which means that it will group the data into (R, G, B).

Of course, using ImageMagick, you need to find how to access the first pixel. This is probably a method, e.g. data (), begin (), pointer (), etc.

Answer 2

Unfortunately, I did not work with ImageMagic or libharu, however I have some experience with image processing, and since no one has answered yet, maybe I can help. Probably the problem is that there are many raw image formats, and I am sure that both libraries do not have the same understanding. What's even worse is that the interpretation of the raw librau image is virtually undocumented. However, the conclusion that libharu processes raw data is quite simple, can be drawn from the parameters: "HPDF_LoadRawImageFromMem". Width and height are pretty much understood, with a single use issue (probably pixels). More interesting: "bits_per_component". This parameter probably describes how many bits are used to determine one pixel (common values ​​are 8: indexed from a palette of 256 values, 16: indexed from a palette of 65,535 values, 24: one byte for red, green, and blue, respectfully [RGB], 32: 24, but with an alpha channel or 8 bits for cyan, magenta, yellow and black [CMYK], 36: 32, but with 9 bits per value to simplify transposting ...). The problem is lousy documentation like: HPDF_ColorSpace, since it probably describes how to interpret color values ​​using: "bits_per_component". ImageMagic takes a completely different approach. It seems that an image object always has an image format (JPEG, PNG, GIF), so the image object probably never has a “simple” memory representation, but is encoded. My recommendation would be to switch the ImagaMagic image to the TIFF format, as it is compressible and therefore has a similar approach to the intended original interpretation of libharu. Hope this helps at least a little ... cheers Mark.

Answer 3

It's never too late to answer.

I used PNG blob as an intermediate step:

 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 document and page creation omitted for brevity.