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.
On the internet are many places to download ICC profiles, which promise to implement standards. But how reliable are these profiles and why should users and distributors care about their quality?
Why quality counts? For many users is real value in reliable colour space definitions. Most professionals and advanced amateurs know that wrongly implemented colorimetry can cause them unwanted modifications and will sum up over repeated conversions and colour space assignments until the error has rendered the colour material useless. But profile conformance to the standard, which these profiles claim to represent, is not so obvious. A profile checker can only detect conformance to the ICC standard itself, which is about the file format, but not about the quality of the encoded data.
The preferred solution for professionals is to download ICC profiles only from trusted vendors. Unfortunately for the open source community, most ICC profiles for common standards are restrictively licensed and allow no modifications. However these licenses are a reaction to people, who want to push stuff at whim and fake profile names. After all spreading low quality fakes will mostly harm users. Such faked profile made it in many open source packages. It would help the open source community, if vendors license their ICC profiles for standard conditions after the new non restrictive ICC profile license. Then faking profiles, by the reasoning of providing them under a free license, would not be needed any more.
We have some free and accurate profiles available. Over the past years colour experts have created precise profiles with a free license. Among these profiles are implementations of sRGB, AdobeRGB spec and after a license switch for LStar-RGB and many standard printing conditions. These profiles are packaged in the icc-profiles-openicc data set.
How to check ICC profiles for standards?One indirect method is comparing reference ICC profiles with alternative ones. A visual comparison is possible on Linux with the free CinéPaint and the separate ICC Examin plugin in CIE*Lab space. The above video compares visually the ROMM ICC profile, which shares its colorimetry with ProPhoto RGB, with the Scarse ProPhoto.icm. The Scarse colour value interpretation shows quite some deviation from the Adobe version. To repeat the test: open a test image and assign the ISO 22028-2 ROMM RGB profile. Then open the ICC Examin colour viewer from CinéPaint´s main menu > Image > Watch Colours 3D … The plugin should launch and show you the colour space with the image colours represented as big dots. You can change the dot size in ICC Examin with the ‘+’ and ‘-’ keys. Then assign the Scarse Kodak ProPhoto RGB to the image from main menu > Image > Assign ICC Profile … The colour dots change to the new interpretation by the lcms CMM after assigning. A unwanted deviation in the interpretation is marked by a line. That visual method of inspecting line vectors is much easier than comparing colour differences directly. Possible rendering intents for these kind of comparisons are relative colorimetric and absolute colorimetric, as these are well defined by the ICC spec. Disadvantages of the outlined method are the need of reference profiles in the first place and so far no numerical results.
On my git repository with CinePaint patches is the full screen mode changed. It uses the GTK funtionality. That mode is now window manager based and will not work with twm. The old code is still ifdefed for users who rely on that and compile it. Putting a full fledged solution like in gqview inside CinePaint would have been too much work.
New is as well resizing of frames in the flip book, to allow me to load a bunch of cameraRAW images and watch them much like in a slide show. Colour regions are updated for the colour server.
And last but not least a fix in now available, to let CinePaint run on non KWin and non Compiz window managers. I tested on twm.
Carl Cole works on a patch to sensibly apply clipping to out of range pixels. The clipping is implemented for the curves and levels tools. In the screencast below you can see how the new clipping works in levels. CinePaint colour clipping video
And here as screenshot, old wild hue moving towards the three secondary colours:
… and the new levels behaviour preserving hue:
I am pretty shure this behaviour will become quickly standard for open source applications as it is a big quality improvement.
After trashing code for a more generic colour rendering core, my gtk development tree is again up and ready.
As usual some colour improvements are included. This means Oyranos is spread more and more over the code. I slowly export CinePaint’s colour management to Oyranos. So, CinePaint must at some point rely on it to build. Otherwise I have to provide the bits in two places. The Oyranos dependency will turn mandatory probably already in the 0.23 release.
As well, CinePaint should build by default as a Gtk2 app. Some distribution try to fake the old Gtk1 API by some none useable headers to finally link into Gtk2. As this is non sense for a advanced application like CinePaint, consequently many users experienced failing builds. The configure option –enable-gtk1 should turn the old build mode after the switch.
It is often discussed, whether Cmyk or Rgb printing results in better quality, or whether one should buy a Rgb or Cmyk device. I will try to shed some light on this theme.
Normally print devices use Cmyk inks. These are cyan, magenta, yellow and black (k). Some come with additional inks for light cyan, light magenta, (light) gray, red and blue to extend the device gamut and improve smoothness. Or they use special finishes for a better appearance of the print. These devices are far away from being Rgb print devices. The somewhat fuzzy term Rgb printer comes almost from the Windows world, where pictures are sent as Rgb colours to print devices. This is a software or driver aspect. The concept, followed on windows, is to make virtually every colour device a (s)RGB device, and thus simplify software and user interaction. This concept has advantages and disadvantages. See further at wikipedia.
To achieve good results, depending on what quality you like to obtain, the colour conversion should occure with colour profiles according to the desired quality and designed for the combination of your device and the ink/media/software/driver you plan to use. Most colour profiles are stored in the ICC format. But there exist as well internal colour transformations in some drivers or propriarity formats. For instance Gutenprint utilises internal lookup tables and algorithms for converting incoming Rgb to printer side Cmyk colours.
As Cmyk is often almost the native colour space of your printing device, this colour space is often used in professional grade RIP’s to better deploy the gamut of a printer.
An other aspect is the look of your print. This includes saturation enhancements or a special tint of the sky, skin tones and so on. It is the aspect of taste in this art, varying with the region and the group of persons.
For CinePaint, the image separated into Cmyk colours, will transport the high bit depth colour information in a most straight forward manner to the Gutenprint print driver. Thus Gutenprint has just to dither with few further colour conversions, resulting in less banding and finer gradients for sky, foggy motives and the finishes on glass and car surfaces. Of course you have the option to use the Gutenprint internal conversion routines and supply Rgb, thus by-passing the ICC conversion. You can read more about printing in CinePaint in my CinePaint – 16-bit Imaging tutorial.
As I released today the 0.22-1 bugfix version, the changes mentioned earlier on this site must be delayed. Lets see as well, if I can get the Python plug-in working to make it a useful distribution part.
Now that the release of CinePaint is out, some things come clearer or simply more evident for handling colour management with Oyranos.
Gray default profile
One thing is the a missing default profile for gray images. I am now adding this to Oyranos. Without it would be incomplete.
The other thing is the missing policy display. If I remember correctly something like a first warn message should be implemented. But it seems difficult for a user to understand such messages the first time. Let me explain a bit more. Once Oyranos is installed and CinePaint runs all comes smoothly. A PNG is opened and and gets a default profile assigned. As the Home+Office policy is the first active one. It will be sRGB for untagged data. Fine. The user tweaks that and saves. Now a tiff comes its way and opens nicely, editing, saving. No problem. After sending to a agency they phone and say it was degraded from their accepted WhateverRGB to sRGB. Now what? No message appeared. Repeating the same in CinePaint and looking now carefully on the windows top border, one can observe that there is sRGB right from the beginning.
Thats not possible. CinePaint degrades an image and this silently. Where is the professionalism?
You can imagine, this will provoke many colour people.
Indeed Oyranos first hand policy is a keep it simple policy. Convert all to sRGB and make all the same right from the beginning. The intention is to help that many users without colour ambitions to work without the need to understand colour management. Once a image is loaded in a Oyranos compliant application, every other applicatin should handle colours fine. This is a maximum of compatibility.
For colour people it is simple to change this. In Oyranos’ control panel, called by oyranos-config-fltk, one has simply to switch from Home+Office to say Photographer. It is in the first tab. Now your image data are handled much more carefully. No colour space degradiation to sRGB, and a bigger default editing colour space is now active.
The dilema is about making it really good for both unexperienced and high level users. Policies can help to satisfy many different groups. And in the future one can simply create its own policy. But a application author is under pressure to provide success right from the beginning.
The question which arises is, how should a default for a fresh installation be formed? What is acceptable for all as a first start?
This print plug-in in CinePaint’s interfacing with Gutenprint is available since quite a time. The blackpreservation option can be found in the first print dialog in the lower part. It affects only CMYK-CMYK conversation. Below is a colour conversion from a ISOcoated to a desktop inkjet with very different gamut shown. The inkjet’s black has a brownish shade. The screenshot shows the visual output on screen:
It is not perfect, but gives you an idea what is available now. The on the fly creation of the device link happens in the background within littleCMS (or lcms), CinePaints internal used colour management modul.
The CinePaint photographic-, printing tutorial 2.1 was today released to the public.It covers now changes up to CinePaints version 0.21.
Thanks to Constanze Sbosny and Nicolaus Millin for theyre great partership.