Hi, Continuing color management discussion, it would be great to get advice for some of the questions I have before starting coding up. There are already some libraries to parser and convert icc profiles. One of them is little cms[1] and it's being used by many applications, specially because it is simple and works with specifications version 2 and 4. However, after looking at how WebKit deals with externals dependencies, I had the impression that they are tried to be avoided as much as possible, and due to that, some tools end up being written from scratch(like SVG, MathML, image decoders, and other parsers). Now we have two possible paths: a) use an external dependency(littlecms for example); b) write from scratch all the ICC Profile specification; What do you guys think what the best approach? [1] http://www.littlecms.com/
01.09.2010, в 08:31, Igor Trindade Oliveira написал(а):
a) use an external dependency(littlecms for example);
b) write from scratch all the ICC Profile specification;
What do you guys think what the best approach?
I think that the first question to answer is why a CMS implementation is needed in WebKit at all. It's normally the job of a drawing library to perform the conversion behind the scenes. For example, one can specify a color space when drawing with CoreGraphics (as used by Mac and Windows Safari). If some platforms don't have such support, deciding what to do with colors should be left to platform-specific code in WebKit anyway. This is what already happens with images that have color profiles embedded, for example. - WBR, Alexey Proskuryakov
2010/9/1 Alexey Proskuryakov <ap@webkit.org>:
01.09.2010, в 08:31, Igor Trindade Oliveira написал(а):
a) use an external dependency(littlecms for example);
b) write from scratch all the ICC Profile specification;
What do you guys think what the best approach?
I think that the first question to answer is why a CMS implementation is needed in WebKit at all. It's normally the job of a drawing library to perform the conversion behind the scenes.
For example, one can specify a color space when drawing with CoreGraphics (as used by Mac and Windows Safari). If some platforms don't have such support, deciding what to do with colors should be left to platform-specific code in WebKit anyway.
This is what already happens with images that have color profiles embedded, for example.
- WBR, Alexey Proskuryakov
Hi, in Qt and Cairo Graphics side does not exist internally any color management system normally the application that needs it uses a external dependency like littlecms, this approach is used by Krita[1] for example. So if the graphics api does not have any support to color management the fallback could be done to WebKit CMS. Other use case could be used by icc support in css3. In the last draft, css3 drops color-profile property due to a lack of implementation [2][3]. [1] www.koffice.org/krita/ [2] http://oyranos-cms.blogspot.com/2010/06/css3-and-icc-colour-profiles.html [3] http://www.w3.org/TR/css3-color/#dropped
On Sep 1, 2010, at 9:52 AM, Igor Trindade Oliveira wrote:
2010/9/1 Alexey Proskuryakov <ap@webkit.org>:
01.09.2010, в 08:31, Igor Trindade Oliveira написал(а):
a) use an external dependency(littlecms for example);
b) write from scratch all the ICC Profile specification;
What do you guys think what the best approach?
I think that the first question to answer is why a CMS implementation is needed in WebKit at all. It's normally the job of a drawing library to perform the conversion behind the scenes.
For example, one can specify a color space when drawing with CoreGraphics (as used by Mac and Windows Safari). If some platforms don't have such support, deciding what to do with colors should be left to platform-specific code in WebKit anyway.
This is what already happens with images that have color profiles embedded, for example.
- WBR, Alexey Proskuryakov
Hi,
in Qt and Cairo Graphics side does not exist internally any color management system normally the application that needs it uses a external dependency like littlecms, this approach is used by Krita[1] for example. So if the graphics api does not have any support to color management the fallback could be done to WebKit CMS.
Other use case could be used by icc support in css3. In the last draft, css3 drops color-profile property due to a lack of implementation [2][3].
It seems like this support would just be behind the GraphicsContext abstraction (which is already colorspace-aware). I don't see why you'd need code above GraphicsContext. Even color-profile in CSS should ultimately just pass the contents of the color profile to GraphicsContext. For example CoreGraphics supports CGColorSpaceCreateWithICCProfile, so I'd just expect GraphicsContext to take the ICC profile data and let the platform decide what to do with it. dave (hyatt@apple.com)
2010/9/1 David Hyatt <hyatt@apple.com>:
On Sep 1, 2010, at 9:52 AM, Igor Trindade Oliveira wrote:
2010/9/1 Alexey Proskuryakov <ap@webkit.org>:
01.09.2010, в 08:31, Igor Trindade Oliveira написал(а):
a) use an external dependency(littlecms for example);
b) write from scratch all the ICC Profile specification;
What do you guys think what the best approach?
I think that the first question to answer is why a CMS implementation is needed in WebKit at all. It's normally the job of a drawing library to perform the conversion behind the scenes.
For example, one can specify a color space when drawing with CoreGraphics (as used by Mac and Windows Safari). If some platforms don't have such support, deciding what to do with colors should be left to platform-specific code in WebKit anyway.
This is what already happens with images that have color profiles embedded, for example.
- WBR, Alexey Proskuryakov
Hi,
in Qt and Cairo Graphics side does not exist internally any color management system normally the application that needs it uses a external dependency like littlecms, this approach is used by Krita[1] for example. So if the graphics api does not have any support to color management the fallback could be done to WebKit CMS.
Other use case could be used by icc support in css3. In the last draft, css3 drops color-profile property due to a lack of implementation [2][3].
It seems like this support would just be behind the GraphicsContext abstraction (which is already colorspace-aware). I don't see why you'd need code above GraphicsContext. Even color-profile in CSS should ultimately just pass the contents of the color profile to GraphicsContext.
For example CoreGraphics supports CGColorSpaceCreateWithICCProfile, so I'd just expect GraphicsContext to take the ICC profile data and let the platform decide what to do with it.
dave (hyatt@apple.com)
My concern about this approach is have duplicated code in plataform code because many of them do not provide any kind of ICC profile support(qt and cairo for example). But is good to see we are reaching a consensus. Igor
On Sep 2, 2010, at 6:39 AM, Igor Trindade Oliveira wrote:
My concern about this approach is have duplicated code in platform code because many of them do not provide any kind of ICC profile support(qt and cairo for example).
Code can be shared between platforms even if it’s in the platform-specific layer; it does not have to be duplicated just because it’s not used in all the platforms. -- Darin
Igor, On Thu, Sep 2, 2010 at 7:52 AM, Darin Adler <darin@apple.com> wrote:
On Sep 2, 2010, at 6:39 AM, Igor Trindade Oliveira wrote:
My concern about this approach is have duplicated code in platform code because many of them do not provide any kind of ICC profile support(qt and cairo for example).
To properly support this on Qt and Cairo (perhaps Skia?) we just need to add the logic to the platform/graphics layer of WebKit. We already do this with certain common functions such as JPEG decoding and so forth. We could add a 'little CMS' support directory and place the logic here, then use its functions from within the specific Cairo/Qt/etc backends. You should file a bug about this request, along with some specifics of how this feature could be validated. I must admit to being pretty clueless when it comes to CMS support, and how to verify that things are working properly. Plus I'm color blind! -Brent
participants (5)
-
Alexey Proskuryakov
-
Brent Fulgham
-
Darin Adler
-
David Hyatt
-
Igor Trindade Oliveira