Category Archives: imaging

LGM Vienna 2-5 May 2012

Posted on by
Reply

The Libre Graphics Meeting is the annual event for open source creative graphics software. It greatly helps in improving the open source software stack through lots of talks, discussions, round tables, work shops and wonderful face to face meetings. There is always a great mixture of developers, artists, writers, translaters and interested people present, who come together in a very friendly and inclusive atmosphere. We had in the past always a OpenICC round table, when I was at LGM, and discussed various topics and planed around colour management. That should happen this year again with many ideas coming up.

To get people from all over the world to Europe, we need your help:

review!

Sirko has created another pledgie:

X Color Management 0.4 DRAFT1

Posted on by
6

Some days ago on FOSDEM I gave a presentation about Colour Management in Compositors. At that point is was not very clear how to introduce colour management especially into the upcoming Wayland display server core and thus make it wide spread. The answer from Wayland developers is the same as from Xorg ones. They want a small core and colour management does not fit inside this.

As a result of a discussion between several colour management interested people from wayland, toolkits and me on the wayland IRC channel, we found a smallest common denominator. That will be a per window colour correction mechanism. The advantage is, it will be very easy to implement inside compositors and they can even start today about ICC support. The biggest disadvantage for applications is, they need to colour correct the whole window. That is as well the reason, why I did not like the idea in the past. Anyway, hopefully toolkits will jump in at one point and make that easy. Meanwhile we need to focus on example code, which demonstrates how per window colour correction can work.

The spec can be found as usual in the libXcm git repository. The main new part is the _ICC_COLOR_OUTPUTS atom and XcolorOutput structure.

Linux Printing

Posted on by
4

Colour managed printing under Linux relies on several components to play nicely together. Linux has the great lcms Colour Management Module (CMM) to parse ICC profiles and apply colour transformations based on those. The standard print job PDF can have source ICC profiles attached. CUPS knows about per print queue server side configured output ICC profiles. If feet with the correct settings by the according colour managing print filters, Ghostscript does a great job with the provided information at producing colour corrected raster output using lcms. That output is further processed by the printer driver and spooled by CUPS to the physical device.

PDF contains most often colour values defined in DeviceRGB, which is a very short way to specify some colour. And you know programmers are lazy and simply use that. So Ghostscript does a trick to colour manage these documents nonetheless and assumes DeviceRGB to be meant as sRGB, which is in this situation kind of the best it can do.

But DeviceRGB being handled as sRGB blocks practically two important use cases.

  1. Advanced application might want to do colour management early inside the application.Think of proofing and other specialised tasks done by designers and PrePress studios.
  2. Profilers, the applications which create ICC in the first place need targets to be printed without any colour correction. This case is vital to being able to setup colour management at all for new devices, media and drivers by creating valid ICC profiles. It affects owners of colour measurement devices for printers and if they publish their ICC profiles most other users too.

Fortunately there is a way to specify a output device profile per job, which is the way CUPS is designed to be used from client side. Comparably a per session based user device profile introduces a high risk to interfere with standard profile selection mechanisms and concurrenting sessions and is pretty limited in scope. The PDF/X standard allows to embed a output profile inside the document. That way all colour management is completely defined inside the PDF per job and can bypass any unwanted server side magic. The mechanism is called OutputIntent. Applications and print dialogs can use the OutputIntent in order to reliably send device Rgb or Cmyk through a colour management wise non intercepted printing path.

However, manipulation of existing PDF files is not that easy. Thankfully Joseph Simon has put some work into a project called Color-Managed Printing eXtension or short libCmpx. The library handles the harder parts of embedding a ICC output profile into a PDF/X and assists with profile selection. His primary design goal for the libCmpx library is to help enabling colour management in print dialogs. The origin of the project lays in the XCPD Google Summer of Code 2011 project for the OpenICC group.

libCmpx PDF Linux ICC colour management for printing with CUPS

ICC wants streamlined workflows

