[Openicc] Helping with ... Architects and project leads

[Hal V. Engel]

On Wednesday, March 09, 2011 01:16:02 PM Graeme Gill wrote:
> Jan-Peter Homann wrote:
> > Currently, Projects like e.g. Oyranos or GCM have to guess, what would
> > may helpful to them and what they may would integrate into their apps.
> 
> Maybe. But I get the impression that often application writers
> don't know a whole lot about color management, and therefore
> look to the CMM for guidance in what they should do :-)

Yes this is difinitely the case for most app developement teams.  They look to 
the experts (us?) for guidence on how this should work.  What we need to do is 
get to the point where we have a working but perhaps feature limited framework 
and then we can go to these folks and ask some of them to try using it.  They 
will likely find a lot of things that are confusing or more difficult then they 
would like and this will help to refine the framework.  But having a prototype 
framework is critical since it will give us a common reference point that we 
can use to work with app teams that want to have something like that.

As an example the past work on KolorManager (think of it as an app that is 
using Oyranos although it used it in a different way than digiKam or Krita 
would) brought to light a lot of issues with Oryanos as well as many things 
that worked.  The fact that there were issues was not unexpected since Oyranos 
was fairly immature when this work was being done.   As a result Oyranos has 
way more fucntionality and is much closer to being ready for real world use 
and some parts are very mature at this point.  For example monitor CM is 
working nicely and on KDE KolorManager plus Oyranos does a good job with this.

> 
> > E.g. from my point of view, it would make e.g. sense for imaging
> > applications to use image based print spool format with embedded
> > document colorspace and CUPS raster-filter based on littleCMS with
> > support for cupsICCprofile.
> 
> A real CMM has somewhat more than that in it. Color transforms are
> heavyweight in general, so it's good to share the color tables
> by caching them in memory. Given that certain transformations
> will be quite commonly used by many applications (ie. sRGB ->
> the main display), this can be important.

This is also true for a print system.  After all it should be a fairly common 
transform to go from sRGB to either the printers RGB colorspace or it's CMYK 
colorspace.  Ghostscript already has caching for transforms so it should be 
fairly efficient in this regard and it may actually be more efficient than 
handling the transforms in a imagetoraster filter without duplication this same 
functionality which is non-trivial.  In fact it might be a good idea to have 
an imagetopdf filter which would be a fairly simple thing to implement and then 
pass the resulting pdf file to the pdftoraster filter and let ghostscript handle 
the color management since it is highly optimized for this already.  This 
would eliminate the need to put this same optimization and other CM related 
code into the image part of the print pipeline which would make the the whole 
implementation simpler as well as easier to maintain since all of this code 
would be in one location (the pdftoraster filter via GS or poppler) 

> 
> Graeme Gill.
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110309/5a0510bb/attachment.htm>