Device Colour Management
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Behrmann, Kai-Uwe
Devices seldom agree about colours by default. RGB (Red/Green/Blue) colour spaces in digital or analog cameras are different from laptop and desktop monitors and those are different from inkjet printers, even if they do not only support a CMYK (Cyan/Magenta/Yellow/Key-Black) colour space. The talk gives an overview of how these diverging colours can be brought together by the configurable Oyranos Colour Management System on a system level. It will further discuss what is required by applications to make use of the provided ICC profile information.
 My name is Kywe Berman. I'm developing open source color management system. And as part of last year's GoGlozama of Code Project, we concentrated much on device color profile configuration in this color management library, or iranus. The device color management is a critical point to get colors right from one device to another device. You, as a designer, have targets like creating a, creating an impression to your audience. So I made some small moments. You want to have this impression in a predictable way, and like to share it with your audience. You want to share it with your users. Sometimes you create a design on screen, and don't can expect that people will have the same impression on their monitors and their screens, especially for internet and also for printing. You maybe want to work media-independent, and design your colors in a way which come out on different media with the same impression. And therefore, you need to create the same appearance on each device. Typical way to do this, or established way to do this, is to use ICC color profiles for communication, which can be attached to images and also to devices. Color profiles are small binary blobs, which contain color information like primaries of a device, or more advanced stuff like color tables and curves, including some text stuff for copyright and so on. So we had some years ago with the great promise to be well-served with sRGB as one fits all model. But if you use sRGB natively, like many operating systems do, and Linux does so, and I think Windows does also, by default, apply unaltered RGB values to monitor output, then you will quickly see that devices greatly differ. I have shown you on the bottom right and with the thinner lines two typical projections of color gamuts of color spaces. The inner one is sRGB ones. The outer one is Adobe RGB one, a commonly used color space by photographers. The other more irregularly shaped curves represent in the outer one a photo printer and the inner one a typical newspaper offset printing machine. So there are great differences. And we expect it to increase. Monitors go more nowadays towards greater gamuts. Wide gamut monitors is a common use term for this. And sRGB, which might have been standard in recent years, is superseded by this. And still we have laptops with much smaller gamuts. Target is for us to have these colors, the color appearance, meet each other and on each device. So the problems we face is that RGB minus one formula is a very pure result. And it is used in many printing systems. OK, good and good has some more advanced features, but it does not reach really precision. It has certain problems with blue colors and also in many other regions. And you get at the first impression a nice appearance and can be satisfied with this as a standalone thing. But if you compare to screen, if you compare to other media, we quite differ a lot. And so it's not this native color handling is not a way to go. Then devices have different properties where are configured by native configuration systems. And these systems have to be put in place and to be passed and understood by a color profile configuration framework. And also there's a variety of renderers like DCGOR or like Gutenprint with own options, which does not only apply to the devices, but also to the driver side of things. So different device IP I already mentioned. There is the Xanny AP. We have cups with currently used PBD system to configure these devices. Gutenprint has its own format used in GIMP and GIMP plug-in. Then there's the Camaroar decoding with DCR. And Xorg is one system and probably not the only one. So one problem with these systems is that we don't tell you much about color. You have many properties in the configuration to consider for these devices like image resolution and like differing algorithm and also kind of media and also the size of media. These are properties which I'm speaking here at the example of printing. And these properties are partitially targeting as color and some options do not. And we have to find a means to separate these properties which are relevant to color and which are not. Then there is one huge problem that these system like Xanny and cups are networked, also Xorg. And it's not easy to circumvent these networking capabilities by native, by own means of a network layer. Cups has many security issues and it would open a can of worms if we would implement this stuff ourselves. The last point here is vendors need to provide profiles or want to provide profiles for their devices. And they don't only have one device with possibly one media. We have a large variety of devices working in different modes and also working with different media. And if we get color profiles shipped for all these combinations and devices and media, then we will have lots of profiles. And depending on the quality of the profiles, this will nearly explode in the data which has to be provided to the desktop user. What we have are the PPD attributes for printing, the good and print settings I mentioned. Xanny options, this is a library and the tests, some options encoded in C structures. We have some more active properties we can use to gather information about camera models and so on. Edite property for monitor configuration, this is a piece of binary blob which is sent from the monitor over the wire to the computer. And we need to abstract this data to have something we can use independent of each special device. Then the ICC had accepted a special information tag which contains key value pairs. And this is very well fit to the task we have to get with. And it opens the door to store information about devices and about drivers into the ICC profile itself. So what is Orenas? The Orenas project is targeting at color management as a color management system on operating system level. So it's almost low level stuff. It provides a C AP to get access to the data and to the configuration and also to manipulate these settings by programs, language bindings we don't have yet. But it should be as internal design is mostly object orientated, there should be no problem to create bindings. It serves as an open ICC specification test that this group, open ICC is a place, email listing primarily and a place to discuss color management topics for Linux and open source systems. What is implemented is profile reading from the opens ICC profile paths. It supports the device dependent ICC profile and X specification and also manipulates profiles, including of course, reading special information about number of channels and names and text strings and so on for displaying, doing selection of profiles in a user interface. So object orientated internal structures of iron as form some almost a basic core part and most functionality is designed to be stored in external modules. So we have an API for loading C libraries which can be exchanged to also have scripting backends which is not done yet. Then there's a policy model which handles ICC related settings and enforces them in color rendering modules where device modules which are designed to support mentioned device libraries and systems and there are some types of image processing nodes which can be formed to direct it as a cyclic graph and which do already some color conversion and together with the policy model and the device modules they can perform and to end color transformations. And as part of this flexibility I have thought it's very important to also support flexible options and not only this, these options have to be presented to users and so one needs some means to display as well as the data in user interface layout including a translation. Icons are also planned and will coming soon. This is the image view of Overnos, a very small example application and it uses LCMS module, asks the monitor for its profile and what you see here is these are the options provided by the policy module. They are common for the color management modules. These are the nodes to color conversions and here on the bottom we have a special option for the LCMS module which implements these above stuff and adds one new option and you can put where in some special stuff which we would otherwise have trouble to identify and to support. The application doesn't know anything about these properties, about these layout and user interface, is all implemented in Overnos in a module. So rendering is done here as an example and FLTK but it's also possible to write a rendering for these options in QT and GTK and so on. So we can just apply. This monitor is too small, this resolution. Well, I don't get it now right. So normally you should see the effect of changing these options here. This stuff is serialized to XML, to Xform dialect. It's not exactly Xforms. Converted to Overnos, C structures and put back to the LCMS module. This is stuff which happens almost automatically. You don't have to care about in your application. Just switch these modules on and constructs the image processing graph and you are done with the stuff. So now we are switching to Janis Belias and he has done some of this stuff for actually writing modules, device detection modules for Overnos and he will talk now about Xeni and Vodicoding. We have to switch the slides now. What? Frank's screen, sorry. OK. Hello from me too. I'm going to speak to you a couple of minutes about my project last year, Google Summer of Code. My job was to make two modules. One for Sain and one for digital row images. OK. That is for all devices that can take input, like from images, scanners, DSLR cameras and any kind of device that LibSain supports or the Libro library can read. And create images. So this is an image that shows the architecture of all things. On the left you can see you can have a lot of cameras, like an icon, scanners with different lenses and different kind of settings. So you can read the row images with multiple ways. You can track them from your USB device or you can read them with LibZ Photo 2 from a Digicam or Fspot. So you can use one of those programs to read images. Now, when all this gets ready to production, you can use the Uranus framework for color management. It's going to be easy for a program to talk to Uranus directly. The Uranus core can talk to one of the back-ins, the row back-in, which talks directly to Libro. That reads the row image and also can take all the information from the XIF tags of the row image. So when you have calibrated every camera with every lens or every kind of settings you want and you have created a color profile for each kind of settings, you can use the Uranus to decide which profile you want to use. It can send it back to your program, Digicam or Fspot, which then can create on the right an image with the embedded profile. And Uranus, on the other hand, can talk to your monitor so you can see exactly what the image is and you can talk to your monitor so you can see exactly what you want with your colors. Sorry. The same happens for Libsane. That's the second modular row for Uranus. You can see on the bottom is the same framework. So the same back-in can talk directly to the same framework and can take all the hardware and software options and can understand these options so it can talk to the Uranus core and you can select with your scanning application which profile fits your current settings, your current settings on the printer and on your scanner and stuff. So this API currently is only written in C and you can only make C calls but we could extend it in the other languages, Python or C++ and stuff. There is a communication protocol for every application who wants to use the back-ins, the Uranus back-ins. It can send text strings like the device name and get the information it wants to get the correct color profiles. That's the current state of the models. The same model is functional right now. The row image model needs still some work. If you want to try and use them, there is a code from last year's Google Summer of Code project. So there is some example code for live scene and for the row image. So if you have calibrated your camera for color management, you can create a profile and you can use that with a live row to create a T-frame image within a better color profile from all your row images. Currently there are some unsolved problems. The worst part is the network part. We don't have a way to get color profiles from remote computers, but it is being worked on. So we need help from you. If you really want to use color profiles and color management, you can contact us if you use scanners, DSLR cameras, or any other equipment. We'd be very happy to help you and hear your ideas and stuff about how this year can become better. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. I want to finish with a small demonstration. How the stuff works for the... I can close it. How the stuff works for the desktop. I will show you... It's correct here. I've installed here some Color Manager module which implements a one-off setting in the KDE desktop. You see here the various settings are actually translated in German to this is the screen. I have here on the laptop. So maybe I need to refresh the stuff. It's actually using Compits to do color conversion in the... This should be the beamer. You can change the color conversions on the GPU. Now you can change the profile of this monitor and you will see the effect instantly. You can do crazy things like this test profile to have an understandable demonstration. But you can of course use other profiles up to such crazy things like making an LHB profile. It's one of your monitor. And SRGB would result in... Would result in a zero transform. Well, I think this could be the closing of this presentation. Thanks for your attention.
 My name is Kywe Berman.  I'm developing open source color management system.  And as part of last year's GoGlozama of Code Project,  we concentrated much on device color profile configuration  in this color management library, or iranus.  The device color management is a critical point  to get colors right from one device to another device.  You, as a designer, have targets like creating  a, creating an impression to your audience.  So I made some small moments.  You want to have this impression in a predictable way,  and like to share it with your audience.  You want to share it with your users.  Sometimes you create a design on screen,  and don't can expect that people will have the same impression  on their monitors and their screens,  especially for internet and also for printing.  You maybe want to work media-independent,  and design your colors in a way which  come out on different media with the same impression.  And therefore, you need to create the same appearance  on each device.  Typical way to do this, or established way to do this,  is to use ICC color profiles for communication, which  can be attached to images and also to devices.  Color profiles are small binary blobs,  which contain color information like primaries of a device,  or more advanced stuff like color tables and curves,  including some text stuff for copyright and so on.  So we had some years ago with the great promise  to be well-served with sRGB as one fits all model.  But if you use sRGB natively, like many operating systems do,  and Linux does so, and I think Windows does also, by default,  apply unaltered RGB values to monitor output,  then you will quickly see that devices greatly differ.  I have shown you on the bottom right  and with the thinner lines two typical projections  of color gamuts of color spaces.  The inner one is sRGB ones.  The outer one is Adobe RGB one, a commonly used color space  by photographers.  The other more irregularly shaped curves  represent in the outer one a photo printer  and the inner one a typical newspaper offset printing machine.  So there are great differences.  And we expect it to increase.  Monitors go more nowadays towards greater gamuts.  Wide gamut monitors is a common use term for this.  And sRGB, which might have been standard in recent years,  is superseded by this.  And still we have laptops with much smaller gamuts.  Target is for us to have these colors, the color appearance,  meet each other and on each device.  So the problems we face is that RGB minus one formula  is a very pure result.  And it is used in many printing systems.  OK, good and good has some more advanced features,  but it does not reach really precision.  It has certain problems with blue colors  and also in many other regions.  And you get at the first impression a nice appearance  and can be satisfied with this as a standalone thing.  But if you compare to screen, if you compare to other media,  we quite differ a lot.  And so it's not this native color handling is not a way to go.  Then devices have different properties  where are configured by native configuration systems.  And these systems have to be put in place and to be passed  and understood by a color profile configuration framework.  And also there's a variety of renderers like DCGOR  or like Gutenprint with own options, which  does not only apply to the devices,  but also to the driver side of things.  So different device IP I already mentioned.  There is the Xanny AP.  We have cups with currently used PBD system  to configure these devices.  Gutenprint has its own format used in GIMP and GIMP plug-in.  Then there's the Camaroar decoding with DCR.  And Xorg is one system and probably not the only one.  So one problem with these systems  is that we don't tell you much about color.  You have many properties in the configuration  to consider for these devices like image resolution  and like differing algorithm and also kind of media  and also the size of media.  These are properties which I'm speaking here  at the example of printing.  And these properties are partitially targeting  as color and some options do not.  And we have to find a means to separate these properties which  are relevant to color and which are not.  Then there is one huge problem that these system like Xanny  and cups are networked, also Xorg.  And it's not easy to circumvent these networking  capabilities by native, by own means of a network layer.  Cups has many security issues and it  would open a can of worms if we would implement this stuff  ourselves.  The last point here is vendors need  to provide profiles or want to provide profiles  for their devices.  And they don't only have one device with possibly one media.  We have a large variety of devices  working in different modes and also working  with different media.  And if we get color profiles shipped  for all these combinations and devices and media,  then we will have lots of profiles.  And depending on the quality of the profiles,  this will nearly explode in the data which  has to be provided to the desktop user.  What we have are the PPD attributes for printing,  the good and print settings I mentioned.  Xanny options, this is a library and the tests,  some options encoded in C structures.  We have some more active properties  we can use to gather information about camera models  and so on.  Edite property for monitor configuration,  this is a piece of binary blob which is sent from the monitor  over the wire to the computer.  And we need to abstract this data  to have something we can use independent of each special device.  Then the ICC had accepted a special information  tag which contains key value pairs.  And this is very well fit to the task we have to get with.  And it opens the door to store information about devices  and about drivers into the ICC profile itself.  So what is Orenas?  The Orenas project is targeting at color management  as a color management system on operating system level.  So it's almost low level stuff.  It provides a C AP to get access to the data  and to the configuration and also to manipulate these settings  by programs, language bindings we don't have yet.  But it should be as internal design is mostly  object orientated, there should be no problem to create bindings.  It serves as an open ICC specification test  that this group, open ICC is a place, email listing primarily  and a place to discuss color management topics  for Linux and open source systems.  What is implemented is profile reading  from the opens ICC profile paths.  It supports the device dependent ICC profile  and X specification and also manipulates profiles,  including of course, reading special information  about number of channels and names and text strings  and so on for displaying, doing selection of profiles  in a user interface.  So object orientated internal structures of iron  as form some almost a basic core part  and most functionality is designed to be stored  in external modules.  So we have an API for loading C libraries  which can be exchanged to also have scripting backends  which is not done yet.  Then there's a policy model which handles ICC related settings  and enforces them in color rendering modules  where device modules which are designed  to support mentioned device libraries and systems  and there are some types of image processing nodes  which can be formed to direct it as a cyclic graph  and which do already some color conversion  and together with the policy model and the device modules  they can perform and to end color transformations.  And as part of this flexibility I have thought  it's very important to also support flexible options  and not only this, these options have to be presented to users  and so one needs some means to display as well as the data  in user interface layout including a translation.  Icons are also planned and will coming soon.  This is the image view of Overnos,  a very small example application and it uses LCMS module,  asks the monitor for its profile and what you see here is  these are the options provided by the policy module.  They are common for the color management modules.  These are the nodes to color conversions  and here on the bottom we have a special option  for the LCMS module which implements these above stuff  and adds one new option and you can put where  in some special stuff which we would otherwise  have trouble to identify and to support.  The application doesn't know anything about these properties,  about these layout and user interface,  is all implemented in Overnos in a module.  So rendering is done here as an example and FLTK  but it's also possible to write a rendering for these options  in QT and GTK and so on.  So we can just apply.  This monitor is too small, this resolution.  Well, I don't get it now right.  So normally you should see the effect of changing  these options here.  This stuff is serialized to XML, to Xform dialect.  It's not exactly Xforms.  Converted to Overnos, C structures  and put back to the LCMS module.  This is stuff which happens almost automatically.  You don't have to care about in your application.  Just switch these modules on and constructs  the image processing graph and you are done with the stuff.  So now we are switching to Janis Belias  and he has done some of this stuff for actually writing  modules, device detection modules for Overnos  and he will talk now about Xeni and Vodicoding.  We have to switch the slides now.  What? Frank's screen, sorry.  OK. Hello from me too.  I'm going to speak to you a couple of minutes about my  project last year, Google Summer of Code.  My job was to make two modules.  One for Sain and one for digital row images.  OK.  That is for all devices that can take input, like from  images, scanners, DSLR cameras and any kind of device  that LibSain supports or the Libro library can read.  And create images.  So this is an image that shows the architecture of all  things.  On the left you can see you can have a lot of cameras,  like an icon, scanners with different lenses and different  kind of settings.  So you can read the row images with multiple ways.  You can track them from your USB device or you can read  them with LibZ Photo 2 from a Digicam or Fspot.  So you can use one of those programs to read images.  Now, when all this gets ready to production, you can  use the Uranus framework for color management.  It's going to be easy for a program to talk to Uranus  directly.  The Uranus core can talk to one of the back-ins, the row  back-in, which talks directly to Libro.  That reads the row image and also can take all the  information from the XIF tags of the row image.  So when you have calibrated every camera with every lens  or every kind of settings you want and you have created a  color profile for each kind of settings, you can use  the Uranus to decide which profile you want to use.  It can send it back to your program, Digicam or Fspot,  which then can create on the right an image with the  embedded profile.  And Uranus, on the other hand, can talk to your  monitor so you can see exactly what the image is  and you can talk to your monitor so you can see  exactly what you want with your colors.  Sorry.  The same happens for Libsane.  That's the second modular row for Uranus.  You can see on the bottom is the same framework.  So the same back-in can talk directly to the same framework  and can take all the hardware and software options  and can understand these options so it can talk  to the Uranus core and you can select with your scanning  application which profile fits your current settings,  your current settings on the printer and on your scanner  and stuff.  So this API currently is only written in C and you  can only make C calls but we could extend it in the  other languages, Python or C++ and stuff.  There is a communication protocol for every application  who wants to use the back-ins, the Uranus back-ins.  It can send text strings like the device name  and get the information it wants to get the correct  color profiles.  That's the current state of the models.  The same model is functional right now.  The row image model needs still some work.  If you want to try and use them, there is a code  from last year's Google Summer of Code project.  So there is some example code for live scene  and for the row image.  So if you have calibrated your camera for color  management, you can create a profile and you can use  that with a live row to create a T-frame image  within a better color profile from all your row images.  Currently there are some unsolved problems.  The worst part is the network part.  We don't have a way to get color profiles from  remote computers, but it is being worked on.  So we need help from you.  If you really want to use color profiles and color management,  you can contact us if you use scanners, DSLR cameras,  or any other equipment.  We'd be very happy to help you and hear your ideas  and stuff about how this year can become better.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  I want to finish with a small demonstration.  How the stuff works for the...  I can close it.  How the stuff works for the desktop.  I will show you...  It's correct here.  I've installed here some Color Manager module  which implements a one-off setting in the KDE desktop.  You see here the various settings are actually translated  in German to this is the screen.  I have here on the laptop.  So maybe I need to refresh the stuff.  It's actually using Compits to do color conversion  in the...  This should be the beamer.  You can change the color conversions on the GPU.  Now you can change the profile of this monitor  and you will see the effect instantly.  You can do crazy things like this test profile  to have an understandable demonstration.  But you can of course use other profiles  up to such crazy things like making an LHB profile.  It's one of your monitor.  And SRGB would result in...  Would result in a zero transform.  Well, I think this could be the closing of this presentation.  Thanks for your attention.
