Color types in Milena...Color types in Milena Caroline Vigouroux Technical Report no0809, MARS 2008...

17
Color types in Milena Caroline Vigouroux Technical Report n o 0809, MARS 2008 revision 1667 The Olena project provides a generic library for image processing, Milena. We want this library to feature many value types so that the user can always choose the relevant types for his application. For instance, we provide many grey-level types, many color types, etc. This seminar focuses on how we implement color types in Milena. There are different color spaces (RGB, HSI, and so on) and several possible encodings for the same color space (rgb_3x8, rgb_f, etc.). One objective of ours is to make things easy for the user. In particular, we want the user to handle color values without being concerned of internal mechanisms. For instance, in conversion formulas, we do not want to see the details of implementation (division by 255). Les types de couleur dans Milena Le projet Olena fournit une bibliothèque générique pour le traitement d’images, Milena. Nous voulons que cette bibliothèque procure de nombreux types de valeur tels que l’utilisateur puisse toujours choisir le type adapter pour son application. Par exemple, nous fournissons de nombreux encodages en niveau de gris, de nombreux espaces de couleur, etc. Ce séminaire présente la manière dont nous mettons en œuvre les types de couleurs dans Milena. Il existe différents espaces de couleur (RGB, HSI, et bien d’autres) et il existe plusieurs encodages possibles pour les mêmes espaces de couleur (rgb_3x8, rgb_f, etc.). Nous voulons rendre les choses plus faciles pour l’utilisateur. Donc, notre objectif est de rendre possible l’utilisation des espaces de couleur sans se soucier des mécanismes internes. Par exemple, dans les formules de conversion, on ne veut pas faire apparaître les détails d’implémentation (division par 255). Keywords Milena, color types Laboratoire de Recherche et Développement de l’Epita 14-16, rue Voltaire – F-94276 Le Kremlin-Bicêtre cedex – France Tél. +33 1 53 14 59 47 – Fax. +33 1 53 14 59 22 [email protected] 200807-Seminar-Vigouroux

