[Openicc] Gutenprint mission ... Printer profiling workflow

Tue May 15 01:44:36 PDT 2012

On Tue, May 15, 2012 at 10:30 AM, Jan-Peter Homann <
homann at colormanagement.de> wrote:

>  Hello to all, some feedback from a non-developer:
>

Hopefully we are going to get a lot of feedback from non developers, as
most color experts are not developers :)

>
> The color transformation from the document space to printer colorspace can
> be done in several places:
> - local application like e.g. gimp, scribus or other
> - CUPS filter like e.g. GhostScript, Poppler
> - Printer Driver like e.g. Turoprint
>
Maybe we should add external color management ie. using a Linux queue Linux
as print server to this list.

> For working with printer profiles, it is necessary, that the whole chain
> application->CUPS-Filter->Driver is transparent to the enduser, and that
> the enduser can be shure, that there is no double or triple transformation
> of print data in the chain. Reaching such transparency is a very
> challinging tasks, which has not been solved till today in Mac OS X or
> Windows environments incl. Adobe applications and drivers of the main
> printer vendor.
>
> Typical tasks for endusers are:
> 1) decide, where the printer profile should be used (application,
> CUPS/Filter, Driver)
> 2) Configure the chain, to avoid double or triple color transformations
> 3) create or choose a printing queue / driver setting which relates to the
> printer profile
>     3a. Install a standard printer profile for this queue / setting (This
> could be also a printer profile which have embedded driver settings)
>     3b. Optionally print a testchart  for profiling
>
> From my experience of making printer profiles since 15 years, it makes a
> lot of sense, that the tasks of:
> - choosing the driver setting (optional with calibration / setup of inkl
> limits, ...)
> - printing the testchart
> - measuring the testchart and calculating the printer profile
> - connecting the printer profile and the driver settings
>
> are done in very controlled environment. If possible I would prefer a
> solution which by passes CUPS and any filters and sends the testchart for
> profiling as bitmap data direct to the printer driver (e.g. Gutenprint).
> (For shure it helps very much, if we have optional a controlled way to
> send profiling testcharts through the CUPS / Filter chain. If this is the
> case, I would recommend, that the printed testchart has an additional
> control slug / text line, which documents the color settings of the CUPS
> queue and all involved filters)
>
> In a LINUX environment with ArgyllCMS and Gutenprint, I would prefer a
> special application, which guides the user through the differnt steps for
> profiling the printer and which has a direct connection to ArgyllCMS and
> Gutenprint.
>
> A basic scenario for a first version of such applicazion could be:
> - Choose a predefined Gutenprint setup (creating such setups and
> calibration is a task for a future version)
> - Choose your measurement instrument
> - Choose the testchart
> - Send the testchart as bitmap directly to Gutenprint
> - Measure the testchart
> - Calculate the printer profile automatically with ArgyllCMS
> - Embedd the Gutenprint Settings as Metadata into the printer profile
>
> Perfect would be, when the printer profile would be automatically
> configured in the printing enviroment. But this tasl is very dependend from
> the choosen printing environment. If Oyranos or colord is part of the
> printing enviroment and connected to the profiling application, the
> automatic configuration of the printer profile should be possible.
>
>
> Best regards
> Jan-Peter
>
>
>
>
> Am 15.05.12 04:12, schrieb edmund ronald:
>
> The previously cited reference [1] is clearly written and well argued, at
> Gutenprint we can live with it, let's give some names and values to the
> actual flags used eg. as per Mike's suggestion and get on with pushing this
> thing out the door!
>
>  We might also include [1] as a whole in the documentation so that domain
> specialists can understand what we are doing.
>
>  Edmund
>
>  [1] http://lists.freedesktop.org/archives/openicc/2011q2/003659.html
>
>
>
> On Tue, May 15, 2012 at 3:58 AM, Graeme Gill <graeme at argyllcms.com> wrote:
>
>> James Cloos wrote:
>> > I do hope we end up with an option which is *much* shorter than, eg,
>> > org.linuxfoundation.color-managed or the like.  Something more like
>> > OPColorManaged would be nicer.  A longer description can be provided
>> > in the ppd.
>>
>>  I did draft this at the time <http://www.argyllcms.com/SCPS_Tag.txt>
>> as a point for discussion.
>>
>> Graeme Gill.
>>  _______________________________________________
>> openicc mailing list
>> openicc at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/openicc
>>
>
>
>
> _______________________________________________
> openicc mailing listopenicc at lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/openicc
>
>
>
> --
> ----------  Please note the new adress --------------
>
> homann colormanagement --------- fon +49 30 611 075 18
> Jan-Peter Homann ------------ mobile +49 171 54 70 358
> Cotheniusstr. 3 -------- http://www.colormanagement.de
> 10407 Berlin -------- mailto:homann at colormanagement.de <homann at colormanagement.de>
>
>
> _______________________________________________
> 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/20120515/9c006d9e/attachment.htm>