Scarse is a project for profiling scanners under GPL based on Argyll code. It started in the old century and became pretty silent, with the last news dating from 2005. The project provides a nice collection of ICC profiles in the Scarse Profile Library, which is now used by some open source graphics packages. ICC profiles referring to standards are used to describe the exact colorimetry of a colour space. The ICC profiles are used to convert to and from other colour spaces in order to exchange with applications, services and customers. It is therefore crucial to meet these standards otherwise results will be incorrect right from the beginning and might render further colour work damaged.
Claudio Wilmanns revealed today a colorimetric imprecision inside the Scarse WideGamutRGB profile. Norman Koren hinted that the Scarse profiles do not pass a profile validation tool. OpenICC could never verify these profiles or how they where build and therefore did not cover any of them in its icc-profiles-openicc data set.
After these comments I like to warn of the usage and distribution of any of the Scarse Profiles for the sake of users trusting profiles of the affected packages in their workflows. We are looking for replacements for some of the most popular ones.
Affected Profiles are AdobeRGB, AppleRGB, WideGamutRGB, CIE-RGB, ECI-RGB, sRGB, KodakProPhotoRGB, ColorMatchRGB and more.
Affected Packages are libkdcraw. Some of the shared-color-profiles/Argyll ‘lcms’ generated profiles from the colord author use in parts the colorimetry of Scarse profiles. The later profiles are not included in the Argyll-1.1.0 source package. These profiles are at risk.
Disclaimer: the author, Kai-Uwe Behrmann, maintains the icc-profiles-openicc package containing ICC profiles describing colour standards.
OpenICC can next year use a DevRoom at FOSDEM on Sunday together with Xorg people. The goal is to provide a meeting space for colour management topics.
Call for Talks:
So far we have one glue talk between Xorg and OpenICC, Scribus and PDF colour management, Taxi DB, OpenICC work and one about Oyranos CMS. We would be glad to see some more talks proposed related to colour management. If you think you could contribute a talk about your favorite project and user topic or get a interesting discussion rolling, then please get in contact with me.
Submission deadline is new year. We will middle January confirm accepted talks.
While OpenICC is usually much biased towards ICC , we feel obliged by the first part of our title and like to get in contact with people using other colour management standards as well and discuss all the overlapping topics. That could be movie or photography. Let´s make it happen. FOSDEM is told to be a good place for that.
The net-color spec from the libXcm repository is renamed. During a great conversation with Martin Gräßlin from KWin at oSC rwx³ he pointed out, that the _NET_ prefix is reserved inside the Xorg atom name space. So I decided to rename all atoms in the applications known to me, which use the net-color spec. The renaming went on fast and all apps work again as expected in git.
The new spec is called X Color Management. It contains the color regions in Xorg description and the used device profile for Linux desktop colour servers.
Affected are libXcm, Xcm, Oyranos, CompICC and CinePaint.
LGM was a quite useful chance to meet people. Jon Cruz from Inkscape I met the first time, which was a nice experience. His remarks on the Cairo API for ICC support at the end of the OpenICC round table where interesting and I hope we can continue with that hot toppic. As well I meet Richard Hughes the author of colord and GCM. We could settle on a specification for file based colour device configuration exchange of CMS/CMF’s and discuss desktop colour servers, which was quite interesting. My talk was about “Connecting Device Calibration to ICC Profiles“.
With many more people I could exchange ideas and make plans. Among them where Oliver Berten, the author of SwatchBooker, Peter Linell and Jean Ghali from Scribus and many more. To my surprise Boudewijn Rempt from Krita pointed out that OpenGTL‘s shiva can handle more than three colour channels. I would love to get support for that in Oyranos.
The whole atmosphere at LGM was great and Louis and the LGM organisation team did great in preparing culinary and cultural program highlights additional to a wonderful conference. As time for coding was somewhat short, some slight improvement could be coding & buffet. This would be a nice experience instead of the well known coding and pizza.
I found the town of Montreal to be a surprisingly friendly place. People from so many cultural background where smiling in the streets, of course always with a arm’s length distance, which is quite unusual in Europe.
LGM will this year happen in Canada. It is one of the great chances to meet so many of the graphics people out there from the major graphics projects. As more and more artists use libre graphics software the focus shifts from almost a mainly developer event in early years to a mix of artists, users, documentation writers, standardisation people and surely more roles. This gives a unique atmosphere to the event.
Typical the projects, which cover a wide range of graphics arts, will present their actual state and announce releases. There will be panels to envision the future of overall developments, to get in closer contact for collaboration projects and to propose or discuss new standards. There is always a reason for surprise.
With enough colour people meeting at LGM, there will be a OpenICC meeting to discuss topics around ICC style colour management in person. This is a good chance to get matters on the table and talk in person. Other colour discussions usually happen at various talks, workshops and so on. I will join this year again.
Dear reader, to make the event happen please consider funding travel and organisation. Many contributors from all over the world can not easily afford the costs for their hobby projects and must rely on your generous spent money to get there. A good chance is the pledgie champaign. The page covers as well links for sponsors:
It is pretty normal that graphics applications use GPU power for their image processing needs. The graphics cards where primarily designed to better support that kind of processing and offload computational power requirements from the main processor the CPU.
GPU computing came not over night. It was first introduced for boosting 2D applications. Simple desktop operations like moving a regions like a window or scaling and help in fast video decoding where first targets. Somewhat later came support for 3D operations. The later is now widely used through OpenGL APIs. The capabilities of the graphic cards increased and OpenGL was extended to support specialised programming on the GPU. The fragment and vertex shaders appeared. Programming of them is in a assembler language. So do not expect much convenience reading, while looking at the assembler code. However, for hard coded graphic operations it plays quite nicely. Compiz, for instance, uses this language for its desktop effects. Long times the assembler code was only available through the proprietary OpenGL drivers from ATI, Nvidia or Intel. Now the open source drivers begin to mature in supporting GPU programming. So it is possible to run Compiz with newer versions of the Nouveau or Radeon drivers. These two types of shaders, vertex and fragment, where joined and later a more convenient expression form for shaders was specified through GLSL. GLSL is OpenGL Shader Language. Newer OpenGL API’s support programming of them in a more straight forward manner. GLSL is officially part of OpenGL since version 2.0.
The C-like GLSL language is much more pleasing at least to most developers eyes. So it is possible to use this language by non specialised programmers to do fast computing on the GPU. If you understand and can write C, imagine you create a graphics filter of your own and process your graphics data through OpenGL directly on the GPU. Its fast and slick and you do not have to wait for a programming hero to convert your favorite algorithm for the GPU to run reasonably fast. But its works only on GPU’s. So either there is a software fallback in case your driver does not support GLSL or you are limited to a subset of hardware and drivers. Thats not so good for sharing and wide spreading your nice ideas.
The Kronos Group, which is the formal body behind OpenGL, specified the new OpenCL standard to improve portability and allow for much more flexible programming. OpenCL has, like GLSL, a C-alike syntax. It is a subset of C with some extensions. OpenCL is now adopted by osX SL and available as vendor driver from Nvidia. If you read adopted by Apple’s osX, you guess right, it is as well available for phones and tablet computers. The AMD Stream SDK contains a OpenCL implementation for CPUs. OpenCL makes the GPU now scriptable with a easy fallback to CPU. Of course thats all very young and up to date exist no open source implementation.
CSS3 drops color-profile property due to a lack of implementation and calls now for more implementations.
These are bad news, as it clearly reduces the scope of ICC profiles. In order to create content with certain colours a ICC profiles is the best way, as soon as the colours exceed the default sRGB colour space. Moreover HTML5 relies on CSS3 colour definitions.
SVG can be used in HTML5 not as syntax, but as embedded document. This means SVG color-profile is not available to all canvas elements. My guess is some web authors need to circumvent sRGB limitations by the means of embedding documents. Is this a continuation of the old flash with unspecified colour space? Clearly not at that level but in regards to colour it might be. We will see. What will be the blending colour space of native canvas elements with SVGs and PNG embeddings?
this text is solely about a idea for a project. The KDE4 site  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.
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.
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.