About
wind&oil, Weblog

Syndicate:
Subscribe to a syndicated feed of my weblog, brought to you by the wonders of RSS.

Projects:
www.behrmann.name
www.oyranos.org
ColourWiki
CinePaint

Others Bogs:
Color hacks
mulebakken.net
Linux Photography

Contact
Impressum

home :: oyranos

Net-color spec
After the successful Google Summer of Code project of Tomas Carnecky at OpenICC we have now a nice spec for late colour binding on the desktop - read server side monitor corrections. The spec is in the doc directory of Tomas' git repository.

Tomas tould us that the propriarity nvidia linux driver has probably a bug preventing me from successfully running his work on a dual monitor system. Fortunedly he was not right at this and I was able to model after his initial work a second compiz plug-in for dual monitor colour correction of the complete desktop. Its at the moment called colour_desktop.

The snapshot below shows the plug-in with two false colour profiles. The left side monitor has a linear sRGB profile assigned and the right monitor profile has all primaries swapped:

The colour correction workload is for a unused desktop nearly zero and for a running movie slightly noticeable. Of course this server side colour management breaks all older colour managed applciations as there will a double colour correction happen, the early colour binding in the application and the late colour binding in the compiz plug-in. The spec of Tomas holds the solution inside with a atom describing colour region on the server. My colour_desktop compiz plug-in respects these regions and a small example application does both early and late colour binding in one window. The whole stuff is in Oyranos git and it will take a while until we can really distribute stuff like this. First applications should have some time to update to the new window atom under Linux. And second many API's under Oyranos need more refinement.

The following link brings your to a more technical post.

/oyranos | 2 comments | permanent link |

Oyranos 0.1.9 packaging
Release v0.1.9 is out and in a improoved shape. The packages have fewer licensing dependencies. The package is tested by the newly added check target on various hardware platforms and OS'es.
What is now missed are more maintainers for distributions. So far exist a Fedora package. Hub emailed, he would look into OpenSUSE, which is great. From the bigger players is missed a Debian/Ubuntu and a Mandriva maintainer.
Interessted people can contact me <ku dot b at gmx dot de>.

/oyranos | no comments | permanent link |

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.

/oyranos | no comments | permanent link |

Colour management annotation
I wonder why real absolute rendering, not to confuse with the ICC absolute rendering intent, is so often rejected in the thinking of many colour people. It is quite correct to point to viewing conditions. But arent these secondary? The first place are absolute ligthness and colour values, which can later be reinterpreted. If this relation to the physical capturing gets lost, the data is flatten out; much like a one shot flash light foto only covers a two dimensional representation of the three and four dimensional world. Introducing time and changing the point of view makes a real difference. I think the same applies to colour.
Sorry for me being a bit polemic, but I cant understand that information stripping, or better omiting, is the only valid way to create good photos.

Ok there are different paths open and the current one is shurely selected with reasoning by the ICC. Nethertheless people who like to ask questions to colour management systems run often in a difficulty to find inherent answeres. This can be seen as a flaw as it deprives cognition.
A simple example is: "I have calibrated my monitor, but when I measure Lab values from a colour patch on screen, they are not the same as the program says. Even though the measuring device is the same as for creating the profile."

/oyranos | no comments | permanent link |

ICC Examin on Leopard II?
ICC Examin v0.45_rc8, a release candidate, seems to work on 10.5.x series of Apples OS X. Eric Robinson provided to log file. Many thanks.

/oyranos | no comments | permanent link |

ICC Examin on Leopard?

Reportedly does ICC Examin v0.45_rc7, a release candidate, fail on the 10.5.x series of Apples OS X. This is a call to help in debugging this issue. What I need is a log showing the crash details. The Programms/Utilities/Console application can guide in finding such a log. My hope is to get an idea of the reasons and bring ICC Examin to the same state like shown in the above screenshot on osX Tiger.

/oyranos | no comments | permanent link |

