[Openicc] Printing Plans... Testcharts

[Jan-Peter Homann]

Hello all,
Looking ar commercial inkjet solutions, the detailed tasks for 
inklimiting, linearization / calibration , re-calibration, profiling are 
handled different in every solution.

e.g. some vendors provide only per channel ink-limit, othet provide 
additional ink limits for two, three and / or four channels.

also re-calibration is handled differnt in such solution ( a 
recalibration bring an ink-media setting to a defined reference, whitout 
the need to make a new profile)

e.g. some vendors do a recalibration per channel, some vendors do 
recalibration with a devicelink appoach.

I don´t think that it makes sense trying to standardize this steps and 
expose it in the PPD. Let such things be driver specific, but expose the 
ICC profile for a (re-calibrated) driver setting in a standardized way 
to CUPS, that differnt XXXtoraster filter can use this profile as a 
target profile.

If a utilitity for inklimit, linerarization, re-calibration and 
profiling interacts directly with the driver, it can lead the user step 
by step to right tasks with doing all the necessary driver 
configurations in the background.

If all such steps should be abstracted from the driver, and work through 
the whole CUPS chain with different libraries creating print spool files 
and different xxxtoraster filters, we will introduce a lot of potential 
places where things can go wrong.

kind regards
Jan-Peter

Am 07.03.11 10:40, schrieb Kai-Uwe Behrmann:
> Am 07.03.11, 20:24 +1100 schrieb Graeme Gill:
>> Jan-Peter Homann wrote:
>>> I don´t think, that such printing, calibration and profiling tasks
>>> should be handled through the complete CUPS chain.
>>
>> Creating separate workflows can make things unreliable if
>> accidentaly different treatment creeps in. Using a very similar
>> process to that used for calibration & profiling, it should be
>> possible to verify that the calibration or profiling is
>> having the intended effect in the print workflow.
>
> With the later I agree.
>
>>> Using a utility directly interacting with the driver like e.g.
>>> Gutenprint will be much more transparent and failure proof.
>>
>> Expecting the profiling package to directly interact with
>> the printing environment would multiply the work needed
>> in creating a calibration & profiling application considerably.
>> There should always be a method of performing this sort of task
>> in independent steps, both to allow a wide range of mix and match,
>> and to be able to diagnose what's going on.
>
> The question is how to get the PPD calibration part out of the way.
> I found Jan-Peter's listing of what is what quite helpfule to give 
> them names. Maybe some further to be defined meta tagging can help 
> getting this sorted.
> Questions come like:
> * what is the basic calibration stage?
> * how is raw printing, before ink limiting, to be labeld and 
> communicated?
> ...
>
>> Direct interaction with the printing environment should be possible
>> (for a smoother user experience), but not essential.
>
> I am a huge fan of Gutenprint. But from a architecture and usability 
> point of view its better to need not too much specialities. 
> Calibration and profiling are very common tasks. Having them 
> integrated, in PPD, would be a big plus for Linux environments.
>
>
> kind regards
> Kai-Uwe Behrmann
>
>
> _______________________________________________
> 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110307/09348226/attachment-0001.html>