Bug 15177 - 16-bit images are downscaled to 8-bit rendering
Summary: 16-bit images are downscaled to 8-bit rendering
Status: RESOLVED DUPLICATE of bug 34055
Alias: None
Product: poppler
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: poppler-bugs
QA Contact:
Depends on:
Reported: 2008-03-23 05:19 UTC by Alan Braslau
Modified: 2011-06-21 12:11 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

PDF file containing a 16-bit PNG image (379.45 KB, application/pdf)
2008-03-23 05:19 UTC, Alan Braslau
PNG image, as included in PDF example (364.05 KB, image/png)
2008-03-23 05:22 UTC, Alan Braslau

Description Alan Braslau 2008-03-23 05:19:48 UTC
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
Comment 1 Alan Braslau 2008-03-23 05:22:47 UTC
Created attachment 15397 [details]
PNG image, as included in PDF example
Comment 2 Albert Astals Cid 2008-05-04 13:04:58 UTC
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.
Comment 3 Hal Engel 2009-07-26 10:28:39 UTC
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. 
Comment 4 Albert Astals Cid 2009-07-26 10:35:47 UTC
Patches welcome as always ;-)
Comment 5 Albert Astals Cid 2011-06-21 12:11:39 UTC

*** 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.