[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openoffice-discuss
Subject:    Re: Re: Publisher export facility - do we need it?
From:       "Chris Sherlock" <csherlock () optusnet ! com ! au>
Date:       2004-03-30 2:26:17
Message-ID: c4aljq$cmj$1 () sea ! gmane ! org
[Download RAW message or body]

Macs have ColorSync that can handle all sorts of color issues. To a lesser
extent, so does Windows with it's use of ICM. After all, colour management
can be applied in the application or in the operating system. But really
this isn't the point. I'm not just talking about bitmaps. I'm talking about
tagged TIFs and JPEGs. Also support for sRGB would be a good idea as this is
the way that MS Office uses colour in it's documents. Another thing to
consider is that many DTPs apply colour management at an object level as
well as at a document level - with each object having a colour profile being
assigned to it. So let's say we use the scanner module in OpenOffice and
scan in an image. This image gets tagged with an ICC profile (well, this is
not really usual but I'm illustrating a point) by the scanner software and
so we assign this input profile with the object. Another object might come
from a camera - again it's tagged, but this time by a different profile.
Another object might be a bog standard bitmap and be completely untaggable,
in which case you might want to apply sRGB or Adobe1998 to this.

It would be of great benefit for apps to be able to support colour
management in a standard fashion. It's true that it might be better to have
a whole colour management system that works apart from X. I think there is
libICC and I do know about littlecms, but as I was saying it would be great
if KDE and GNOME could have a module where apps could get access to a
standard API for accessing colour management routines. I do note that the
gimp would *definitely* benefit from a module like this. Photoshop has it's
ACE engine and it'd be great if we could get a feature in gimp that could
take an input profile and apply an output ICC profile. I know many many
photographers and image people could use this (and in fact actually *do*
need this feature!)

Incidently, if you draw a bitmap then you would save it as a tagged TIF with
a profile created from your monitor. So colour management *would* be useful
in this case. In fact, it would have a great effect on printing because you
apply a rendering intent to the image that transforms the image's colour to
"conform" to an output profile. The only way to do this, however, is by
using an input profile which "describes" the colour. So with a tagged object
(or image) printing can be affected.

As an aside: I work for a printer manufacturer in support. We get this sort
of issue all the time! People keep asking why their images don't look the
same on the screen as on the paper, and through the use of input and output
profiles we are often able to alleviate the problems they are having. Mind
you, these customers need to be able to use Photoshop as it has the best
colour management IMHO.

Chris

"Sander Vesik" <Sander.Vesik@Sun.COM> wrote in message
news:4068AD8E.2090106@sun.com...
> Chris Sherlock wrote:
> > Sander Vesik wrote:
> >
> >> CPH wrote:
> >>
> >>> On Thursday 25 March 2004 11:01, Chris Sherlock wrote:
> >>>
> >>>> Well, here's a question. I was thinking that Linux really needs a
> >>>> properly integrated colour management system. I realise littlecms is
> >>>> out, but what I'd REALLY like to see is that it is modularised and
> >>>> integrated into GNOME *and* KDE.
> >>>>
> >>>> In fact, if I knew more about maths and physics (to do the colour
> >>>> transforms) then I'd attempt to do it myself!!!
> >>>>
> >>>> Anyone know of any plan on integrating a CMS into GNOME or KDE?
> >>>
> >>>
> >>>
> >>>
> >>> As far as I know this is planned for X under freedesktop.org.
> >>>
> >>
> >> But CMS in X doesn't really give apps all that much help...
> >
> >
> > How so? Maybe CMS could be integrated into Xlib (a new version)
> >
>
> Why do you see that helping the apps a lot? Unless they know the cms
> information about the sources, all it will do is make sure the
> 'sourceless' colours that you explicitly create in the app by drawing
> primitives look the same. If youhave a bitmap , this no longer applies.
> Worse, it doesn't do anything for printing
>
> > Chris
> >




[prev in list] [next in list] [prev in thread] [next in thread]