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).
attachment please
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
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.
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.
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.