Re: [Gegl-developer] researching colorspaces, colormodels, colorspace ops

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Calvin Williamson wrote:

Yes. We want to start thinking about color management and gegl some. I have so far been more or less following the spirit of the java2d classes for color spaces, color models, and so on. They have some ICC profile based color space classes and use sRGB or CIE_XYZ as a profile connection space. I thought that java2d was using some parts of a Kodak CMS in its implementation, but I am not completely sure of
 this.

There is also the argyll color management lib based from Graeme Gill to have a look at as well.

I am curious what bitdepths these libraries handle for different conversions.

I am not an expert either, and have learned this stuff from several
forays into the subject.

Argyll, I think, is rather limited.  As far as I can tell, it's color
conversion code is limited to double pixels, and the function call for
the conversion happens one pixel at a time.  Here is a list of the color
spaces supported (taken right from color.h):

/* The different type of spaces */
typedef enum {
        None = 0,       /* Not configured */
        /* Device independent, linear */
        XYZ,    /* CIEXYZ */
        Yxy,    /* CIEYXY */
        Yuv,    /* CIEUCS 1976 */
        /* Device independent, non-linear, relative to white point */
        Luv,    /* CIELUV */
        Lab,    /* CIELAB */
        LCh,    /* CIELCHab */
        Sub,    /* Modified Luv */
        ATD,    /* Guth ATD95 large step space */
        /* Device dependent */
        RGB1,   /* Ideal monitor type of RGB */
        CMYK1   /* Simple CMYK model */
} cspace;

Plus, Argyll wants to know about file formats, is lacking in
documentation, and does a lot of other things besides colorspace
conversion.  And, in the code above, misuses the word "linear."
It also contains some non-gpl'ed code (it's a BSD license)

lcms is written for speed as a support library to a color mangement system or image processing libary (e.g. it's intended as a programmatic backend, not a solultion for color managemnt). It is exteremly easy to use and fits well into
how you expected to do things.  It can process scanlines or tiles or
whole pixels at a time.  It has mechinisms in place to detect out of
gamut colors.  It supports many differnt kinds of rendering intents.  It
supports 121 different colorspace/channel space combinations.  Including
8 and 16 bit (both endiannesses) as well as all channels with and
without alpha and various reorderings of the colors.  Here is an
exaustive list:

TYPE_RGB_8, TYPE_GRAY_8, TYPE_GRAY_8_REV, TYPE_GRAY_16,
TYPE_GRAY_16_REV, TYPE_GRAY_16_SE, TYPE_GRAYA_8, TYPE_GRAYA_16,
TYPE_GRAYA_16_SE, TYPE_GRAYA_8_PLANAR, TYPE_GRAYA_16_PLANAR, TYPE_RGB_8,
TYPE_RGB_8_PLANAR, TYPE_BGR_8, TYPE_BGR_8_PLANAR, TYPE_RGB_16,,
TYPE_RGB_16_PLANAR, TYPE_RGB_16_SE, TYPE_BGR_16, TYPE_BGR_16_PLANAR,
TYPE_BGR_16_SE, TYPE_RGBA_8, TYPE_RGBA_8_PLANAR, TYPE_RGBA_16,
TYPE_RGBA_16_PLANAR, TYPE_RGBA_16_SE, TYPE_ARGB_8, TYPE_ARGB_16,
TYPE_ABGR_8, TYPE_ABGR_16, TYPE_ABGR_16_PLANAR, TYPE_ABGR_16_SE,
TYPE_BGRA_8, TYPE_BGRA_16, TYPE_BGRA_16_SE, TYPE_CMY_8,
TYPE_CMY_8_PLANAR, TYPE_CMY_16, TYPE_CMY_16_PLANAR, TYPE_CMY_16_SE,
TYPE_CMYK_8, TYPE_CMYK_8_REV, TYPE_YUVK_8, TYPE_CMYK_8_PLANAR,
TYPE_CMYK_16, TYPE_CMYK_16_REV, TYPE_YUVK_16, TYPE_CMYK_16_PLANAR,
TYPE_CMYK_16_SE, TYPE_KYMC_8, TYPE_KYMC_16, TYPE_KYMC_16_SE,
TYPE_KCMY_8, TYPE_KCMY_8_REV, TYPE_KCMY_16, TYPE_KCMY_16_REV,
TYPE_CMYKcm_8, TYPE_CMYKcm_8_PLANAR, TYPE_CMYKcm_16,
TYPE_CMYKcm_16_PLANAR, TYPE_CMYKcm_16_SE, TYPE_CMYK7_8, TYPE_CMYK7_16,
TYPE_CMYK7_16_SE, TYPE_KYMC7_8, TYPE_KYMC7_16, TYPE_KYMC7_16_SE,
TYPE_CMYK8_8, TYPE_CMYK8_16, TYPE_CMYK8_16_SE, TYPE_KYMC8_8,
TYPE_KYMC8_16, TYPE_KYMC8_16_SE, TYPE_CMYK9_8, TYPE_CMYK9_16,
TYPE_CMYK9_16_SE, TYPE_KYMC9_8, TYPE_KYMC9_16, TYPE_KYMC9_16_SE,
TYPE_CMYK10_8, TYPE_CMYK10_16, TYPE_CMYK10_16_SE, TYPE_KYMC10_8,
TYPE_KYMC10_16, TYPE_KYMC10_16_SE, TYPE_CMYK11_8, TYPE_CMYK11_16,
TYPE_CMYK11_16_SE, TYPE_KYMC11_8, TYPE_KYMC11_16, TYPE_KYMC11_16_SE,
TYPE_CMYK12_8, TYPE_CMYK12_16, TYPE_CMYK12_16_SE, TYPE_KYMC12_8,
TYPE_KYMC12_16, TYPE_KYMC12_16_SE, TYPE_XYZ_16, TYPE_Lab_8, TYPE_Lab_16,
TYPE_Yxy_16, TYPE_YCbCr_8, TYPE_YCbCr_8_PLANAR, TYPE_YCbCr_16,
TYPE_YCbCr_16_PLANAR, TYPE_YCbCr_16_SE, TYPE_YUV_8, TYPE_YUV_8_PLANAR,
TYPE_YUV_16, TYPE_YUV_16_PLANAR, TYPE_YUV_16_SE, TYPE_HLS_8,
TYPE_HLS_8_PLANAR, TYPE_HLS_16, TYPE_HLS_16_PLANAR, TYPE_HLS_16_SE,
TYPE_HSV_8, TYPE_HSV_8_PLANAR, TYPE_HSV_16, TYPE_HSV_16_PLANAR,
TYPE_HSV_16_SE

It doesn't however, support floats, which I see as it's major
limitation.  However, float support can definatly be added, as the
auther did a good job of keeping channel space and colorspace seperate
in his code.  (I have also emailed the auther and asked him if he is
considering adding float support to his library).  He has hand tuned asm
for x86, is past version one, has some support for writing new ICC profiles, and has some tools to help calibrate one's monitor (and other devices). The code also compiles for WIN32 and unix and is being used in at least one commericial color management system (it's lgpled).

Oh, and this is the library used for the current Color managment Gimp
1.2 plugin.


--
Daniel


[Index of Archives]     [Yosemite News]     [Yosemite Photos]     [gtk]     [GIMP Users]     [KDE]     [Gimp's Home]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux