Created attachment 15396 [details] PDF file containing a 16-bit PNG image 16-bit/color RGB images included in a PDF file are not rendered correctly in okular (as for kpdf, evince and xpdf), yet display correctly using acroread or gv. Note that the original 16-bit/color (png or tiff) image files ARE correctly displayed by okular (and kpdf), so this appears to be a bug in the poppler library, as signaled by a KDE maintainer. Note also that the PDF file must indeed contain 16-bit images, as many programs (such as pdflatex, imagemagick, ...) simply silently convert to 8-bit depth, whereas others (ConTeXt) do respect the full color depth. Attached is one example; One can easily create others using imagemagick to generated a 16-bit PNG image (but not directly the PDF file) and then ConTeXt to (correctly) produce the PDF file: % texexec test \starttext \externalfigure[test] \stoptext
Created attachment 15397 [details] PNG image, as included in PDF example
Since poppler 0.8.1 we downscale the 16 bits per component to 8 bits per component and then do the drawing. That is not "the real fix" but given no graphics server supports 16 bits per component images it's not that bad. I'm leaving the bug open to signal this could be fixed in a distant future release.
If poppler is going to be used for printing work flows in CUPS filters than this needs to get fixed. Many users going color critical work use 16 bit work flows all the way through to printing and it is not acceptable to have 16 bit images converted to 8 bit images in the filter before sending it to a 16 bit device (GutenPrint uses 16bit depths). I am not sure if the PDF format supports images in other formats such as 32bit/channel or floating point formats. But popper needs to support all of these formats without loss. The format conversion from the objects internal format (8bit/channel, 16bit/channel, 32 bit/channel, floating point...) to the output devices format (8bits/channel for monitors, 16bits/channel for printers...) needs to be handled by the color management engine.
Patches welcome as always ;-)
*** This bug has been marked as a duplicate of bug 34055 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.