xpdf viewer renders wrong colors for jpeg encoded images

[Herbert V. Riedel]

Binary package hint: xpdf

see attached files;

colors.tiff:
   original lzw-compressed test image

colors_j.pdf and colors_z.pdf:
   generated by libtiff-tools via "tiff2pdf -n -j colors.tiff -o colors_j.pdf" and "tiff2pdf -n -z colors.tiff -o colors_z.pdf" respectively

displaying colors_z.pdf with either xpdf/gv/evince shows proper colors

displaying colors_j.pdf with evince shows proper colors, whereas xpdf and gv show bad colors (see Screenshot_Xpdf_colors_j_pdf.png)

This happens with either gutsy or hardy on powerpc (don't have any x86 box to compare with, in order to rule out endianness issue)

[Herbert V. Riedel (hvr)]

additional note: libpoppler based apps seem to get it right (as evince and the poppler-utils seem to decode the colors properly) wheras ghostscript and xpdf don't

[TerryG (tgalati4)]

Colors are messed up on x86 hardware as well (under Gutsy). Also, colors_z.pdf show up in the wrong order in both xpdf and evince, so even though the colors are correct, they are not in the same order, so basically, the image is incorrectly rendered in both cases.

Don't know if it is a libtiff-tools problem or a pdf render problem with either evince or xpdf. If you need this tool, then it doesn't work as advertised. Marking as confirmed.

[Herbert V. Riedel (hvr)]

On Fri, 2008-02-22 at 21:33 +0000, TerryG wrote:
> Colors are messed up on x86 hardware as well (under Gutsy).

> Also, colors_z.pdf show up in the wrong order in both xpdf and evince,

what do you mean by different order? here on my gutsy/ppc I see the bars
in colors_z.pdf and colors.tiff with the dark side left, and the white
bar being top...

[TerryG (tgalati4)]

The colors appear swapped, cyan for magenta, yellow for cyan, etc. The left-to-right gradient is correct, but the colors are completely mixed up. I have a powerbook, and I have used the Live CD Dapper on it, but I never installed it since Tiger works pretty well on it.

Your simple use case is repeatable. We need to look at libtiff-tools and see what is going on.

Have you found a work-around?

[Herbert V. Riedel (hvr)]

On Sat, 2008-02-23 at 04:35 +0000, TerryG wrote:
> The colors appear swapped, cyan for magenta, yellow for cyan, etc. The
> left-to-right gradient is correct, but the colors are completely mixed
> up.

> I have a powerbook, and I have used the Live CD Dapper on it, but I
> never installed it since Tiger works pretty well on it.

...so you tested with dapper actually?

...how does tiger's Preview.app display those pdfs for you btw?

> Your simple use case is repeatable. We need to look at libtiff-tools
> and see what is going on.

> Have you found a work-around?

not yet, so far I assumed xpdf/ghostscript to be wrong... since it
worked fine w/ evince ...

cheers,
hvr

[Herbert V. Riedel (hvr)]

well...

I've just tried Leopard's Preview application, for which the tiff and the .pdf files show with the expected proper colors

on the other hand, I've also tried the latest Acrobat Reader 8.1.2, for which colors_z.pdf is fine as well, but colors_j.pdf shows up with bad colors...

so I guess there must be something weird going on with the way tiff2pdf does the jpeg encoding...

I've ran the colors_j.pdf file through "pdfimages -j" (which looks fine as well) and called jpeginfo with it, which couldn't detect any errors:

$ pdfimages -j colors_j.pdf colors
$ jpeginfo -c -i colors-000.jpg
colors-000.jpg 1280 x 102 24bit n/a Normal Huffman 14467 [OK]

alas I couldn't find any tool which allows me to directly embedded a jpeg into tiff without reencoding, as that would definitely help to find a hint about what's going on here...

so I tried a workaround now: I tried using "tiffcp" to reencode the lzw tiff into a jpeg tiff, and embed that one into a pdf without transcoding:

$ tiffcp -c jpeg colors.tiff colors_j.tiff
$ tiffinfo colors_j.tiff
TIFF Directory at offset 0x4dd6 (19926)
  Subfile Type: (0 = 0x0)
  Image Width: 1280 Image Length: 102
  Resolution: 72, 72 pixels/inch
  Bits/Sample: 8
  Compression Scheme: JPEG
  Photometric Interpretation: YCbCr
  YCbCr Subsampling: 2, 2
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 3
  Rows/Strip: 64
  Planar Configuration: single image plane
  DocumentName: /home/hvr/Bugs/libtiff/colors.tiff
  Reference Black/White:
     0: 0 255
     1: 128 255
     2: 128 255
  JPEG Tables: (574 bytes)
$ tiff2pdf colors_j.tiff -o colors_j2.pdf
$ pdfimages -j colors_j2.pdf colors2
$ jpeginfo -i -c colors2-000.jpg
colors2-000.jpg Not a JPEG file: starts with 0xff 0xc0 [ERROR]

actually, colors_j.tiff was already corrupted (Leopard's Preview complained about it being corrupted)

...this starts to look more and more as if the bug should rather be rassigned to the libtiff package... :-/

ps: all commands above were executed on a current hardy install

[TerryG (tgalati4)]

Excellent troubleshooting Herbert. I suspected libtiff but I have had time to run it through and see what was going on.

Package changed to libtiff-tools

[Jay Berkenbilt (ejb)]

Hello. I'm just looking over the tiff bugs in ubuntu. I'm the debian tiff maintainer. Sorry you guys spent so much time on this. I was already familiar with this problem. The problem is that tiff2pdf was setting the /ColorTransform field to 0 in /DecodeParams when it should not have been. This problem was fixed upstream in the 4.0 branch (actually now the trunk). I backported tiff2pdf from 4.0.0 to 3.8.2, and that version of tiff2pdf is included in the current tiff packages in debian.

[Jay Berkenbilt (ejb)]

If you want an easy way to look into a PDF file, I recommend my qpdf software, though in this case, you could look at the image dictionary in the PDF file in a text editor. Solving this one required some familiarity with the PDF spec.

[Jay Berkenbilt (ejb)]

Last comment: hidden here is actually a bug in whichever viewers were not showing incorrect colors since the problem was in the PDF file, not the viewers.