Rendering Intents Typology

While looking over the new czech translations for CinePaint and ICC Examin from Milan Knizek, I stumbled over “fotometricky” inside all intents. Looking at the origins I found to have written photometric and colourimetric into the sources. Thats clearly ambiguous. But why did I come up with photometric at all?
Graeme Gill points out that a ICC style Rendering intent is a couple of dedication or usage of image content and gamut mapping. I am in doubt that this coupling will remain as is. And frankly Graeme has its part in my mindset regarding smart CMMs. Still no solution for my intent naming. Should I call the first ICC rendering intent as officially called “perceptual” and wait until the paradigm changes? Or call it “photographic” or “pleasing”?
It seems best to switch back to the ICC standard until a proper convention can be agreed to.

Probably the confusion comes from german “fotografisch” translated “photographical”, which appears in the sources as well.

Libre Graphics Meeting 2008

The LGM happens to take place 8th to 11th may at the Wroclaw University of Technology. I am quite curious about the city and the people to meet there, most the first time in person. Even though we had sometimes contact some years before.
There are primarily three themes for me,

Of course other topics like tonemapping, a cross toolkit plug-in GUI API will be interessting to elaborate there as well. Talks in preparation for the Summer of Code projects like Colour Management near X are also promising to become interessting. Lets see what else.

For giving you a chance to help in the success of the event, you can donate to cover part of the cost for the attending developers.
LGM 2008 Logo

Click here to lend your support to: Support the Libre Graphics Meeting and make a donation at www.pledgie.com !

A sponsor contact page is here.

Named Colour Format open

with the various discussions around a single colour format seems now some movement on the Create email list. Among various alternatives the creation of a new format was most popular one. There seems simply nothing what counts and is extensible while being useful with standard tools. So Cyrille Berger is about writing a format draft to later adapt colour palettes, spot colours and so on to the new format. The format will allow ICC profile referencing and seems useful for many areas in colour data exchanging.

One candidate, a format from Xrite, developed by GretagMacbeth, called CxF was not been available since times. There exist a whitepaper, which no one in the open source community likes to implement, because of its unclear status.

Of course Oyranos needs a on disk format, and ideally one, which will be open for future new areas.

OpenICC executeables paths

The new Oyranos continues to evolves to a CMM framework. But where to store?

The already mentioned OpenICC directory proposal handles text and binary data, but no active parts. I am now thinking about a good way for making plug-ins and extensions possible. The idea is to define standard API’s which can later be implemented by various CMM’s. As most binaries are highly architecture dependend theire place must reflect this appropriately. Continuing the current sheme we would get the /usr/lib/color/ + /usr/local/lib/color/ + .local/lib/color/ paths. For the later we had to skip the XDG_DATA_HOME variable as it points to HOME/.local/share, which is not good for our need. After defining the base paths we can append a cmm/ to make the use of the content obvious.

Oh, binaries are not covered by the XDG spec. What now?
A OPENICC_PATH variable with the above paths? Who will set this

OpenICC Proposals

Currently we have two proposals on OpenICC in discussion, which will affect colour managed desktop applications. The first is the ICC Profile in X proposal. Jon A. Cruz brought up the discussion again. I took the chance and wrote a draft version for ICC Profiles in X Specification 0.3. We had discussed several ambiguities and I hope 0.3 will be much clearer.

The other text is the OpenICC directory proposal. It covers the location of colour profiles and configuration data. But it needs more work to become clearer.

Implementations for the first exist in XICC, Oyranos and I think a couple of applications can read the profile out. The paths proposal is in its previous form widespread. But the new paths draft is far away from that.