Bug 158165

Summary:	kpdf (and xpdf) do not display 16-bit/color RGB images correctly
Product:	[Unmaintained] kpdf	Reporter:	Alan Braslau <alan.braslau>
Component:	general	Assignee:	Albert Astals Cid <aacid>
Status:	RESOLVED INTENTIONAL
Severity:	normal
Priority:	NOR
Version:	0.5.8
Target Milestone:	---
Platform:	Debian testing
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	red.pdf red.png red.tex

Description Alan Braslau 2008-02-21 15:31:26 UTC

Version:           0.5.8 (using KDE 3.5.8)
Installed from:    Debian testing/unstable Packages

16-bit/color RGB images included in a pdf file are not rendered correctly in kpdf (and xpdf). As an example, I created a simple 16-bit/color RGB image (using imagemagick) and included this in a ConTeXt document. The image, a nice red filled-circle, shows up as black in kpdf/xpdf yet renders quite correctly in acroread.

Note that producing the pdf document using pdflatex for example silently converts the image to 8-bit/color that gets rendered "correctly" (yet the color depth is lost).

Comment 1 Albert Astals Cid 2008-02-21 20:49:56 UTC

attachment please

Comment 2 Alan Braslau 2008-02-21 23:02:59 UTC

On Thursday 21 February 2008 20:49:57 you wrote:
[bugs.kde.org quoted mail]

Hello,

Attached is a pdf file (as well as the png image and ConTeXt code from which 
it was produced). I thought it was a bug in ConTeXt, but discovered it was a 
problem with kpdf/xpdf. According to Taco Hoekwater (NTG-context mailing 
list):
> xpdf (and its derivatives) does not support 16-bit color.
> No warning, the pdf is just displayed incorrectly.
> It 'works' in pdflatex in xpdf because the file does not contain a
> 16-bit image at all, it is automatically downgraded.
> You document will be loosing functionality, and gaining portability.


Thank you for your attention.


Created an attachment (id=23662)
red.pdf

Created an attachment (id=23663)
red.png

Created an attachment (id=23664)
red.tex

Comment 3 Albert Astals Cid 2008-04-15 22:03:27 UTC

This should work (meaning we just crop down from 16 bits to 8 bits) on Okular (KPDF successor in KDE4) plus poppler 0.8.1 (due to release in a pair of weeks). We are not actively developing kpdf anymore unless for critical bugfixes and given the low impact of this bug (first 16bit RGB image in a PDF i've seen) we are not fixing it in kpdf.

Thanks for reporting.

Comment 4 Alan Braslau 2008-04-15 23:14:01 UTC

On Tuesday 15 April 2008 22:03:28 you wrote:
[bugs.kde.org quoted mail]

Thank you.

I do not really expect this to be fixed in kpdf. The okular developers handed 
the bug over to poppler. But it's too bad that the "solution" to be accepted 
will be to crop down from 16 bits to 8 bits as this is indeed a loss of 
functionality.

16 bit (and greater) RGB images are not uncommon in scientific documents. I 
suppose that displaying 8-bits is good-enough for most users, but why then 
are most computers now equiped with 24 and 32 bit video cards?

Acrobat handles images correctly.

Comment 5 Albert Astals Cid 2008-04-16 19:29:35 UTC

32 bit video cards mean 8 bit per component RGB images (8 for R, 8 for G, 8 for B and 8 for Alpha), so to display a 16 bit per component image you need a 64bit video card, which is totally unavailable as consumer hardware.

So somewhere in the pipeline you'd get the precision loss anyway.