[Openicc] Jan Peter's workflow remarks. RESEND

Tue May 15 02:15:45 PDT 2012

RESEND OF A TRUNCATED MESSAGE. Sorry.

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.

Indeed. And this raises the issue of giving the developers and
endusers some diagnostic tools to see what profiles if any have been
applied, and with which intent.

>
> 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

ADD:
Task 0 configuring a queue by initial installation.
Taks 4 checking that thesettings (ink, profile) loaded when printing
is really the one one needs for the media.

>
> 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).

Jan Peter, a different print path is a place where bugs will breed.
However, a special carefully maintained app to help people print
targets through the standard print path (with CM-off), maybe complete
with a set of targets for various use-cases, might be a very good
idea. Most profiling software has a target generator which can print.
I think Argyll and friends will be delighted to propose a GUI tool for
generating/loading targets and printing them.

> (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)
Yes, there is this interesting problem of documenting the settings
which are being used at a given moment, and some diagnostic tools are
needed.

> 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
I don't know. Might be useful as a diagnostic aid to Gutenprint
developers, but normally testcharts should be sent through the usually
filter chain with the CM-off flag attached.

> - Measure the testchart
> - Calculate the printer profile automatically with ArgyllCMS
> - Embedd the Gutenprint Settings as Metadata into the printer profile
Evidently all the functionality Jan-Peter is describing needs to be
provided at the end, and one app which can do most of it would be
nice. In tje mean time, while we are bringing the system up, the
CM-off flag will let users print targets from mostly any legacy app
eg. Gimp, however we should really start thinking about diagnostic
tools because now is the time we need them most.

>
> 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 list
> openicc at lists.freedesktop.org
> http://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
>
>
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc