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.<div> <br></div><div>Edmund<br><br><div><br><div class="gmail_quote">On Wed, Jan 25, 2012 at 9:28 PM, edmund ronald <span dir="ltr"><<a href="mailto:edmundronald@gmail.com">edmundronald@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Michael, <div><br></div><div> 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. </div> <div><br></div><div> 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. </div> <div><br></div><div> 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.<span class="HOEnZb"><font color="#888888"><br> <br><div class="gmail_quote">Edmund</div></font></span><div><div class="h5"><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">On Wed, Jan 25, 2012 at 9:16 PM, Michael Sweet <span dir="ltr"><<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div>On Jan 25, 2012, at 11:55 AM, edmund ronald wrote:</div><blockquote type="cite"> Michael,<div> </div><div>I don't quite understand 16 bit colorN as a solution to most printing problems, at least for Gutenprint.</div></blockquote><div><br></div></div>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.</div> <div><br></div><div>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.</div><div><br></div><div>As others have noted, relying on existing calibrations for new media or ink does not always work well.</div> <div><br></div><div>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.</div> <div><br></div><div>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.</div> <div><br></div><div>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.</div> <div><div><div><br></div><div><blockquote type="cite"><div><br></div><div>Maybe you could outline a realistic way you think the system would operate, so we can understand the intended design philosophy. </div> <div><br></div><div>Edmund</div><div><br><div class="gmail_quote">On Wed, Jan 25, 2012 at 5:10 PM, Michael Sweet <span dir="ltr"><<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div>On Jan 25, 2012, at 2:19 AM, Kai-Uwe Behrmann wrote:<br> > ...<br> </div><div>> 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.<br> > 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?<br> <br> </div>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.<br> <br> (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...)<br> <div><br> __________________________________________________<br> Michael Sweet, Senior Printing System Engineer, PWG Chair<br> <br> </div><div><div>_______________________________________________<br> openicc mailing list<br> <a href="mailto:openicc@lists.freedesktop.org" target="_blank">openicc@lists.freedesktop.org</a><br> <a href="http://lists.freedesktop.org/mailman/listinfo/openicc" target="_blank">http://lists.freedesktop.org/mailman/listinfo/openicc</a><br> </div></div></blockquote></div><br></div> _______________________________________________<br>openicc mailing list<br><a href="mailto:openicc@lists.freedesktop.org" target="_blank">openicc@lists.freedesktop.org</a><br><a href="http://lists.freedesktop.org/mailman/listinfo/openicc" target="_blank">http://lists.freedesktop.org/mailman/listinfo/openicc</a></blockquote> </div><br><div> <span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px"><div> __________________________________________________</div><div>Michael Sweet, Senior Printing System Engineer, PWG Chair<br></div></span> </div> <br></div></div></div><br>_______________________________________________<br> openicc mailing list<br> <a href="mailto:openicc@lists.freedesktop.org" target="_blank">openicc@lists.freedesktop.org</a><br> <a href="http://lists.freedesktop.org/mailman/listinfo/openicc" target="_blank">http://lists.freedesktop.org/mailman/listinfo/openicc</a><br></blockquote></div><br></div></div></div> </blockquote></div><br></div></div>