Device_Colour_Management_0_59.png Device_Colour_Management_60_635.png Device_Colour_Management_636_695.png Device_Colour_Management_696_1139.png Device_Colour_Management_1140_1331.png Device_Colour_Management_1332_2579.png Device_Colour_Management_2580_3203.png Device_Colour_Management_3204_4187.png Device_Colour_Management_4188_4307.png Device_Colour_Management_4308_7679.png Device_Colour_Management_7680_15239.png Device_Colour_Management_15240_18467.png Device_Colour_Management_18468_24719.png Device_Colour_Management_24720_25931.png Device_Colour_Management_25932_26087.png Device_Colour_Management_26088_26159.png Device_Colour_Management_26160_26699.png Device_Colour_Management_26700_27707.png Device_Colour_Management_27708_27791.png Device_Colour_Management_27792_28823.png Device_Colour_Management_28824_28871.png Device_Colour_Management_28872_30347.png Device_Colour_Management_30348_31883.png Device_Colour_Management_31884_32003.png Device_Colour_Management_32004_32531.png Device_Colour_Management_32532_33311.png Device_Colour_Management_33312_36575.png Device_Colour_Management_36576_37751.png Device_Colour_Management_37752_38147.png Device_Colour_Management_38148_38675.png Device_Colour_Management_38676_39083.png Device_Colour_Management_39084_39947.png Device_Colour_Management_39948_40463.png Device_Colour_Management_40464_41519.png Device_Colour_Management_41520_41975.png Device_Colour_Management_41976_42599.png Device_Colour_Management_42600_42695.png Device_Colour_Management_42696_42767.png Device_Colour_Management_42768_42911.png Device_Colour_Management_42912_43163.png Device_Colour_Management_43164_43943.png Device_Colour_Management_43944_44579.png Device_Colour_Management_44580_44627.png