Gamut mapping II
To allow to look at the gamut mapping of a CIE*Lab to ISOcoated2 ICC profile in 3D without any CinePaint, here comes a 3D screenshot, available as a gzipped VRML file.

/oyranos | 1 comment | permanent link |

Oyranos Options API II
The general idea is simple. To reach a consitent colour management are parties must play better well together. Agreement to similiar dialogs is one part. To aid the layout Oyranos provides not only settings but as well a concept on how to display them in a interface. A html page comes to mind, but Oyranos is more abstract and not that formal.
The widget requirements are easy:
choice, slider, button (with image), button styles (check, radio), text
groups:
frame, tab or choice or tree ..., layout widget array groups with orientation

Oyranos continues with the concept to require a implementation of a native widget set according to the above mentioned Oyranos abstract widget set and some abstract layout requirements to render the Oyranos settings.

The current widget set covers only choices, profile selections and a groups for pages implemented as tab in oyranos-config-fltk.

These dialogs will be easily rendered in control panels of KDE, Gnome and other places with the above mentioned according implementation.

/oyranos | no comments | permanent link |

Gamut mapping
The below screenshot of ICC Examin working as CinePaint plug-in showes the mapping of a CIE*Lab colour grid to ECI-RGBv2 or LStar-RGB:

The snapshot was created by assigning a Lab profile to Bruce Lindbloom's RGB16Million.tif . For better handling I scaled the Lab16million.tif to a handy size. Then the samples where viewed in CinePaint's ICC Examin plug-in. After that I had let CinePaint convert the Lab values to Rgb and ICC Examin showed the colour movement, appearent here as coloured lines. The small squares show the final Rgb postions. The projection is a 3D view into the CIE*Lab colour space from the CIE*b+ direction. The upper samples point to CIE*L 100 the lower to CIE*L 0.

Interessting is the front plane (+CIE*b) with the mapping of green, yellow and some oranges. They work in a almost lightness (CIE*L) preserving way. The left side (+CIE*a) reds, magentas and blues show a strong lightness modification. The snapshot helps me in improving my gamut creation algorithm in ICC Examin.

/oyranos | no comments | permanent link |

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.

/oyranos | no comments | permanent link |

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?

/oyranos | no comments | permanent link |

OO API changes
with Oyranos being alpha and still no one using its API's, excepts of projects which I maintain myself, I'd think it is appropriate to come with havy weigth changes to the API's. Still it will remain C, but with more of a object style programming. The simple C calls to modify Oyranos internals are changing to calls for manipulating structs. I hope the changes will be more local and thus more patterns can evolve from using Oyranos.
If you still want the old API's for some reason let me know.

/oyranos | no comments | permanent link |

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.

/oyranos | no comments | permanent link |

Oyranos Options API
as is the various properties of options are handled by internal lists. This is fine as long as the complexity is very small. Just many planed features become complex and would need to hold internal data structs in a single list. So my plan is to drop the single property lists to obtain options values and GUI names. The replacement will be build around a single struct and a according extensible API to handle these structs.

The colour management control panel must later be adapted to the new API. But I expect the sources will become more logical. Hope there is nothing else affected and can be set in stone for a stable version 1.0 of Oyranos.

/oyranos | no comments | permanent link |

Named Colour 2

after digging into the named colour API things tend to fall to bottom. A Oyranos Named Colour should be convertible to various colour spaces. So generalised colour conversions are needed.

One way would be to stick to an available CMM like lcms or argyll. The rumors about a CMM API did not turn into a visible reality. Then we could think about how to switch for HDR data to a different CMM.

By the way, a HDR CMM, which will use hard coded colour transformations, will have a hard time due to the complexity. See some thoughts about such approaches here.
Everything except floats can be very comfortable and relyable done by the available CMM's. This is the only decission needed at the moment and should be traceable by the CMM's capabilities registration.
When lcms can handle uint8_t and uint16_t and an other registred CMM IEEE floats, then the later will be used as a fallback for all pure floating point transformations. The prefered way would be a generic CMM like lcms supporting floating point precission.