Posted on by
Reply

The ICC meeting from 30th January to 1th February was again a great chance to meet with colour management people in person. The meeting was hosted in Munich at Adobe with a great view over the snowy city. I joined the sessions under the OpenICC umbrella to represent the open source community.

Of course many talks went over various specification topics and coordination with other standard bodies and groups of interest in colour exchange. But as ICC is evolving, there are new topics coming up as well.

Notably, ICC is slowly moving from a solely static colour content description of what colours are. There is great interest to cover as well the process of applying colour conversions. This covers necessarily definition of terms and workflows and gets to the questions of why, how and who handles colour. This will help users to do high level decisions as opposed to the current need to understand low level technical ICC terms and figuring out how that applies to actual used implementations.

I presented my work inside OpenICC to add monitor identification and calibration state information inside ICC profiles to streamline profile distribution and installation. The concept found support and the presentation about the meta tag keys came along nicely.

ICC members dive currently into spectral imaging, which is prototyped in SampleICC. I appreciate this direction, as it very likely simplifies the use of spectral readings for colour calculations in applications.

The only discussed hint to reduce the size of n-channel profiles, was work on how to put formulas inside the colour processing pipe. It would be great if that comes to a useful result. Formulas inside ICC profiles where first introduced during the v4 specification but only apply to single channels. For per channel operations are currently some few formulas supported. However the new approach allows to express with more elementary operations and allows free access to all channels.

Obviously many members have a strong background in printing, which is greatly reflected in the spec. But some companies have a strong relation to various imaging industries, like camera manufacturers, who as well create printing or displaying devices. There is potential, that ICC will support their interests, provided they actively contribute. For instance ICC profile embedding inside images is well covered inside the ICC spec. That was a good base for e.g. the W3C to introduce colour management for photography on the net. There is no equivalent to movie or video content. In parts embedding of ICC profiles there does not even exist.

Altogether, the ICC meeting was a great chance to coordinate and intensify the work of ICC and OpenICC.

SampleICC-1.6.6 + IccXML-0.9.6

Posted on by

SampleICC provides an open source platform independent C++ library for reading, writing, manipulating, and applying ICC profiles along with applications that make use of this library.

IccXML provides a library and tools to convert between ICC profiles and XML in both directions.

SampleICC release obtained up to the actual revision 1.6.6 various bug fixes, build system improvements and the new iccGetBPCInfo tool.

OpenICC Program FOSDEM 4 + 5 February 2012 in Brussels, Belgium

Posted on by

OpenICC uses 2012 a DevRoom at FOSDEM on Sunday together with Xorg people. The goal is to provide a meeting space for colour management topics.

The program is online on the OpenICC wiki. The talks will present and discuss colour management in Compositors, OpenICC, Scribus, Taxi DB, Oyranos and SVG2.

dispcalGUI supports online ICC Taxi DB

Posted on by

Version 0.8.1.9 of the monitor profiling front end to Argyll CMS was released on 08.12.2011 with a new option to share profiles via the ICC Profile Taxi service hosted by openSUSE. dispcalGUI is thus the first application we know of supporting the online data base (DB). The Linux package is available on openSUSE and will be in the next update to the Oyranos Colour Management Live CD.

Firefox-8.0 Colour Management

Posted on by

As I wrote in my recent post, Firefox has many colour management bugs and one is of special concern toward the Oyranos Colour Management LiveCD III. This bug is now reported upstream and I proposed a patch to fix. It is double color correction with X Color Management, which is in close relation to Hal V. Engels report about Firefox color management does not honor _ICC_PROFILE X11 atoms. It affects all X11 builds and inhibits automatic selection of the system ICC monitor profile. A properly detected system monitor profile in Firefox will show default sRGB colours as well as images with ICC profiles much more in line with other colour managed applications. Getting this bug fixed is a major improvement for presenting colours on the web for Linux.

