packetmonkey / prawn-gmagick

Use GraphcisMagick to load images into a Prawn document
https://github.com/packetmonkey/prawn-gmagick/
13 stars 6 forks source link

Image does not display correctly (GIF gmagick.depth or BitPerComponent) #19

Open ggenzone opened 3 years ago

ggenzone commented 3 years ago

I found a problem with a GIF image, I know that prawn doesn't support GIF image but ,I am not sure if the problem is prawn-gmagick or prawn.

Source Image: example

Example code:

require "prawn/gmagick"

Prawn::Document.generate('example.pdf') do |pdf|
    pdf.image "example.gif"
end

Output: screenshot-github com-2021 06 03-13_23_41

In this specific case prawn-gmagick read the image and create this object

  def initialize image_blob    
    self.gimage = GMagick::Image.new image_blob
    self.bits = gimage.depth
    self.width = gimage.width
    self.height = gimage.height
  end
  def build_pdf_object(document)

    obj = document.ref!(      
        Type: :XObject,      
        Subtype: :Image,      
        ColorSpace: gimage.colorspace,      # = DeviceRGB
        Height: height,                     # = 243
        Width: width,                       # = 341
        BitsPerComponent: bits              # = 4
    )

    obj << gimage.unpack
...

The problem seems to be related to BitsPerComponent if I put 8 instead of the variable the image looks correct.

https://github.com/packetmonkey/prawn-gmagick/blob/master/lib/prawn/gmagick.rb#L27

Does anyone know if the problem is using image.depth as BitPerComponet or if the problem is internal in prawn?

Thanks!

packetmonkey commented 3 years ago

My initial thought may be a problem with the gif itself. We read the bit depth directly using GMagick::Image#depth which is implemented using MagickGetImageDepth.

If you run identify -verbose <image.gif> what does the reported image depth show?

mojavelinux commented 2 years ago

I'm seeing the same problem with certain PNG images, and I think I might understand what's happening.

For the image cited in the description of this issue, identify reports the depth as follows:

Depth: 8/4-bit

GraphicsMagick reads this value as a 4. And that's what ends up in the PDF:

/BitsPerComponent 4

If I edit the PDF and change this to an 8, the image renders as expected.

Similarly, I have a basic red square image in the Asciidoctor PDF test suite that bumps into the same problem. identify reports the depth of this image as:

Depth: 8/2-bit

GraphicsMagick reads this value as a 2. And that's what ends up in the PDF:

/BitsPerComponent 2

If I edit the PDF and change this to an 8, the image renders as expected.

I think GraphicsMagic is supposed to be using the first value in the Depth field, not the second value.

mojavelinux commented 2 years ago

If I use the following command on the square image:

identify -format "%[depth]\n" square.png

The value reported is 8. That confirms to me that the depth should be read as 8 instead of 2.