Tag Archives: printing

Linux Printing

Posted on by

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

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.

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.

Colour management results of Google Summer of Code 2011

Posted on by

We are pleased to announce the final results of this years OpenICC participation in the Google Summer of Code program [1]. All students could reach successfully the project goals and obtained the second part of the Google stipends.

OpenICC mentored two students directly and one student through the collaboration with the openSUSE organisation. All three worked on colour management projects, which covered in parts new ground breaking technology and maintain existing one.

Yiannis Belias worked on the “API stabilization for Oyranos Colour Management System II” project [2]. The new classes, code generator improvements and tools will walk into the Oyranos master branch in the next months. This project helps in stablising the CMS core, which covers a great foundation of functionality. After the conversion, it will be much easier to provide stable and extensible APIs.

Joseph Simon realised the XCPD project. It’s goal was to implement the idea of a robust, standards conform printing dialog, which is based on the Common Printing Dialog (CPD) projects code. The handled and manipulated PDF follows the PDF/X specification for embedding user side colour managed content and remote printer configuration [3] [4].

Sebastian Oliva implemented a ICC device profile data base, called taxi. It is intented to share vendor and user created ICC profiles across platforms in a automated fashion. The online data base is designed to cover meta data about the device driver calibration status alongside the characterisation information in the belonging ICC profiles. The DB is online [5] [6]. The project slot was provided by the openSUSE distribution project and mentored by a OpenICC member.

Google Summer of Code is a global program that offers student developers stipends to write code for various open source software projects.

Many thanks to all students for their great work, all people how helped in shaping the basic ideas and discussing the projects in detail and Google for providing the stipends and openSUSE for addtionally inviting their students to the europe openSUSE Conference.

[1] http://code.google.com/soc/
[2] https://github.com/yiannis/Oyranos
[3] https://www.gitorious.org/google-summer-of-code-2011/xcpd
[4] http://jsimon3.wordpress.com/2011/08/23/gsoc%E2%80%9911-update-%E2%80%93-final/
[5] http://icc.opensuse.org
[6] http://openicc.git.sourceforge.net/git/gitweb.cgi?p=openicc/taxi

Google Summer of Code 2011 Student Applications open

Posted on by

This years Google Summer of Code program is open for student proposals. OpenICC in collaboration with openPrinting and openSUSE provide mentored projects around colour management. Own ideas from female and male students all around the world are welcome.

And still we provide guidance for all new or experienced people who like to help with and code for open source colour management projects, even without GSoC.

Oyranos on CLT 2011

Posted on by

The weekend on Chemnitzer Linux Tage happened in a very nice atmosphere at the TU campus.

The Oyranos booth had this year lots of place to show ideas on the hot topics like desktop and print colour management. Unfortunately my long planed co exhibitor could not make it to Chemnitz to show openSUSE-medical. We planed to display medical images on a properly setup 30-bit system as is required by the DICOM specification. Sirko Kemter designed one artistic 2 meter banner and helped with the basic design of the other posters, which we used for the new space. The Oyranos posters included some schematic graphics and the usual “Why do we need colour management” style explanations. For the later one I sketched a comparison of three non colour managed monitors showing the same fashion person. The SVG graphics from the open clip art library was colour converted to three real world monitor profiles. It resembles a typical shop over web situation, where colour counts for selection of the right looking goods.

Several visitors allowed me to start the actual SuseStudio created Oyranos LiveCD on their laptops with different success. We used the exhibited measurement devices and a camera target to create custom ICC profiles for use in digikam, Scribus, Inkscape and friends. The LiveCD is still based on openSUSE-11.3 and worked in many but not all cases. I found it impressive how good looked the featured KDE desktop, when the CompICC plug-in launched immediately. Working OpenGL, which is needed for the desktop colour server shader, was still not always available.

The newest openSUSE-11.4 version was demonstrated on the neighboring openSUSE booth. openSUSE-11.4 was released only some days ago. The OBS color_management repository was updated with the help of Stanislav Brabec just some days before to have nearly all packages build for 11.4. Thus Oyranos workes flawless on 11.4 too.

All in all a great weekend with lots of good talks and meeting of old and new friends.

Gutenprint talks to colour management systems

Posted on by

The Gutenprint project is going to tag its colour related print options with the ColorKeyWords PPD entry. Thus Gutenprint follows a request to tag colour related options in native device API’s. Marking colour related options as being colour related will help to automatically select ICC device profiles depending on the calibration state in the deriver. So in case Gutenprint is set to a increased brightness of 1.1 and the media size is A5, then the colour marked brightness setting will play a role in searching the correct ICC device profile. In contrary a non colour related paper size option will not influence the ICC profile search. This concept of marking driver options as being colour related works as well for SANE and Xorg. The colour related options can be serialised to a common file format, which still has to be defined. Then this calibration information can be embedded by profilers into ICC profiles. Such calibration data enriched ICC profiles can then even be used to setup the calibration state of a given device + driver combination and automatically ensure the correct usage, while minimising user errors. That approach is already deployed in Oyranos’ Xorg module. For display profiles it is typical to embed the calibration data inside the ICC profiles for a long time. The embedded calibration data is used to setup the graphics card to work with the display. Gutenprint is the next candidate to get a similar calibration support inside ICC style colour management.

Drupa 2008

Posted on by

was a impressive tradeshow, with lots of people from the printing industry. Showing machines is one part. One can get a good idea of what is actual in printing effects, costs and handling, at least if some experience already exists. What wondered me was, that at such a show, where much money is put into booths, still occure obvious lapse with very simple things.
So at the Epson booth, which was fairly large, opalescence or broncing in the proofs was rather the standard, even for the Oris RIP. I had expected they sorted such things out and present the optimum of the K3 devices. But possibly the connection of selling machinery and software in one part is more of an objective in a customer relation. So customers see what they get after buying. This helps decreasing support requests, while increasing satisfaction.
Minolta showed a very nice, and large, laser copier/printer. The colours seemed constant, which is a major concern in using this technology for proofs. Just the selected image was squeezed through a assumedly 8 bit rendering path or a terrible profile. One could easily see in the presented gradients. It’s hard to recommend such a expensive device, if one does not know how it can be done better from the software side.

What was really missed was a open source booth. ArgyllCMS/LProf could be shown for calibration and profiling. There is Ghostscript for rendering PDF’s, CUPS for spooling, littleCMS for colour conversions and Gutenprint for driving ink jets. I would offer to demonstrate live my CinePaint proofing tutorial. This would be the right audience.
To center around Linux/BSD seems not that much of a break there, with some companies running Linux since years as servers for their workflows. At least Samba would be a good add to the open source list above.
Well, whether it is possible to sort out broncing and provide a better rendering path with pure open source components, would be a good toppic at the open source booth.

Cmyk versus Rgb printing

Posted on by

Pingus printing on Unix.
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.

Blackpreservation

Posted on by

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:
CinePaint Blackpreservation in Gutenprint plug-in 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.