But why is this bug of so strong concern especially for the Oyranos LiveCD? The CompICC desktop colour server, which is part of the CD, uses sRGB as the assumed document colour space of all non colour managed content on screen. It needs to fool all non X Color Management spec aware applications to think the monitor is exactly in sRGB as long as they do not register with the colour server. In the sense of the X Color Management spec only that content, which is registered through specific per window colour regions is honoured to be colour managed and can use the monitors device ICC profile. This way applications like Inkscape, Krita or eog stay upward compatible and continue to work. However Firefox is not able to fetch the sRGB profile due to the above mentioned bug and falls back to a otherwise clever ICC from EDID generated profile. But Firefox colour corrects under Xorg to the from EDID profile and after that already done compensation assumes CompICC the Firefox window to be in sRGB and colour corrects to the actual setup monitor profile, which might be a from EDID generated profile as well, which leads to double colour correction. The fix of this bug lets Firefox detect the correct system profile. Double colour correction can happen as well if the monitor profile is explicitly set in the client application. So use always the system profile. Setting the system profile is really the job of a CMS like Oyranos.

As I read the code, Firefox honors embedded ICC profiles in JPEGs and PNGs. Great. These bitmaps works even in bitmaps inside SVGs, which is wonderful.

In recent changes Firefox can even handle v4 ICC profiles. These profiles are created by newer ICC profilers and became in recent years pretty widespread. But v4 profiles are not supported by default in Firefox. You need to enable them manually in Firefox´ configuration tab.

The situation for pure vectors graphics in Firefox is not in the same level as with bitmaps. The HTML/CSS color_profile element is completely ignored.

Conclusion, Firefox has after the proposed patch the ability to show with its internal colour management comparable colours of bitmaps like most other colour managed applications.

How to deploy the ICC capabilities of Firefox beyond the WWW´s sRGB as a web artist? You can place JPEG and PNG bitmap images with embedded ICC profiles inside web pages. An other way is to place such images inside SVG. While the freely available SVG editor Inkscape will not show a colour corrected preview of these images, it will not touch the JPEG and PNG images, so Firefox can render them correctly by the SVG standard.

Oyranos Colour Management LiveCD III

Posted on by

The third version of the Oyranos Colour Management LiveCD is based on openSUSE-12.1 and will run on x86_64 compatible PC´s. I placed the ISO image yesterday after some preparations on the better accessible SourceForge site for download. The CD project starts into a instantly colour managed desktop, which is unique under Linux.

The ICC desktop colour correction is done by the CompICC colour server. The LiveCD contains the usual mixture of colour managed graphics applications. Among them is the colour management system Oyranos, the KDE Color Management panel, a profiler based on Argyll CMS and many colour management aware applications for drawing, colour analysis and desktop publishing. Due to package size changes not even all programs from the last release are covered. I am very sorry for that. Nevertheless I decided to include Firefox, as a very wide spread every days application. After fixing a bug in Firefox, the web browser is usable under CompICC and has generally improved regarding colour management. But still it has many colour management related issues.

The desktop widget contains some test images to help you verifying, your desktop is setup correctly and works inside all colour managed applications. Covered are some JPEG, PNG, TIFF and SVG images with wide gamut and swapped channel test profiles. You will surely spot problems, as not everything in Linux desktops is really polished regarding colour management. But these test data can help you in getting a sense of, what can be relied on and what not. You can easily include other applications into your test by installing from openSUSE. And please help the projects and report bugs to the according project bug trackers. This will show interest in the issues seen with colour management and helps developers spot current weaknesses, which are otherwise overseen.

The CD uses the stable version of the Compiz compositing window manager, which is the only one being able to run under KDE. While the Oyranos CMS is packaged in openSUSE, a full screen desktop colour correction is currently not possible with KDE´s KWin or any window manager other than Compiz with the CompICC plugin. One difference to the previous LiveCD is a better useable nouveau driver, which since greatly improved and can now launch into Compiz with GPU acceleration.