Then Oyranos must know about profiles and load them. Of course short hands should not be missed. A profile API, loading, on the fly creation, default profile selection, is needed.

The next is a colour conversion context. It will contain a image description. Fortunedly some thoughts where invested in this already a while ago.

Something else?

Oh, yes byteswapping and ICC tag for GUI's interpretation, at least to some extent.

When it is done, ICC Examin has a some more of its capabilities moved to Oyranos with the benefit of being more modular. I hope this helps reducing some the complexity in this application.

The bad news, Oyranos will delay further and probably miss some other wanted features, like the settings virtualisation.

/oyranos | no comments | permanent link |

Named Colour
API in ICC Examin is evolving. To make colours selectable from lists, as often embedded in colourimetric data, I decided to prototype an API for named colour exchange. As such a API stands since a long time on the Oyranos TODO list, it shall later be exposed in the Oyranos colour management library.
There it can be used to select colours and get arbitray conversions from it. For instance it will be highly downward compatible with traditional sRGB workflows. The library shall create sRGB values on the fly from different input, such as Lab or Cmyk.
Things like exposing settings as gamut warnings, HDR information and swatch handling must be added.

Here is a screenshot of the upcoming version 0.45 of ICC Examin:


As soon as a file format for colour swatches is defined, it shall be used for storing named colours on disk.

/oyranos | no comments | permanent link |

ICC Examin osX snapshot

After fiddeling around with all those libraries to bring into the fat mach-o form for ppc and intel machines, I could now build ICC Examin. The package is available as a release candidate for osX.
The osX disk image, containing a universal binary and compressed with gzip (dmg.gz), can be found here:
ICC_Examin-0.43_rc8_U.dmg.gz on SF

Let me know especially whether it works on the mac intel architecture.
To leave a comment, for readers of graphisplanet and similiar, go to the:
comment page on Kai-Uwe's wind blog.

/oyranos | 1 comment | permanent link |

Universal osX
Huhh, compiling all of my toolchain for running ICC Examin on osX PPC/Intel machines. It is not that much fun.
Some libraries are not prepared to handle this case. For the iconv/intl libs I had to remove all obscure -no-undefined statements in Makefile.in. It seems to be in place for BeOS. What do I care, as I dont intent to release those libraries as sources.
Instead -flat-namespace -undefined suppress options helped to get the stuff comiling.
I had to modify ICC Examin to support --disable-dependency-tracking configure option. gcc -M options are not allowed with multiple arch targets in fat files.
As usual, I dont rely what others compile for lcms, tiff and the like. Too often is my HDR stuff brocken. Now these are following as well, but starts more simple. .. OpenEXR compiled fine.

Apple documentation: http://developer.apple.com/technotes/tn2005/tn2137.html

/oyranos | 1 comment | permanent link |

ICC Examin on osX
The builds running on osX are still buggy. Besides various crashes, which might be fixed meanwhile, the most anoying bug is a deadlock for repeatedly calling the pthread_mutex_lock function. This happens automatically by calling FLTK's Fl::lock(). Not shure wether this behaviour is triggered by a memory error in FLTK or in ICC Examin itself.

The later seems to be more likely. Some other things point into this direction. The Xcode memory debugger shows nothing and valgrind is not available on that platform. A tool would be needed to debug the stack.

/oyranos | no comments | permanent link |

Oyranos nearing release date
The package has solved most of the test on the supported platforms. Thanks to Bob Friesenhahn from the GraphicsMagic project for providing access to NetBSD and Sparc Solaris systems. The oyranos-monitor cli tool should now set as well multi monitor profiles. Remains a GUI but this is for a later stage.
What is a bit more burning on the nails is to think about my custom build system. Reportedly it does not solve all dependencies. Even more as Xorg is now widepread modularised.
A other field which needs attention is QA. My imression for Oyranos and thought allready about it for CinePaint is to come with a test suite, much like the SVG test.
I will leave it after 0.1.7. not not further delay a release and do the CinePaint one shortly after.

/oyranos | no comments | permanent link |