Color management on non-Mac platforms
Adam Barth
CoreGraphics on Mac, which supports color management, but we use Skia
on non-Mac, which does not support color management. I'm finishing up
implementing color profile support in the WebKit image decoders, and I
was wonder if there was interest in using that color profile
information on non-Mac ports. Poking around a bit, there seems to be
an MIT licensed library for doing the color profile transformation:
Implementing color management on non-Mac ports would improve rendering
consistency between Chromium ports and between Chromium and Firefox.
Thoughts?
Adam
Adam Barth
Brett Wilson
I think it would be nice to include color management everywhere. The
only reason we haven't done this already is that it's nontrivial and
the only people qualified to work on it have been too busy.
Mozilla replaced lcms with their own which they claim is faster and
better suited to the way a web browser works:
http://muizelaar.blogspot.com/2009/06/qcms-color-management-for-web.html
The code is here:
http://mxr.mozilla.org/mozilla-central/source/gfx/qcms/
I would also prefer to use the same solution as Mozilla's also from a
security perspective. It deals with untrusted content, and going with
the solution actively being shipped in a popular browser seems safer.
Brett
Adam Barth
> On Tue, Nov 2, 2010 at 3:10 AM, Adam Barth <aba...@chromium.org> wrote:
>> Currently, we only support color management on Mac because we use
>> CoreGraphics on Mac, which supports color management, but we use Skia
>> on non-Mac, which does not support color management. I'm finishing up
>> implementing color profile support in the WebKit image decoders, and I
>> was wonder if there was interest in using that color profile
>> information on non-Mac ports. Poking around a bit, there seems to be
>> an MIT licensed library for doing the color profile transformation:
>>
>> http://www.littlecms.com/
>>
>> Implementing color management on non-Mac ports would improve rendering
>> consistency between Chromium ports and between Chromium and Firefox.
>
> I think it would be nice to include color management everywhere. The
> only reason we haven't done this already is that it's nontrivial and
> the only people qualified to work on it have been too busy.
Do you think it would be beneficial to start with color management
support for images and expand to other areas of the code
incrementally?
> Mozilla replaced lcms with their own which they claim is faster and
> better suited to the way a web browser works:
> http://muizelaar.blogspot.com/2009/06/qcms-color-management-for-web.html
>
> The code is here:
> http://mxr.mozilla.org/mozilla-central/source/gfx/qcms/
>
> I would also prefer to use the same solution as Mozilla's also from a
> security perspective. It deals with untrusted content, and going with
> the solution actively being shipped in a popular browser seems safer.
That sounds like a good idea to me.
Adam
Brett Wilson
> On Tue, Nov 2, 2010 at 9:15 AM, Brett Wilson <bre...@chromium.org> wrote:
>> On Tue, Nov 2, 2010 at 3:10 AM, Adam Barth <aba...@chromium.org> wrote:
>>> Currently, we only support color management on Mac because we use
>>> CoreGraphics on Mac, which supports color management, but we use Skia
>>> on non-Mac, which does not support color management. I'm finishing up
>>> implementing color profile support in the WebKit image decoders, and I
>>> was wonder if there was interest in using that color profile
>>> information on non-Mac ports. Poking around a bit, there seems to be
>>> an MIT licensed library for doing the color profile transformation:
>>>
>>> http://www.littlecms.com/
>>>
>>> Implementing color management on non-Mac ports would improve rendering
>>> consistency between Chromium ports and between Chromium and Firefox.
>>
>> I think it would be nice to include color management everywhere. The
>> only reason we haven't done this already is that it's nontrivial and
>> the only people qualified to work on it have been too busy.
>
> Do you think it would be beneficial to start with color management
> support for images and expand to other areas of the code
> incrementally?
If I were doing it I would do it for images and then stop :) I think
this is what Firefox does.
Brett
Adam Barth
Ok, that sounds like a tractable problem to me. I'm not sure if I
count as a "qualified" person, but I'll give it a try. Do you know of
a good set of test images? I've been using some images from
Wikipedia, but more test cases is better.
Adam
Scott Byer
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
Darin Fisher
Adam Barth
his point of view were color management (on the path to resolution)
and something about clipping:
http://neugierig.org/software/chromium/notes/2010/07/clipping.html
IMHO, consistency between Chromium ports is more important than
clipping, but everyone might not agree with that sentiment.
Adam
On Tue, Nov 2, 2010 at 10:50 AM, Darin Fisher <da...@chromium.org> wrote:
> So for Mac Chrome, this means that we are one step closer to being able to
> use Skia instead of CG. Is there a plan to go all the way? It seems like
> it would be nice to unify our ports.
>
Darin Fisher
Nico Weber
> I asked Nico about this on IRC. He said the two blocking issues from
> his point of view were color management (on the path to resolution)
> and something about clipping:
>
> http://neugierig.org/software/chromium/notes/2010/07/clipping.html
And he added
"3. It would be nice if skia was maintained somehow. If the choice is
between a system library that the OS provider maintains and uses for
all of its apps, and a in-house library without a maintainer with
known bugs that have been open for over a year, the choice doesn't
seem too hard"
or something to that effect :-)
Once these three are addressed, we can _start_ evaluating if it's
worth switching.
Nico
Adam Barth
> On Tue, Nov 2, 2010 at 2:00 PM, Adam Barth <aba...@chromium.org> wrote:
>> I asked Nico about this on IRC. He said the two blocking issues from
>> his point of view were color management (on the path to resolution)
>> and something about clipping:
>>
>> http://neugierig.org/software/chromium/notes/2010/07/clipping.html
>
> And he added
>
> "3. It would be nice if skia was maintained somehow. If the choice is
> between a system library that the OS provider maintains and uses for
> all of its apps, and a in-house library without a maintainer with
> known bugs that have been open for over a year, the choice doesn't
> seem too hard"
>
> or something to that effect :-)
>
> Once these three are addressed, we can _start_ evaluating if it's
> worth switching.
Like the color management and clipping issues, that seems like an
important problem to solve for the (N-1) of N Chromium ports that
don't run on Mac. :)
Adam
Peter Kasting
> "3. It would be nice if skia was maintained somehow. If the choice is
> between a system library that the OS provider maintains and uses for
> all of its apps, and a in-house library without a maintainer with
> known bugs that have been open for over a year, the choice doesn't
> seem too hard"
>
> or something to that effect :-)
Like the color management and clipping issues, that seems like an
important problem to solve for the (N-1) of N Chromium ports that
don't run on Mac. :)
PK