Transcript of Color types in Milena...Color types in Milena Caroline Vigouroux Technical Report no0809, MARS 2008...

  • Color types in Milena

    Caroline Vigouroux

    Technical Report no0809, MARS 2008revision 1667

    The Olena project provides a generic library for image processing, Milena. We want this library to featuremany value types so that the user can always choose the relevant types for his application. For instance,we provide many grey-level types, many color types, etc.

    This seminar focuses on how we implement color types in Milena. There are different color spaces(RGB, HSI, and so on) and several possible encodings for the same color space (rgb_3x8, rgb_f, etc.). Oneobjective of ours is to make things easy for the user. In particular, we want the user to handle color valueswithout being concerned of internal mechanisms. For instance, in conversion formulas, we do not wantto see the details of implementation (division by 255).

    Les types de couleur dans Milena

    Le projet Olena fournit une bibliothèque générique pour le traitement d’images, Milena. Nous voulonsque cette bibliothèque procure de nombreux types de valeur tels que l’utilisateur puisse toujours choisirle type adapter pour son application. Par exemple, nous fournissons de nombreux encodages en niveaude gris, de nombreux espaces de couleur, etc.

    Ce séminaire présente la manière dont nous mettons en œuvre les types de couleurs dans Milena. Ilexiste différents espaces de couleur (RGB, HSI, et bien d’autres) et il existe plusieurs encodages possiblespour les mêmes espaces de couleur (rgb_3x8, rgb_f, etc.). Nous voulons rendre les choses plus faciles pourl’utilisateur. Donc, notre objectif est de rendre possible l’utilisation des espaces de couleur sans se soucierdes mécanismes internes. Par exemple, dans les formules de conversion, on ne veut pas faire apparaîtreles détails d’implémentation (division par 255).

    KeywordsMilena, color types

    Laboratoire de Recherche et Développement de l’Epita14-16, rue Voltaire – F-94276 Le Kremlin-Bicêtre cedex – France

    Tél. +33 1 53 14 59 47 – Fax. +33 1 53 14 59 [email protected] – 200807-Seminar-Vigouroux

    [email protected]://publications.lrde.epita.fr/200807-Seminar-Vigouroux

  • 2

    Copying this document

    Copyright c© 2008 LRDE.Permission is granted to copy, distribute and/or modify this document under the terms of

    the GNU Free Documentation License, Version 1.2 or any later version published by the FreeSoftware Foundation; with the Invariant Sections being just “Copying this document”, no Front-Cover Texts, and no Back-Cover Texts.

    A copy of the license is provided in the file COPYING.DOC.

  • Contents

    1 Introduction 41.1 Colors in the library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

    2 Colors representation 52.1 RGB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 CMY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 HSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 HSV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5 XYZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.6 YUV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.7 YIQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.8 How these color spaces are implemented in the library . . . . . . . . . . . . . . . 8

    3 Conversion between color spaces 93.1 conversion formulas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

    CMY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9HSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9XYZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9YUV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10YIQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

    3.2 Conversion system design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Problem: a lot of constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Code design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

    4 other services 144.1 component getters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.2 literals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

    5 Conclusion 16

    6 Bibliography 17

  • Chapter 1

    Introduction

    1.1 Colors in the library

    Having many color spaces available is very important for image processing. Indeed, someimage processing algorithms need a color model close to display device operating. Some otherprocessing algorithms need a color model close to human perception.

    We want to make available a color system which is easy to use and easy to update. So somesoftware engineering appears.

    1.2 Problem

    Our main problem is how to make things easy for user. We will follow two axis for develop-ment:

    • The library make work instead of the user.

    • We do not want to show the details of implementation.

    The goal of this report is to present color management in Milena. It introduces color modelsand code disgn problems.

    First, we will present color models and their compared advantage. Then, we will see conver-sion formulas and conversion system. Finally, we will see related services that allow to easilyuse colors in Milena.

    1.3 Acknowledgment

    Thanks to Ugo Jardonnet for his help.

  • Chapter 2

    Colors representation

    We use color models to represent color.

    A color model describes colors with tuples of numbers. We typically use a tree axis space.Each axis represent a component of the color. This splitting up is particular for each colormodel. The resulting set of colors is called a color space.It is how each components are interpreted that makes the interest of a color space.We will present each color space and explain why it is useful for image processing.

    2.1 RGB

    The RGB color space is an additive color model.Indeed, RGB is represented by three axis: red, green and blue light.Those three components are added together to create the resulting color.This representation is similar to dispay system representation of color, but it do not fit humaninterpretation.This is the most popular color space.

  • 2.2 CMY 6

    2.2 CMY

    The CMY color space is an subtractive color model.This model substract brightness from white. Indeed, CMY is represented by three axis: cyan,magenta and yellow light. These three components are added together to create the resultingcolor. This representation is similar to printing system representation of color, but it do not fithuman interpretation.

    2.3 HSI

    The HSI color space is very different from the two first models because it aims at emulatinghuman perception of color.HSI owes its name to composents that are used to express this model: Hue, Saturation andIntensity.

    The Hue component describes the color itself in the form of an angle. The Saturation compo-nent signals how much the color is polluted with white color. The Intensity component signalshow much the color is polluted with black color. This representation is very important for imageprocessing because it is similar to how human eye senses colors.

  • 7 Colors representation

    2.4 HSV

    The HSV color space is a model in which color is represented according to three axis: Hue,Saturation and Value. HSV model describes colors as points in a cylinder. This representationis similar to human vision.

    2.5 XYZ

    The CIE XYZ color space was designed so that the Y parameter was a measure of the brightnessor luminance of a color. The chromaticity of a color was then specified by the two derivedparameters x and y.

    2.6 YUV

    The YUV color space is used by color television systems. Y is used for luminance and U and Vare used to represent chrominance part of the color.

  • 2.7 YIQ 8

    2.7 YIQ

    In the YIQ color space Y component represents the intensity, the I and Q component representthe color informations.

    The YIQ model also takes advantage of the fact that the human eye is more sensitive to changein luminance than changes in hue or saturation.

    2.8 How these color spaces are implemented in the library

    Each color space is represented by a structure which inherit from value type.

    template struct HSI

    :public internal::value_like_< algebra::vec< 3, float01_8 >,

    algebra::vec< 3, float01_8 >,algebra::vec< 3, float01_8 >,HSI >

    {};

    Each color space is represented by a class template by the type of each components. Eachclass define each components separately. Each component can have a different type specifiedby the user. These classes define all setters and getters on each components.

    template class hsi_ : public HSI< hsi_ >

  • Chapter 3

    Conversion between color spaces

    We want that the user be able to swap from a color space to another.

    3.1 conversion formulas

    We use RGB color space as an intermediate color space to swap between each color space.

    CMY

    CMY color space is similar to RGB color space so conversion formula is not so much compli-cated. C = 1−RM = 1−G

    Y = 1−B

    HSI

    HSI color space is a polar space compared to RGB color space.H = arctan(βα )S =

    √α2 + β2

    I = (R+G+B)/3

    with{α = R− 12 (G+B)β =

    √3

    2 (G−B)

    XYZ XYZ

    = A. RGB

    + Xof f setYof f setZof f set

  • 3.2 Conversion system design 10

    YUV Y = 0.299×R+ 0.587×G+ 0.114×BU = −0.147×R− 0.289×G+ 0.436×BV = 0.615×R− 0.515×G− 0.100×B

    YIQ XIQ

    = 0.299 0.587 0.1140.595716 −0.274453 −0.321263

    0.211456 −0.522591 0.311135

    . RGB

    3.2 Conversion system design

    Problem: a lot of constraints

    There is a lot of different color spaces. There is no inheritance between color spaces becausethey do not have the same nature. Indeed, for example, red component in RGB color spacebears no relation to intensity component in HSI color space.

    We do not want the user to have to use a lot of different functions. We want that functions re-turn numerous types with no inheritance between them. We also want that they take numeroustypes as argument. Moreover, we want that it will be easy in future to add new color spaces.

    Code design

    First, we have to create the future return structure templated by its type. Indeed, its would bedefined later.

    namespace later{

    template struct red;

    }

    Then, we define the function itself.

    template struct f_rgb_to_ : public Function_v2v< f_rgb_to_ >{

    typedef typename later::red::result result;

    template result operator()(const T_rgb& rgb) const{

    return later::red::on(rgb);}

    };

    Finally, we define the function behavior for each color space.

  • 11 Conversion between color spaces

    namespace later{

    template struct red< mln::value::cmy_ >{

    typedef mln::value::cmy_ result;static result on(const mln::value::rgb& rgb){

    result cmy;

    cmy.cyan() = 1 - rgb.red();cmy.magenta() = 1 - rgb.green();cmy.yellow() = 1 - rgb.blue();

    return cmy;}

    };

    template struct red< mln::value::hsi_ >{

    typedef mln::value::hsi_ result;static result on(const mln::value::rgb& rgb){

    static const double sqrt3_3 = std::sqrt(3) / 3;static const double inv_sqrt6 = 1 / std::sqrt(6);static const double inv_sqrt2 = 1 / std::sqrt(2);

    result hsi;

    double alpha = inv_sqrt2 * rgb.green()- inv_sqrt2 * rgb.blue();

    double beta = 2 * inv_sqrt6 * rgb.red()- inv_sqrt6 * rgb.green()- inv_sqrt6 * rgb.blue();

    float tmp = atan2(beta, alpha) / 3.1415 * 180.0;

    hsi.hue() = atan2(beta, alpha) / 3.1415 * 180.0;if (hsi.hue() < 0)

    hsi.hue() = hsi.hue() + 360.0;mln_invariant(hsi.hue() >= 0);hsi.sat() = std::sqrt(alpha * alpha + beta * beta);hsi.inty() = sqrt3_3 * rgb.red() + sqrt3_3 * rgb.green()

    + sqrt3_3 * rgb.blue();

    return hsi;

  • 3.2 Conversion system design 12

    }};

    template struct red< mln::value::xyz_ >{

    typedef mln::value::xyz_ result;static result on(const mln::value::rgb& rgb){

    result xyz;

    xyz.x() = 0.490 * rgb.red() + 0.310 * rgb.green()+ 0.200 * rgb.blue();

    xyz.y() = 0.177 * rgb.red() + 0.812 * rgb.green()+ 0.011 * rgb.blue();

    xyz.z() = 0.010 * rgb.green() + 0.990 * rgb.blue();

    return xyz;}

    };

    template struct red< mln::value::yiq_ >{

    typedef mln::value::yiq_ result;static result on(const mln::value::rgb& rgb){

    result yiq;

    yiq.y() = 0.1768 * rgb.red() + 0.8130 * rgb.green()+ 0.0101 * rgb.blue();

    yiq.i() = 0.5346 * rgb.red() - 0.2461 * rgb.green()- 0.1791 * rgb.blue();

    yiq.q() = 0.2474 * rgb.red() - 0.6783 * rgb.green()+ 0.4053 * rgb.blue();

    return yiq;}

    };

    template struct red< mln::value::yuv_ >{

    typedef mln::value::yuv_ result;static result on(const mln::value::rgb& rgb){

    result yuv;

    yuv.y() = 0.299 * rgb.red() + 0.587 * rgb.green()

  • 13 Conversion between color spaces

    + 0.114 * rgb.blue();yuv.u() = 0.436 * (rgb.blue() - yuv.y()) / (1 - 0.114);yuv.v() = 0.615 * (rgb.red() - yuv.y()) / (1 - 0.299);

    return yuv;}

    };

    }

  • Chapter 4

    other services

    4.1 component getters

    With the conversion system, we can provide other services which are not specific to a particularcolor space. For example, we can define a function that allow the user to get the red componentfrom a color that is implemented in one of the color spaces.

    template struct f_red_ : public Function_v2v< f_red_ >{

    typedef typename later::red::result result;

    template result operator()(const U& color) const{

    value::rgb rgb;

    rgb = f_to_red_< value::rgb >(color);

    return later::red::on(rgb);}

    };

    So we can provide services that allow easily to access to a particular component. This is usefulbecause it allows the user to benefit from numerous color models at the same time. Indeed, wecan imagine that an algorithm need to access on the same image to the red component whichcan be easily got in RGB representation and the intensity which can be easily got in HSI colorspace.

    4.2 literals

    We want also that the user can specify literally the color he wants. So we defined the followingliterals:

    • black

  • 15 other services

    • blue

    • brown

    • cyan

    • darkgray

    • gray

    • green

    • lightgray

    • lime

    • magenta

    • olive

    • orange

    • pink

    • purple

    • red

    • teal

    • violet

    • white

    • yellow

  • Chapter 5

    Conclusion

    Making services available and allowing the user to abstract the internal mechanisms involvessome design problems.

    In the first part of this report, we described color spaces and how they work. We couldsee that there was no relationship between them. So, converting from one type to anotheras no similarity. Then, the report get on how we organize color system: color structures andassociated services and how we find a way to hide implementation details.

    Our aim was to make a system in which color management and adding new color spaces ornew services is easy.

  • Chapter 6

    Bibliography

    Colantoni, P. (2008). Colors (http://www.couleur.org/).

    http://www.couleur.org/

    1 Introduction1.1 Colors in the library1.2 Problem1.3 Acknowledgment

    2 Colors representation2.1 RGB2.2 CMY2.3 HSI2.4 HSV2.5 XYZ2.6 YUV2.7 YIQ2.8 How these color spaces are implemented in the library

    3 Conversion between color spaces3.1 conversion formulas CMY HSI XYZ YUV YIQ

    3.2 Conversion system design Problem: a lot of constraints Code design

    4 other services4.1 component getters4.2 literals

    5 Conclusion6 Bibliography