[Openicc] printer, driver, CUPS, PPD, printing GUI, ICC-profiles, colord, Oyranos, taxi....

[edmund ronald]

To clarify, the remark about the ink curves is there to say that Gutenprint
may need per media  metadata even for DeviceCMYK and thus 16 bit DeviceCMYK
is not a magic bullet. It would really be better to engineer a clean way
from the beginning to send Gutenrpint  an XML preset file, for instance
including a preset as XML data embedded in a profile is a perfectly viable
possibility.

Edmund


On Wed, Jan 25, 2012 at 9:28 PM, edmund ronald <edmundronald at gmail.com>wrote:

> Michael,
>
>  I think that only rgb profiling is at present really appropriate for
> Gutenprint; Even printing in Device CMYK implies that ink curves eg C2CC'
> be defined, and also profiling in CMYK requires a lot of samples, and is
> not necessarily something even the advanced amateur is going to have fun
> with.
>
>  Really, I do think that any color managed print system that relies on
> Gutenprint should at present be able to operate with 8 bit per channel  RGB
> data, and allow sending Gutenprint calibration data ie, ink curves, drop
> sizes to use etc, and an RGB profile.
>
>  If the calibration data (presets) are dumped in an XML file, the current
> Gutenprint iteration should be able to do the job with very little software
> engineering. Anything else takes us into utopia.
>
> Edmund
>
>
> On Wed, Jan 25, 2012 at 9:16 PM, Michael Sweet <msweet at apple.com> wrote:
>
>> On Jan 25, 2012, at 11:55 AM, edmund ronald wrote:
>>
>> Michael,
>>
>> I don't  quite understand 16 bit colorN as a solution to most printing
>> problems, at least for Gutenprint.
>>
>>
>> Normally Gutenprint performs internal transforms from CMYK or (s)RGB to
>> DeviceN using calibrations for specific media and resolution settings.
>>  Gutenprint also provides an uncalibrated DeviceN path that provides access
>> to each ink individually vs. mapped from RGB or CMYK.
>>
>> Current ICC-based solutions use the RGB or CMYK paths to "calibrate" the
>> color - you print a target image, measure the target, generate a profile,
>> and use it.
>>
>> As others have noted, relying on existing calibrations for new media or
>> ink does not always work well.
>>
>> We can choose to pass calibration data to Gutenprint, perhaps through ICC
>> profile metadata, but that doesn't solve the general profiling case and
>> requires a special app to profile just for Gutenprint.
>>
>> We can also choose to support an uncalibrated 16-bit DeviceN space where
>> 0 means no ink and 65535 means 100% ink (for each color). This supports
>> having a general profiling application and is not driver-specific.  And
>> certain key information (such as number and type of colorants) could be
>> supplied as PPD keywords for the Gutenprint driver ("this is a 7-color
>> printer with C, LC, M, LM, Y, K, LK inks") which would take care of the
>> initial defaults when working with standard colorants for the printer.
>>
>> I will grant that the general DeviceN design has a serious issue: there
>> are no DeviceN color profiling tools (generally?) available to support N >
>> 4, which means that Open Printing would be treading on new ground.  There
>> is also the issue of printer modes - depending on the media you might
>> choose between two different sets of drop sizes, for example; in that case
>> we are back to the "how do I tell the printer/driver that I have a
>> derivative media type?" question, which I proposed could simply be an
>> extension naming scheme.
>>
>>
>> Maybe you could outline a realistic way you think the system would
>> operate, so we can understand the intended design philosophy.
>>
>> Edmund
>>
>> On Wed, Jan 25, 2012 at 5:10 PM, Michael Sweet <msweet at apple.com> wrote:
>>
>>> On Jan 25, 2012, at 2:19 AM, Kai-Uwe Behrmann wrote:
>>> > ...
>>> > As it was not clear in the past how to place Gutenprint calibration
>>> data passed along PPD files, I am much interessted how does the situation
>>> change for that through IPP.
>>> > How do you plan to populate your calibration data along Gutenprint
>>> vendor ICC profiles in a IPP world? Do you plan to make use of the IPP
>>> "printer-icc-profiles" attribute and the associated job ticket attributes?
>>>
>>> Gutenprint "calibration" data isn't something that can be passed as
>>> options presently; at the IPP level we can support sending arbitrarily-long
>>> lists of numbers (as might be used for a lookup table) as an attribute
>>> which the driver will see as a comma-delimited string on the command-line,
>>> however that seems like a poor solution in the long term since it requires
>>> the application or toolkit to furnish that data each time.
>>>
>>> (Gutenprint *does* have a real 16-bit per color DeviceN path, and if
>>> that path was supported by Ghostscript then that would likely be a viable
>>> option for an ICC-based workflow...)
>>>
>>> __________________________________________________
>>> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>>
>>> _______________________________________________
>>> 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
>>
>>
>>  __________________________________________________
>> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>
>>
>> _______________________________________________
>> 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/20120126/62edd5dd/attachment.html>