[Openicc] Google Summer of Code 2009: Oyranos CUPS backend

[Ann L McCarthy]

This conversation is quickly pointing out the need for a metacontrol such 
that the users can direct behaviour using user friendly terms such as "I 
want to proof" and then having a control structure under the hood to make 
the choices of profiles accordingly.  Looking ahead, the new metadataTag 
in ICC can be used to label profiles internally so they can be selected 
properly by such a control structure.
If we are thinking about changing PPD -- then perhaps this concept can be 
considered.

Best regards,
Ann McCarthy
Imaging Systems R&D
Lexmark Imaging Solutions Division
Lexmark International, Inc.






Chris Murphy <lists at colorremedies.com> 
Sent by: openicc-bounces+almccart=lexmark.com at lists.freedesktop.org
05/17/2010 12:45 PM

To
openicc Liste <openicc at lists.freedesktop.org>
cc

Subject
Re: [Openicc] Google Summer of Code 2009: Oyranos CUPS backend






For the Epson Stylus Pro 3880, there are 12 manufacturer supplied ICC 
profiles totally 8.5MB in size. Each profile is 760K in size, roughly. 
Which is 1/3 to 1/4 the size of a good production quality profile. Now, 
this is probably OK quality for casual soft proofing. If you're looking to 
get better results (for printing as well) then better profiles are needed. 
As far as I'm aware, SEC doesn't supply them, however Epson America does 
make better profiles available via separate download.

So what if user at printerhost has downloaded or created superior profiles, 
and uses those for soft proofing and printing. But then user at remote is 
subject only to using PPD based profiles? (Or manufacturer supplied 
profiles?) It would be nice if there were a way for user at remote to have 
the option to use the better quality profiles, without having to download 
inferior ones first. cupsICCProfile is URI based isn't it?

While it can be argued the settings of user1 should not affect the 
settings user2 is subject to, I think a case can be made that 
user1 at printerhost is in a vastly better position to know what media is 
presently in the printer and thus what ICC profiles apply to the various 
printing modes, if they're going to be used at all. So if they've 
overridden them, it's probably a good idea for the option to present the 
remote user with alternate profiles. It might even be a good idea to 
suggest them as the default.

Another way to do this entirely would be three subset profiles that are 
only used for soft proofing, and are non-binding on the print job. Those 
categories would be: plain paper, glossy, and matte medias. While there 
clearly are differences between different matte media I think a single 
profile representing most matte media on the printer can set expectations 
at this level appropriately. Same for gloss. Same for plain paper.

Once the job arrives at the printerhost machine, then the correct profile 
based on actual media loaded (and perhaps a custom profile as specified by 
that printer's owner) is used for actual matching.


Chris

On May 17, 2010, at 10:06 AM, Kai-Uwe Behrmann wrote:

> A spooler is not required to pass a ICC profile from a remote location 
to a local host. This is still very much needed to support local proofing.
> 
> Given that CUPS' cupsICCProfile is just a name without garantee to see 
the profile in applications, embedding seems the only option? Or how could 
it be made a requirement to obtain the profile?
> 
> 
> kind regards
> Kai-Uwe Behrmann
> -- 
> developing for colour management www.behrmann.name + www.oyranos.org
> 
> 
> Am 17.05.10, 09:39 -0600 schrieb Max Derhak:
>> As Chris Murphy pointed out, I would be wary of assuming a one to one
>> relationship between a printer and a single profile.  Potentially each
>> media, output resolution, and halftoning strategy needs to have a
>> different profile.  Ideally you want to have something that allows all
>> the printing condition settings to select the profile.
>> 
>> My understanding is that this doesn't lend itself to using PPD's 
easily.
>> 
>> Max Derhak
>> Senior Software Architect
>> max.derhak at onyxgfx.com
>> 
>> 
>> -----Original Message-----
>> From: openicc-bounces+max.derhak=onyxgfx.com at lists.freedesktop.org
>> [mailto:openicc-bounces+max.derhak=onyxgfx.com at lists.freedesktop.org] 
On
>> Behalf Of Kai-Uwe Behrmann
>> Sent: Monday, May 17, 2010 9:22 AM
>> To: Leonard Rosenthol
>> Cc: Dov Isaacs; OpenICC Liste
>> Subject: Re: [Openicc] Google Summer of Code 2009: Oyranos CUPS backend
>> 
>> Am 17.05.10, 11:09 -0400 schrieb Leonard Rosenthol:
>>> On Mon, May 17, 2010 at 10:51 AM, Kai-Uwe Behrmann <ku.b at gmx.de>
>> wrote:
>>> 
>>>> What you propose is particially related to the "cupsICCProfile" PPD
>>>> keyword. By this keyword the ICC profile is only named and not
>> embedded in
>>>> the PPD as you suggest.
>>> 
>>> 
>>> In addition, cupsICCProfile isn't supported by desktop applications
>> (such as
>>> Adobe Acrobat/Reader) on any OS platform and certainly not in any
>> situation
>>> on Windows.   Is it widely enough used to even consider trying to
>> support
>>> it?  Certainly none of the major vendors are including this in
>> profiles
>>> supplied with printers - does it only appear in a customized CUPS
>> driver
>>> installation?
>> 
>> We have practical no support for cupsICCProfile on Linux. It supports
>> too
>> few use cases. Linux is much networked. A PPD embedded ICC profile 
would
>> 
>> be prefered.
>> 
>> 
>> kind regards
>> Kai-Uwe Behrmann
>> -- 
>> developing for colour management
>> www.behrmann.name + www.oyranos.org
>> 
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20100518/49465d01/attachment.htm>