Open ggenzone opened 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?
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.
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.
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 code:
Output:
In this specific case prawn-gmagick read the image and create this object
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!