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

Plug-ins for Compositing WMs
this text is solely about a idea for a project. The KDE4 site [1] has given their reasoning on why to reject Compiz. Expectedly Gnome will jump in similiar wording. I just want to raise one point about compositing effects/plug-ins. Plug-ins form a great users space to interact with ideas and code.

It is correct stated that Compiz exposes too much details about its internals into plug-ins. So its hard to reuse compiz plug-in code for say kwin.

Anyway the underlying logic is pretty simple.
Shaders are small text files. The desktop has a visible and virtual size, workspaces, monitor outputs, windows, subwindows, edges, a task bar, shortcuts, a property system (Xorg Xatom's) and some more. So from a logical point of view it could be possible to write one plug-in for serveral compositing engines.

What I, as a plug-in author, would find great is a project, which developes a common script language and implements native plug-ins for each of those window managers acting as a script host. Based on a simple and common logic script authors could write text only plug-ins. Obviously shaders are very likely to be part of such a system or possibly OpenCL if mature enough.

I know coming with code or a detailed proposal is nicer. But if someone searches for a nice Summer of Code project, that might become one.

[1] http://techbase.kde.org/Projects/KWin/4.0-release-notes

/docs | no comments | permanent link |

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 |

Libre Graphics Meeting 2009 - Montreal
This years Libre Graphics Meeting will happen to be in Montreal from 6 to 9 may 2009. LGM is a major community organised event to bring open source graphic programmers and users together. On the last years meeting, I could meet many persons en face for the first time and discuss one of OpenICC's Google Summer of Code projects. It was a great bazaar of exchanging ideas in a friendly atmosphere and I expect it to be a very helpful event this year too.

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:

/docs | no comments | permanent link |

Nouveau Compiling on openSUSE
after Hal V. Engel suggested the nouveau driver because of its good XRandR-1.2 support, I installed the driver from the X11:Driver:Video repository. With that alone Oyranos has now a basic XRandR support.
Today I wanted to use the current development version of Nouveau and build on my local openSUSE-11.1 installation. It worked not very well. So here comes some suggestions on which packages are needed to sucessfully build the driver. RPM's which should be present are kernel-source, which is huge, xorg-x11-server-sdk and the various xorg-x11-*-devel packages. With them installed the instructions of the Nouveau developers can be followed: InstallNouveau.
After uninstalling all of the nouveau distribution binaries and drm kernel modules X started successful.

/imaging | no 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 |

ICC DevCon08
was a great opportunity to meet colour people in person. Many thanks to ICC for opening the door to speek at the conference about Linux. It was a fairly small talk compared to what others provided. But it was as well for many the first introduction about the possibility to do colour management on Linux at all. So first of all I gave a introduction about licensing and commercials, as this is most often confused by IT managers.

It was very nice to meet Max Derhak, who implemented the mpet tag and developed on the multiProcessElementsType for better support of floating point processing inside ICC profiles. The tag was developed to better support colour conversions for the motion pictures industry. Great to see that there is communication possible to that extent. We looked over the license issue of SampleICC and figured out how to best solve that. He has interessting things on the plan together with ICC.

Meeting people on the streets of Portland, and I do not think this is specific to this city, had a flair like wild west. Many pedestrians where distant at more than a arm's lenght and keept a cautious tone at a first glance. The border between civilised politeness and the feeling of attention in face of a tiger was very fuzzy. Instinctively I had to think about the citicens right in the US to own gun wappons. On the other hand I saw many signs of openness as I found in Europe, if I may compare, mostly in Amsterdam. So I found a nice place of showing quite some tensions.

/imaging | no comments | permanent link |

HP's DreamColor displays and the 30-bit advancement
cool
10-bit per channel powered by modern graphic chips. Given the last generations of chips with high bit depth frame buffers, dual link dvi and HDMI it seems not so astonishing. Anyway HP can be praised to have brought this to designers and graphics studios at a reasonable price. Congratulation. (Of course I hope this technology becomes pretty standard and will become even more affordable.) Would be interessting to know how Dreamworks deploys this under Linux - Ati : Nvidia?

/imaging | no comments | permanent link |

Drupa 2008
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.

/docs | 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 |

LGM 2008
was for me a really impressive meeting. Really good was the talking on the OpenICC BoF and with other project workers face to face to more easily get a impression about, what are requirements and objections.

We met Carl Worth, and he and Behdad Esfahbod took the time to conceptually let coincide the colour and Cairo internals.

One interessting talk was given about spectral imaging in Krita. Really nice topic shared with the audience by Emanuele Tamponi.
Most talks are covered here.

Kamila Giedroj , Dave Neary, Louis Dejardins and all the other organisers made good preparations. It was a pleasure to attent. Thanks.

/docs | no comments | permanent link |

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,

• be present in a talk about the goals of OpenICC
• give a talk about the Oyranos colour management system
• discuss a, to be prepared, CM strategy for Cairo

/docs | no comments | permanent link |

Cairo in motion
is a small code example for how to do animation in Cairo. Click on the below image to download a 5MB mpeg preview.

The red arc has a mouse over effect and the right below spline with the red line is interactive.

/imaging | no comments | permanent link |

OpenICC and Google Summer of Code 2008
OpenICC is a Freedesktop project that brings together just about everyone who is interested in color for free software applications. That's: ArgyllCMS, CinePaint, Cups, GraphicsMagick, Gimp, Gutenprint, ImageMagick, Inkscape, Krita, karbon, LittleCMS, LPROF, Scribus and Oyranos. And, of course, what's happening here has influence on the the Linux desktops.

This year OpenICC has been selected again as one of the projects that can participate in the Google Summer of Code!

Hot topics for this year are the integration of a colour management system into low level services, like Xorg and Cairo, HDR colour management, hardware accelerated colour conversions, true multiple monitor support, again Tonemapping and a toolkit independent GUI layer for plug-ins and CMM's. Of course we are happy about continuing and improving our existing applications, libraries and all being mentored by experienced developers.

The project ideas range from very simple "get familiar with open source" style projects to advanced topics. Given they are all cross platform, they have potential to influence colour management not only on Linux. With students entering this round we hope to get closer to a colour managed desktop with fun.

/docs | 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 |

Joel Cornuz
asked me some questions to publish on his blog. As I know him from discussions and like his gallery, I agreed and sent him my answeres:

Hello Kai-Uwe

As one of the lead developers of Cinepaint and a very active contributor in Color Management (CM) on Linux, you are a key-person when it comes to using Linux for photography. Thank you very much for taking the time to share your thoughts with us and help us understand better what is going on in the Color Management field on Linux.

Read the whole interview on Joels blog...

/imaging | no comments | permanent link |

CMake hassle
CMake is wrong in claiming it generates unix makefiles. It generates lots of dependend files, which must be read to understand the whole process. Nothing selfcontained. All is spread over many files and various dependencies. Cmake feels much like a PHP hack. If CMake could render it true to generate native build files, I mean selfcontained unix Makefiles and projects files for other build environments, CMake would be a great tool and probably help reducing complexity. Currently it is more close to autotools laboriousness.

Changing the paradigm from automated configure scripts to a full interactive only configuration process moves the new build environment clearly to Windows. In the same way CMake looses a clear Unix feeling.

To make it clear, I dont like to use libtool with its timeconsuming complexity. But what makes Cmake substancially better? As I often try to compile many different projects, my benchmark is, how quickly can I overcome a unexpected problem during the build process?

The following questions arise quickly [with CMake answeres]:
Do I need to learn a new syntax? [yes]
Are all tools and dependencies in one place, making needed adaptions easy and straight forward? [no]
Does I get a project relevant help message by default to change options or set variables? [no]
Can I easily trace wrong parameters to its source, without the need to go through various files and possible learn theire syntax? [no]
Can I use the tool in existing automated envioronments? [not obvious]

If you search for a elegant and simple buildenvironment, chances are high you dont find it with a current version of this tool.

/docs | 1 comment | permanent link |

Sensible colour clipping
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.

/cinepaint | 2 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 |

Pixel naming in Cairo
I find it always confusing to say CAIRO_FORMAT_ARGB32 and mean a 8-bit per channel thing. At a first glace I seriously expect it to be a IEEE float format, which it is not. Most users will expect to multiply by the channels count to get the pixel size not to divide the pixel size by the channel count.

If you consider, most of the imaging world has changed its pixel naming to a per channel base, it would be nice to see Cairo following this too. It is pretty common to say 16-bit image processing, which means per channel. Or 8-bit monitor displaying, which is again per channel. The monitor LUT's are sometimes 10/12 or even 14-bit, again per channel. The pixel numbers dont say anything about the colour resolution.

Why bit per channel instead of bit per pixel?
For instance a 16-bit Gray X-Ray image, properly displayed, can be superior compared to a 32-bit/pixel CMYK representation. In this case the numbers are non relevant to the lightness distinction. The example makes clear, what counts are the shades of gray.

Tricks like dithering dont count. Otherwise all people would still use indexed gif's for photos. But I dont know any camera or scanner doing so.

On the other side a 32 bit chunck with 3*10 bit RGB inside would be harder to describe. Is such thing still in use for hardware and must be supported? At least it is not present in cairo_format_t. Out of scope?

Possibly someone can point me to a document describing the necessity of Cairos per pixel naming as is. Is it something to do with tradition? Nethertheless the non selfexplanatory behaviour today makes it feel much like a pitfal.

To exemplify (a F stands for floating point):

colour    bit/channel    bit/pixel        cairo_format_t sheme
---------------------------------------------------------------
RGB                 8           24        CAIRO_FORMAT_RGB24
RGBA                8           32        CAIRO_FORMAT_ARGB32
Gray                8            8
GrayA               8           16
Alpha               8            8        CAIRO_FORMAT_A8
CMYKA               8           40
RGB                16           48        CAIRO_FORMAT_RGB48
RGBA               16           64        CAIRO_FORMAT_ARGB64
Gray               16           16
GrayA              16           32
CMYKA              16           80
RGB[A]... 16-bit float/channel use the same pixel size as the 16-bit per channel integers.
RGB      IEEE Half 16           48        CAIRO_FORMAT_RGB48F
RGBA     IEEE Half 16           64        CAIRO_FORMAT_ARGB64F
...
IEEE floats and 32-bit integers:
RGB          FLOAT 32           96        CAIRO_FORMAT_RGB96F
RGBA         FLOAT 32          128        CAIRO_FORMAT_ARGB128F
...
IEEE doubles:
RGB         DOUBLE 64          192        CAIRO_FORMAT_RGB192F
RGBA        DOUBLE 64          256        CAIRO_FORMAT_ARGB256F

CAIRO_FORMAT_ARGB32 -> CAIRO_FORMAT_ARGB_8
CAIRO_FORMAT_RGB24  -> CAIRO_FORMAT_RGB_8
CAIRO_FORMAT_A8     -> CAIRO_FORMAT_A_8
CAIRO_FORMAT_A1     -> CAIRO_FORMAT_A_1

#define CAIRO_FORMAT_ARGB32 CAIRO_FORMAT_ARGB_8

CAIRO_FORMAT_ARGB_16
CAIRO_FORMAT_RGB_16
CAIRO_FORMAT_RGB_HALF
CAIRO_FORMAT_RGB_FLOAT

/imaging | 21 comments | permanent link |

0.23 swings
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.

/cinepaint | 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 |

Cmyk versus Rgb printing

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.

/cinepaint | 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 |

Retargeting 0.22-1 changes
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.

/cinepaint | no comments | permanent link |

Grafpup 2.0
and Nathan could not resist to include UFraw allready. Funny. Hope many users enjoy like him: in his news.

/cinepaint | no comments | permanent link |

0.22-1 tasks for Oyranos
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.

Maximum conformity
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?

/cinepaint | 3 comments | permanent link |

Blackpreservation
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.

/cinepaint | no comments | permanent link |

Smoothness
of the brush strokes seems limited. The blue may camouflage. Anyway for a non vector drawing it is ok. Now scaling works correct:

/cinepaint | no comments | permanent link |

Linux Tage Chemnitz 2007

This years the fair in my hometown was a nice experience. 40 people, all beginners, where listening to my, in their eyes somewhat exotic, colour management and CinePaint explanations. They where probably attracted by the title. I must admit, my intention was to have a discussion with specialists, but these people seems not to come regulary to Chemnitz. But with a small change I hope the audience could take a good impression home.
Beforehand I tried to bring the CinePaint release out, but found some no go issues. Now, with the nice feedback from the fair, I started to solve a long outstanding thing - the precission in the drawing core. The inherited code does nice things, but is, well, a not finished kernel. What I want is a polished look of brush strokes. Things which dont belong to a stroke must go away. What I found is − the CinePaint engine lacks precision in drawing positioning. Some code snippets to overcome the resulting effects are found but where never finished. I looked at the continued projects and thought, it would be best to stay within the CinePaint code complexity and not switch to the complexity of an other application. The results can been seen below.
Drawing quality before (left) and after the changes (right):
There should be still more done to better work out of the box. As well these changes made some other things obvious − see the stripes in the blue stroke. As well the brush scaling code is now insufficient. Hmm ... an other delay in the release. Btw. as you might have noticed the tablet issue for Gtk2 is fixed.

/cinepaint | no comments | permanent link |