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

[edmund ronald]

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/20120125/4fe6bb39/attachment-0001.htm>