Version: 4.2.3 (using KDE 4.2.3) Compiler: gcc 4.3.1 OS: Linux Installed from: Gentoo Packages Poppler now has basic color management support in the latest development versions and version 0.12 will be the first official release with color management support. This is currently available in development release 0.11.0 which was released May 11. The final 0.12 release is scheduled for July 6, 2009. Patches have been sent to the poppler developers email list with code to expose color management support in the poppler qt4 library and also to add color management support to the qt4 demo viewer application so that it uses monitor ICC profiles if these have been installed as X11 atoms. These patches should appear in git sometime soon and this will provide example code for how to do the same thing in applications like Okular. At some point Okular will need to be updated to more fully support color management. Running current versions of Okular against poppler v 0.11 results in improved color rendering of PDF documents with embedded ICC profiles or object with CIEbased color spaces. But if the calling application (Okular in this case) has not set the correct output profile (IE. the profile for the monitor) poppler defaults to sRGB. This is better than not doing color management at all but it would be best if Okular set the correct output color profile so that colors were rendered correctly. The code to do this is almost trivial so this is NOT going to be difficult to add. Also I wrote the poppler qt4 support and demo qt4 viewer patch so I would be willing to assist if help is needed. By the way you can set the X11 profile atom(s) on your system using kolor-manager which is located in the playground area of KDE SVN.
Actually, Albert, Brad and me are in the poppler ml as well... (so this wish is not a news). That reminds me I have to reply there about the poppler-qt4 API patch you sent. Back to the integration with Okular: we're in feature freeze already, so not sure I can do much for KDE 4.3.
My intent was to get this in the queue and I didn't think that KDE 4.3 would be a likely target for this change since it will be released shortly after poppler v0.12. This means that this should probably be targeted for release with KDE 4.4 or at the soonest 4.3.1 or 4.3.2. Users who are running the current versions of Okular but who upgrade to poppler 0.12 before Okular has full support will see some benefits from the CM support just not everything and my experience is that Okular works fine with the new poppler code base. Hopefully my patches or code derived from them will be part of v 0.11.1. In addition, those of us that have been working on kolor-manager (this was a 2008 Google Summer of Code project from the OpenICC group) related stuff would also like to target KDE 4.4 for inclusion and this raises the possibility of leveraging it and the Oyranos backend for enhanced color management support across a range of KDE apps (krita, digikam, printing ...). OpenICC has two Google Summer of Code projects about to start up related to extending Oyranos to support more devices (printers, scanners and cameras in addition to monitors) and part of that effort is to extend this support into kolor-manager. Oyranos and kolor-manager will give us a ColorSync (IE. the color management stuff on the Mac) like environment for KDE. Although it will likely take a while to mature.
Created attachment 165788 [details] pdf with images containing ICC profile Is there any news on this, 25 years later? I just tried to create a pdf file (the image should print blue if ICC profiles are enabled, and red otherwise) but the ICC profile is not applied.
So I made a deeper analysis: so Okular does support input ICC profile (but you need to properly create the pdf, see https://www.color.org/version4pdf.pdf for a nice example and https://tex.stackexchange.com/a/709430/116348 for creating them from LaTeX), but my understanding is that it is NOT taking into account the monitor output ICC profile, so my guess is that it uses a basic sRGB output profile. So for instance, in my laptop I have by default a monitor profile created by KDE (see KDE configuration > color management): ``` $ xprop -display :0.0 -len 14 -root _ICC_PROFILE _ICC_PROFILE(CARDINAL) = 0, 0, 4, 156, 108, 99, 109, 115, 4, 48, 0, 0, 109, 110 ``` Now, this monitor profile will make colors more saturated… but Okular is apparently not applying the monitor profile, so the color looks like a basic sRGB output profile. I will attach an example pdf showing the issue, together with a screenshot comparing with what other tools like Geequie show.
Created attachment 165791 [details] PDF: see that the input profile is respected if the file is properly inputted (second column). But the monitor profile is not applied (cf screenshot) Generated with: \documentclass{article} \usepackage{graphicx} \usepackage{robust-externalize} \robExtConfigure{ enable fallback to manual mode, new preset={icc image xelatex}{ latex, add to preamble={\usepackage{graphicx}}, use xelatex, }, } \NewDocumentCommand{\includegraphicsICC}{D<>{}O{}m}{% \cacheMe[ icc image xelatex, add to includegraphics options={#2}, dependenciesList={#3}, #1 ]{\includegraphics{__ROBEXT_WAY_BACK__#3}} } \begin{document} Compare: \includegraphics[width=5cm]{should_be_blue.jpg} With: \includegraphicsICC[width=5cm]{should_be_blue.jpg} \includegraphics[width=5cm]{tree.jpg} vs \includegraphicsICC[width=5cm]{tree.jpg} \end{document} % Local Variables: % TeX-command-extra-options: "--shell-escape -halt-on-error" % End:
Created attachment 165792 [details] Screenshot showing that Okular does not apply the monitor profile The green is significantly more saturated on the Geekie output (same as Gwenview…) compared to the two bottom right outputs. My guess is that Okular does not apply the monitor output profile.