Re: [Printing-architecture] [Printing-japan] Last OP SC - Mon/Tue -2/3 February 2009 - The Recording

[Till Kamppeter <till.kamppeter@gmail.com>]

Done.

See "More info" link on Summit Wiki page.

https://www.linuxfoundation.org/en/OpenPrinting/OpenPrinting_Summit_San_Francisco_2009
https://www.linuxfoundation.org/en/OpenPrinting/Summit_2009/Color_Management

    Till


Petrie, Glen wrote:
> Hal,
> 
> That was a great reply.  It puts the necessary details and spin on my
> input to create the foundation for the summit discussion.  I can see
> several items that can be discussed and addressed relative to print
> vendors, driver developers, foomatic, end-users and color managers.
> 
> Till, if you had time (I know you don't sleep) it would great to put
> Hal's last email on the Wiki for the Summit as foundational material for
> this session.
> 
> Glen
> 
>> -----Original Message-----
>> From: Hal V. Engel [mailto:hvengel@astound.net]
>> Sent: Thursday, February 05, 2009 5:33 PM
>> To: printing-architecture@lists.linux-foundation.org
>> Cc: Petrie, Glen; Printing-japan
>> Subject: Re: [Printing-japan] [Printing-architecture] Last OP SC -
> Mon/Tue
>> -2/3 February 2009 - The Recording
>>
>> On Thursday 05 February 2009 08:41:07 am Petrie, Glen wrote:
>>> Hello Hal,
>>>
>>> Thanks for review of our printing "color management" discussion.  We
> are
>>> all looking for inputs to help in this complex subject.
>>>
>>> PLEASE, please, ... note that my only objective in my reply below is
> to
>>> seek understanding and create general understanding by all
> interested
>>> parties.
>> That is one of the primary intents of OpenICC participation here and
> with
>> other projects.  The other intent to get and keep color management on
> the
>> table until it is an accepted part of all of those systems where it
> should
>> be
>> used.  In addition we are active in doing actual CM related coding for
>> various
>> applications some of which are CM specific like LProf, ArgyllCMS,
> Oyranos,
>> Kolor Manager, iccexamin and LCMS.
>>
>>> I have exactly the same understanding that you do in discussing
> document
>>> applications.  That is applications like GIMP, Open Office, and so
>>> forth.  Each of these document applications must work with
> different,
>>> multiple, modified, enhanced and even user defined color spaces.
>> Of course some of these are smarter than others about color
> management.
>> GIMP
>> and Krita have some CM awareness but do not know how to handle CM when
>> printing.  As far as I know OpenOffice is color management dumb (as
> that
>> term
>> would be used by OpenICC members).  Probably the two most advanced
>> document
>> handling applications with regard to color management are Cinepaint
> and
>> Scribus both of which can handle CM printing.  Cinepaint along with
> Kolor
>> Manager are the only apps that currently use Oyranos which is the
> system
>> level
>> CM configuration back end.  The Scribus, Cinepaint and Krtia projects
> have
>> active representation on the OpenICC and OpenICC was founded by one of
> the
>> Scribus developers.
>>
>> Having already worked with a number of projects on this process these
> seem
>> to
>> fall into three groups.
>>
>> 1. The "we are already working on it" group.  In this group are
> projects
>> like
>> Cinepaint, Scribus, UFRAW, Krita, ImageMagick and GhostScript.
>>
>> 2. The projects who after being pushed a little about CM say "OK your
>> right we
>> need CM, we will get back to you when we have something working".
> This is
>> what happened with X-Sane and recently Poppler.  All these folks
> needed
>> was
>> for someone to point out the need and they were off and running
> without
>> any
>> need to assist them although in some cases it took awhile to happen.
>>
>> 3. The "OK your right we do need CM but we don't know how to approach
> this
>> can
>> you help" group?  Open Printing appears to be in this group.
>>
>> The first step is for them to understand CM basics.  At this point we
> are
>> not
>> even talking about how the CM tools or APIs work.  This is just an
>> advanced
>> user level understanding of how things should work.   At this stage it
>> seems
>> that almost every group I have worked with goes through a "we need a
>> standard
>> color space" phase.  This is where you guys are at and the OpenICC
> group
>> is
>> more than happy to spend some time working through this with you.
>>
>> Next you need to understand what your part of the puzzle needs to do
> to
>> support CM.  Printing happens to be the most complex single area with
>> respect
>> to CM because of the number of variables involved and the breath of
> things
>> that need to be done and the number of systems touched by this.  This
> is
>> most
>> definitely not something that will be trivial to implement although
> most
>> of
>> the work will be on things that are not directly related to using the
>> color
>> management back end.
>>
>>> What about printing?
>>>
>>> Let's define the print processes as starting with a document
>>> application, moving to a print spooler/manager (i.e. CUPS) and
>>> associated transforms (i.e. Ghostscript); and, finally, the print
>>> drivers which produces the physical print.
>>>
>>> As I stated above document application must handle "color
> management" in
>>> its broad scope.
>>>
>>> The print spooler/Manager, like CUPS, does not care about "color
>>> management".  Yes, CUPS has a capability to produce "raster" output,
> but
>>> as a generic spooler/manager it is does not get involved in the
> "color
>>> management" aspects of a document.
>> It is on OS/X though the proprietary*torafter filters that Apple
> supplies.
>>> CUPS (spooler/manager) can manage
>>> transforms for the print jobs.  Example would be PS-to-image or
>>> PDF-to-image.  In this case, CUPS is using a transform application;
> but
>>> CUPS itself does not get involved in the "color management"
> processing.
>> See above.
>>
>>> << side note >>  Part of understanding is understand terms.  To me,
> but
>>> not to all people, the term "raster" refers dithered, ink (not
> color,
>>> but ink) output values that a printer actually prints.  A "raster"
> is
>>> not RGB or any other color set of values; even if the image format
> is
>>> not a standard; like CUPS "raster".  CUPS "raster" should be called
> CUPS
>>> image.
>>>
>>> Back to transforms, like Ghostscript which, like CUPS above, is only
>>> being used as an illustrative example.  Transform applications like
>>> Ghostscript, to me, are document application; they are not print
>>> application in the sense that it is not a printer driver.  Yes,
>>> Ghostscripts contains, actually, it supports drivers; but actually,
>>> Ghostscript transforms a document from one format to another.
> Example,
>>> it transforms a PDF or PS document to an image document (and not a
>>> raster format).  And yes, I'll bet Ghostscript can actually produce
>>> actually raster output; but, I am trying to make the point that most
>>> transforms are document format transform.  Thus, Ghostscript follows
>>> your description below and needs to support all aspects of color
>>> management you describe.
>>>
>>> If what I discussed above is the scope of the "color management"
>>> discussion for the print summit; then I believe, the "color
> management"
>>> group (you) need to continue your great support and creating
>>> understanding to the document applications.  However, if the "color
>>> management" is about color-to-ink, then .....
>> It is about creating a per pixel "raster" that is in device specific
>> colors.
>> This would not include things like dithering and half toning but as
> you
>> correctly point out these things and other printer settings affect how
> the
>> device reproduces colors and they must be taken into account in the
>> profiling
>> process.  I will add more details below about this including what I
> mean
>> by
>> "device".
>>
>>> This is where I need your help on how to use and incorporate your
> "color
>>> management" with printing at the driver level.
>>>
>>> Conditions:
>>> 1. Inks are not pure colors;
>>> 	that is cyan ink is not real pure cyan color
>>> 	and the same is true for all inks.
>>>
>>> 2. Inks can only be deposited in discrete units (i.e. a drop
>>> 	and drops of different sizes).
>>> 	Thus, dithering is required in order to create the
>>> 	desired image color; but this is a tradeoff with
>>> 	not creating undesirable artifacts or blurring the final
>>>       print representation of the image.  And this is coupled
>>> 	with print intent; that is, dithering is different for line
>>> 	art/text than photos.
>>>
>>> I don't think of "color management" is doing the dithering but only
>>> concerned that the color value of an individual pixel (maybe an
> area)
>>> meets the intent.
>> This is basically correct.  One common misconception is that the color
>> profiles contain "calibration" information**.  A color profile
> contains a
>> characterization (mathematical description) of the devices
> reproduction
>> characteristics and it has no affect on the actual characteristics of
> the
>> device.
>>
>> The profile contains a mapping between an absolute color space such as
> CIE
>> XYZ
>> or CIE Lab and the "devices" representation.  The absolute color space
> is
>> called the Profile Conversion Space or PCS.
>>
>> The term device is somewhat loosely used in that this is referring to
> not
>> just
>> the physical device or hardware but any software processing that
> occurs
>> between when the profile is applied and what the actual physical
> hardware
>> does.  In the case of printers the "device" includes driver level
>> functionality like dithering.   For something like a camera the
> "device"
>> in
>> this context might include the RAW conversion software if that was
> being
>> used
>> or the in camera processing if the user were using images processed
>> directly
>> in the camera.   Again we are in general agreement and the above was
> to
>> clarify terminology.
>>
>> Because ICC profiles contain information for transforming from (in the
>> case of
>> output devices like printers) or to (in the case of input devices like
> a
>> scanner) an absolute color space it takes two profiles to do any
> useful
>> work.
>> On the output side a somewhat simplified flow would look like:
>>
>> document color space(s) -> transform(s) -> PCS -> transform -> printer
>> color
>> space
>>
>> It is fairly normal for advanced users to work in a number of color
> spaces
>> as
>> part of their work flow.  Typically users will have one or more
> "working
>> color
>> spaces" that they do editing work in and that there stored documents
> use.
>> In
>> general working color spaces are generic non-device specific color
> spaces.
>> This working color space could be sRGB but advanced users will
> typically
>> select something with a wider gamut such as BetaRGB or proPhotoRGB
> because
>> sRGB is too limited to handle the gamuts of most capture work flows.
>> Users
>> want to preserve document content as far into the process as possible
> even
>> if
>> some of that content will be lost when it is reproduced on a smaller
> gamut
>> device like a printer.
>>
>> For input devices users will as part of the capture work flow
> transform
>> from
>> the input devices (camera or scanner) color space to a working color
>> space.
>> Then when working on the image/document in color management aware
> software
>> (like GIMP, Krita, Cinepaint, Scribus...) the content on the monitor
> will
>> be
>> transformed from the document color space to the monitor color space
> when
>> it
>> is sent to the device but the actual document content will remain
>> unchanged by
>> this process.  The same thing is be true when a document is printed
> since
>> both
>> a printer and a monitor are output devices.
>>
>>> Color Management could "help" with "1." above if an ICC profile is
>>> supplied for every print.  That is, a document is transformed from
> its
>>> current color representation to the printer's gamut.
>> This is basically correct although is is somewhat more complex than
> this.
>>> But this would
>>> only be "helping" since dithering "2." Typical affects the details
> of
>>> color-to-ink transformation.  Thus, this color-to-ink transform is
>>> typically done in the driver which understand both the effects on
> color.
>> Again this is basically true.  But as you point out printer settings
> like
>> dither, media type, resolution and other things can affect the
> color/tonal
>> reproduction of the printer.  Because of this it should be fairly
> apparent
>> that those who are really picky about this will have a profile for
> each
>> print
>> mode (media type, resolution, dither...) that they use.  They will
> also
>> tend
>> to use only a limited set of these.  If you look at the documentation
> for
>> the
>> cupsICCProfile PPD setting you see that it is possible to define an
>> arbitrary
>> number of ICC profiles for the device that will be used under
> different
>> conditions and that it is possible to specificity up to three things
> that
>> will
>> be used by the CUPS to select which profile will be used.  By default
>> these
>> are media type, resolution and output color space type (RGB, CMYK or
> Gray
>> currently).  It is possible to override these defaults with some other
>> printer
>> setting such as dither to help with the profile selection process.
>>
>> The basic idea is sound but having only three variables is too
> limiting
>> and
>> this should be expanded to allow for an arbitrary number of variables
> to
>> be
>> used.   For example in addition to the three default variables dither
>> could
>> also be useful here and for some printer drivers there are likely
> other
>> user
>> settings that could be used for profile selection.
>>
>>> Depending upon the solution (embedded, mobile, desktop, office,
>>> production) the creation of ICC profile may or not be practical.
>>> Remember it is not just one ICC profile per printer but because of
> "2."
>>> above it could mean many ICC profiles.
>> Again I think we agree in principle.  In fact printers will almost
> always
>> have
>> more than one profile.  For example Apple typically defines at least
> three
>> profiles for each printer as part of the default installation and this
>> default
>> is intended for users who are not doing color critical work.  As
> another
>> example Epson makes available for download sets of profiles for
> specific
>> printers that contain a large number of profiles that are correct for
> a
>> range
>> of their print media (papers).  As part of the documentation for these
>> profiles they specify what printer settings each profile is valid for
> and
>> for
>> optimal results users must use the specified settings when using these
>> profiles as well as the specific media that the profile was created
> for.
>> In
>> addition, many paper and ink vendors do the same thing for their
> media.
>> So
>> for Windows and Mac users it is possible, at least in some cases, to
>> download
>> dozens of off the self semi-custom profiles for a particular printer
> model
>> but
>> any given user may only need one or two of these.
>>
>>> One solution is to give the "color management" system an ICC profile
>>> which is the sRGB gamut; problem solved.
>> Again it is not that simple since the "color management system" does
> not
>> have
>> a profile but rather is designed to manage transforms between color
> spaces
>> for
>> various devices each with it own (in some cases set of) arbitrary
> color
>> spaces
>> and the documents (again arbitrary) color space(s).
>>
>> On some devices color management using custom profiles does not make
> much
>> sense.  For example on (most?) embedded devices and things like PDAs
> color
>> management is of little use at the system level.  After all why would
> you
>> get
>> too concerned about color managing a display that only has 16
> bits/pixel.
>> So
>> this is probably a non-issue for these types of devices. Most programs
>> that
>> create ICC profiles will either give very strong warnings or refuse to
>> create
>> profiles for devices with less than 24 bits/pixel since the ICC
>> specification
>> does not define transforms for formats with less than 24 bit/pixel
>> resolution.
>> Since we are talking about printing how many embedded devices actually
>> have
>> the printing software stack installed on them?
>>
>> But for most of the other categories you mention it does make sense
>> although I
>> am not sure what "production" is.  The intent should be to have
> something
>> that
>> is flexible enough that it can be configured to work well in all of
> these
>> environments for both casual users (this should be the default setup)
> as
>> well
>> as users doing color critical work (it is OK if this needs to be hand
>> configured).
>>
>>> Changing subject slightly.  I believe the importance of printer ICC
>>> profiles is so that, at least an approximation of, the final printed
>>> document can be viewed on a display by the user and will show the
> final
>>> printed colors.  In this case, then an average/representative ICC
>>> profile for all of the printer modes could be supplied; at least
> this is
>>> a reduction from N to 1.
>> These are two separate things that should not be conflated.  Soft
> proofing
>> does matter and is particularly important to advanced users doing
> color
>> critical work.  But those users are likely to be the ones who are the
> most
>> concerned about having every detail in their color management work
> flow as
>> close to correct as possible.  These users are likely to have monitors
>> that
>> are calibrated and profiled using a hardware measurement device,
> custom
>> profiled capture devices, specialized print viewing booths,
> specialized
>> controlled lighting in their work room and custom printer profiles
> that
>> they
>> have either produced themselves (again using hardware measurement
> devices)
>> or
>> had a profiling service create.   They will almost never be using
> canned
>> profiles for any of their devices and will likely have more profiles
>> installed
>> on their system than other (more "normal") users.
>>
>> On the other hand there should be a default profile set that is
> supplied
>> with
>> every printer that is suitable for use "out of the box" by users who
> are
>> not
>> concerned about color reproduction to the point where they will be
>> creating
>> custom profiles (IE. your average "I just want it to work" user).   It
>> should
>> be possible in many cases to start out with these being a set of
> generic
>> RGB,
>> CMYK and Gray profiles that are the default base set of profiles for
> all
>> printers unless the driver authors wish to supply profiles that are
>> specific
>> for their devices*.
>>
>> This is what Apple does for most printer types (have a look at the
>> cupsICCProfile lines in recent PPD files for some examples) where they
>> default
>> to sRGB for users who are using RGB printer mode and generic (I don't
> know
>> where they got these but these are probably under Apple copyright)
> CMYK
>> and
>> Gray profiles.  But the main point is that there will always be more
> than
>> one
>> profile per printer.   There is no way around this since it is simply
> the
>> nature of the beast.
>>
>> For those interested the ArgyllCMS author has created a set of generic
>> CMYK
>> and Gray profiles that are very similar to the ones that Apple ships
> that
>> can
>> be used in an open way.  Most Linux systems now days will have a sRGB
>> profile
>> already installed or users will have available packages to install it
>> along
>> with some other generic profiles.
>>
>>> Now the reality of creating ICC profiles.  Due to the open source
> nature
>>> of Linux, not all contributing individuals will have the capability
>>> (meaning equipment), time or desire to create ICC profiles for their
>>> instantiation of their driver which needs to take into account "1."
> and
>>> "2." above. This was the reason for suggesting sRGB as expected
> input
>>> color space to driver.
>> The document color space has no relevance to the issue of creating
> printer
>> or
>> other device profiles.  None of the work flows in the color management
>> system
>> should care at all about what the document color space is as long as
> it
>> has
>> one specified.  It simply does not matter and it actually creates more
>> issues
>> than it solves to try to require a specific document color space (I
> can't
>> think of any issue it solves actually).
>>
>> However you are correct about many users not being able to or not
> wanting
>> to
>> create ICC profiles.   This is particularly true for printer profiles
>> where
>> the measurement devices are fairly expensive (they currently start at
>> about
>> $400) and the process is somewhat complex.  But keep in mind that most
> of
>> the
>> measurement devices currently in production are now supported by open
>> source
>> software and work fine on *nix systems so this is not a users can't do
> it
>> because they are using open source kind of thing.  For most users who
> want
>> to
>> do this it boils down to the cost of the hardware and this is true for
>> Windows
>> and Mac users as well.   Also keep in mind that profiling monitors and
>> input
>> devices like scanners and cameras is now fairly inexpensive and there
> is a
>> wide range of *nix supported devices for doing this.  For example the
> X-
>> Rite
>> Huey is supported and can be purchased for less than $50 making
> monitor
>> profiling with in reach of most users.
>>
>> Where Windows and Mac users have an advantage is the printer, paper
> and
>> ink
>> vendors now commonly supply semi-custom profiles for free that provide
>> perhaps
>> 95% of what a user can get with a true custom profile.  On the other
> hand
>> there are profiling services that will create true custom printer
> profiles
>> for
>> a little as $25 and for most ink jet printers these are good for the
> life
>> of
>> the printer as long as the user uses the same media and settings for
> their
>> printing work flow.
>>
>> The real issue is when the document does not have an embedded color
> space
>> and
>> that the app sending the document to an output device has not
> specified
>> one.
>> Since the color management system needs two profiles to create the
>> transform
>> how can this be handled?  The OpenICC recommended way to to assume
> that
>> these
>> untagged documents are sRGB.  But this is only a fall back for when
> the
>> color
>> space is not some how specified.
>>
>> In short it is contrary to accepted color management practice to
> require
>> the
>> use of a specific document color space.
>>
>> * This implies some things about the out of the box calibration of the
>> printers that I will not get into at this time.
>>
>> ** As a side note the gutenprint team is starting to look at
> measurement
>> driven printer calibration/linearization.  Unlike using profiles this
> is
>> something that does directly involve the driver.  It is intended that
> this
>> will be used in conjunction with ICC profiles.  This is currently at
> the
>> very
>> early stages so it will be a while before this starts appearing in
>> anything
>> other than development code.
>>
>>> glen
>>>
>>>> -----Original Message-----
>>>> From: printing-japan-bounces@lists.linux-foundation.org
>>> [mailto:printing-
>>>
>>>> japan-bounces@lists.linux-foundation.org] On Behalf Of Hal V.
> Engel
>>>> Sent: Tuesday, February 03, 2009 5:12 PM
>>>> To: Open Printing; Printing-japan
>>>> Subject: Re: [Printing-japan] [Printing-architecture] Last OP SC -
>>> Mon/Tue
>>>
>>>> -2/3 February 2009 - The Recording
>>>>
>>>> On Tuesday 03 February 2009 02:46:16 pm you wrote:
>>>>> Hal V. Engel wrote:
>>>>>> Till,
>>>>>>
>>>>>> Just listened to the recording.  Thank you for making it
>>> available.
>>>
>>>> There
>>>>
>>>>>> are apparently some misconceptions about how color management
>>> works.
>>>
>>>> So
>>>>
>>>>>> here is some feedback.
>>>>>>
>>>>>> It is not acceptable to use sRGB or any single color space as
> the
>>> only
>>>
>>>>>> acceptable or required document color space.  It appears that
> this
>>> is
>>>
>>>>>> something that comes up every time a new application starts
>>> looking at
>>>
>>>>>> color management.  For example, this same thing was discussed
> at
>>>> length
>>>>
>>>>>> when the GIMP developers started looking at CM and in the end
> they
>>> did
>>>
>>>>>> not use the "required color space" approach since the CM
> experts
>>> told
>>>
>>>>>> them not to (in very strong terms) and when they actually got
> into
>>>> coding
>>>>
>>>>>> it they discovered that is was actually counter productive and
> not
>>>>>> needed.
>>>>>>
>>>>>> User land applications should be able to send documents to the
>>> output
>>>
>>>>>> device (printer, monitor...) in any color space(s) it wants to
>>> use.
>>>
>>>> In
>>>>
>>>>>> fact it is common for those doing color critical work to avoid
>>> sRGB
>>>
>>>> since
>>>>
>>>>>> it has a very limited gamut and it is common for devices like
>>> scanners
>>>
>>>>>> and cameras to have much larger gamuts (in many cases almost
> twice
>>> as
>>>
>>>>>> big).   So friends do not let friends use sRGB.  Keep in mind
> that
>>>> this
>>>>
>>>>>> is the document color space and it needs to have enough gamut
> for
>>> the
>>>
>>>>>> device that created the document and it's gamut has nothing to
> do
>>> with
>>>
>>>>>> the printers characteristics.
>>>>>>
>>>>>> The correct approach is allow the user land app to specify any
>>>> document
>>>>
>>>>>> color space (actually compound documents like pdf can have
> more
>>> than
>>>
>>>> one
>>>>
>>>>>> color space since pdf allows for each individual object in the
>>>> document
>>>>
>>>>>> to have it's own color space).  In fact there is no other
>>> reasonable
>>>
>>>>>> approach.  In addition it is typical for documents to have the
>>>> document
>>>>
>>>>>> color space(s) embedded in the document and since the document
> is
>>>> passed
>>>>
>>>>>> to the printing subsystem the document color space(s) are
>>> discoverable
>>>
>>>> by
>>>>
>>>>>> the *toraster filter.
>>>>>>
>>>>>> The consensus from discussions on the OpenICC list is that the
>>> only
>>>
>>>> time
>>>>
>>>>>> sRGB is used by default is when the user land application does
> not
>>>>>> explicitly pass a document color space(s) and any document or,
> for
>>>>>> compound documents, any object in the document that has an
>>> embedded
>>>
>>>> ICC
>>>>
>>>>>> profile has passed an explicit color space that must be used.
> In
>>> fact
>>>
>>>> if
>>>>
>>>>>> the printing work flow is correctly designed there is no need
> to
>>> limit
>>>
>>>>>> what document color space(s) are used as this will be handled
> by
>>> the
>>>
>>>>>> color management engine when the *toraster filter sets up the
>>> color
>>>
>>>>>> transforms that it needs for the document it is handling.
>>>>>>
>>>>>> On the "OS level" you do NOT need agreement on what color
> space
>>> will
>>>
>>>> be
>>>>
>>>>>> used but rather what needs to be agreed to is how the
>>> transformations
>>>
>>>>>> from the document color space(s) to the output device color
> spaces
>>>> will
>>>>
>>>>>> be handled. There is work underway on this end of things by
> the
>>>> OpenICC
>>>>
>>>>>> folks. Specifically Oyranos which is a system wide CM
>>> configuration
>>>
>>>>>> management back end that is being worked on my Kai-Uwe
> Behrmann
>>> and
>>>
>>>> for
>>>>
>>>>>> KDE the Kolor Manager System Setting applet which is a KDE4
>>> specific
>>>
>>>>>> Oyranos front end that is now in the playground area of the
> KDE
>>> svn
>>>
>>>>>> repository.  We hope to have Kolor Manager included in KDE
> 4.3.
>>>>>> Currently Oyranos has no support for CM configuration of
> printers
>>> (the
>>>
>>>>>> only devices that currently have full support are monitors)
> and
>>> this
>>>
>>>> is
>>>>
>>>>>> an area that needs to be addressed along with scanners and
>>> cameras.
>>>
>>>> The
>>>>
>>>>>> KDE front end was written as part of GSoC 2008 and there were
>>> lengthly
>>>
>>>>>> discussions during that effort about how all these other
> devices
>>>> should
>>>>
>>>>>> be supported.  In particular printers generated lots of
> interest
>>> and
>>>
>>>>>> there is some preliminary code in Kolor Manager related to
> printer
>>> CM
>>>
>>>>>> configuration along with similar code for scanners.  Our hope
> is
>>> to
>>>
>>>>>> introduce printer support into Oyranos and Kolor Manager as
> the CM
>>>> parts
>>>>
>>>>>> of the printing work flow are being developed.
>>>>>>
>>>>>> Rendering intent in the color management context has a limited
>>> number
>>>
>>>> of
>>>>
>>>>>> options most of these are defined by the ICC and are to some
>>> extent
>>>
>>>>>> standardized.  These are absolute colorimetric (no white point
>>>>>> transformation), relative colorimetric (this causes a white
> point
>>>>>> transformation), perceptual and saturation intent.  For
> relative
>>>>>> colormetric intent users can also select black point
> compensation
>>> to
>>>
>>>> help
>>>>
>>>>>> reduce the loss of shadow details when the transform is going
> to a
>>>> device
>>>>
>>>>>> with reduced gamut compared to the document color space.  So
> there
>>> are
>>>
>>>>>> actually 5 rendering intents and all of these are supported by
>>> LCMS.
>>>
>>>> So
>>>>
>>>>>> all that actually needs to happen is that users can select the
>>> intent
>>>
>>>> and
>>>>
>>>>>> this gets passed through to the *toraster filter so the the
>>> transform
>>>
>>>>>> uses the correct intent when it creates the raster that is
> passed
>>> to
>>>
>>>> the
>>>>
>>>>>> printer.   At present most document formats do not have a
>>> standardized
>>>
>>>>>> way of embedding this information.
>>>>>>
>>>>>> There is a need for user land applications to be able to
> discover
>>> the
>>>
>>>>>> printer color space(s) (IE. profiles) so that applications can
> do
>>> soft
>>>
>>>>>> proofing.
>>>>>>
>>>>>> RAW is NOT a color space as that term is used in the color
>>> management
>>>
>>>>>> world.
>>>>>>
>>>>>> Hal
>>>>> Thank you for your mail. You have sent it to me in private, but
> I
>>> prefer
>>>
>>>>> to discuss it on the printing-architecture mailing list, could
> we
>>> post
>>>
>>>>> your mail there to start the discussion?
>>>> Yes I can do that.  I was not too sure where I should send it so I
>>> kept it
>>>
>>>> private.
>>>>
>>>>> So good to hear that the color correction
>>>> Color Management types would say "color space transform" rather
> than
>>>> "color
>>>> correction" because this could also be doing things like taking an
> RGB
>>> (or
>>>
>>>> XYZ
>>>> or Lab) document and converting it into CMYK or even deviceN
> output
>>> for
>>>
>>>> the
>>>> printer.
>>>>
>>>>> can be done completely on the
>>>>> server side.
>>>> Doing the transform on the server would be the preferred way to
> handle
>>>> this.
>>>> Right now we are limited to doing this client side in the user
> land
>>> apps
>>>
>>>> that
>>>> are sending output to the print server.  This means we only have
> color
>>>> managed
>>>> printing in those apps that know how to do color managed printing
>>> which
>>>
>>>> right
>>>> now is a very limited set of apps (probably less then a dozen
> total
>>> but I
>>>
>>>> can
>>>> only think of three off hand and one of those is a specialized
> front
>>> end
>>>
>>>> for
>>>> gutenprint).  Having this functionality on the server side means
> that
>>> even
>>>
>>>> CM
>>>> dumb apps benefit once things are properly configured.
>>>>
>>>>> A color-managed driver will then use an ICC profile in a
>>>>> standardized directory on the server and functions of a CM
> library
>>> to
>>>
>>>>> execute the color correction.  The PPD will have a "Rendering
>>> Intent"
>>>
>>>>> option with the choices mentioned in your mail, option and
> choices
>>> with
>>>
>>>>> standardized names for all printers. Option settings are passed
> to
>>> CUPS
>>>
>>>>> as IPP attributes and this way also the rendering intent gets to
> the
>>>>> driver. The driver will get all option settings by its command
> line.
>>>>> Perhaps color correction has too be better done by the renderer
>>>>> (Ghostscript or Poppler, Ghostscript preferred), as a raster
> image
>>> can
>>>
>>>>> have only one color space where as vector graphics, especially
> in
>>> PDF
>>>
>>>>> format, can have a separate color space for each object.
>>>> I think this assessment is correct.  In fact having this happen in
> the
>>>> *toraster rendering filter makes things much simpler for everyone
>>> since
>>>
>>>> doing
>>>> this would eliminate the need to do any color management specific
>>>> modifications to the individual drivers and it would also
> centralize
>>> this
>>>
>>>> functionality in one place.  For example once GhostScript has been
>>> updated
>>>
>>>> to
>>>> have an up to date CM implementation (I think we should have at
> least
>>>> development versions with this capability soon) and the new
>>> pdftoraster
>>>
>>>> filter
>>>> is setup to handle CM the new pdf based printing work flow will
> have
>>>> functional CM for all apps using it, including apps that are not
> CM
>>> aware,
>>>
>>>> no
>>>> matter what printer/driver is being used.
>>>>
>>>> As a side note Poppler has now been patched with preliminary CM
>>>> functionality
>>>> and the testing I did with it seemed to work OK.  So it might make
>>> sense
>>>
>>>> to
>>>> continue to use Poppler for the common printing dialog since it's
> CM
>>>> support
>>>> might be "good enough" for this use.
>>>>
>>>>> The ICC profile of each print queue also needs to be
> downloadable by
>>> the
>>>
>>>>> clients via CUPS' http server facility, so that apps (or the
> Common
>>>>> Printing Dialog) can get them for soft proofing.
>>>> Currently the CUPS API allows client side apps to get a list of
>>> profiles
>>>
>>>> that
>>>> are in cupsICCProfile lines in the PPD.  But there were several
> open
>>>> issues
>>>> with the CUPS implementation the last time I checked.
>>>>
>>>> 1. If the CUPS server is not local there is no way to get the
> profile
>>> for
>>>
>>>> soft
>>>> proofing.
>>>>
>>>> 2. CUPS only allows passing a user specified printer profile on
> the
>>>> command
>>>> line if the profile is installed in a specific directory on the
> CUPS
>>>> server
>>>> and there is no way in the general case for a client app to get a
> list
>>> of
>>>
>>>> these profiles or to get a copy of any of these profiles.
>>>>
>>>>>     Till
>>>>>
>>>>>
>>>>> P. S.: Thank you for registering for the OpenPrinting Summit.
> You
>>> are
>>>
>>>>> welcome to attend and I am looking forward for the Color
> Management
>>>>> session.
>>>> That is why I registered.  I live with in commuting distance of
> the
>>>> conference
>>>> which makes it fairly easy for me to attend.  So I guess that I
> will
>>> be
>>>
>>>> the
>>>> OpenICC representative there and perhaps there will be others as
> well.
>>>>> From the CM side not only you but also Michael	Vrhel
>>>>> (Ghostscript) is attending.
>>>> _______________________________________________
>>>> Printing-japan mailing list
>>>> Printing-japan@lists.linux-foundation.org
>>>> https://lists.linux-foundation.org/mailman/listinfo/printing-japan
> 
> _______________________________________________
> Printing-japan mailing list
> Printing-japan@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/printing-japan
>