<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <html><head><meta name="qrichtext" content="1" /><style type="text/css"> p, li { white-space: pre-wrap; } </style></head><body style=" font-family:'DejaVu Sans'; font-size:12pt; font-weight:400; font-style:normal;"> 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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/openicc </body></html>