Gutenprint, Mac OS X, R1800 and Color Matching tab

[Aleksandar Milivojevic]

When using Gutenprint driver on Mac OS X, there are two places where
color control options show up for R1800 (and probably other printers).

The first is under "Color Matching".  It shows two options,
"ColorSync" and "Vendor Matching".  The later is always grayed out.

The second is under "Printer Features", "Feature Set: Output Control
Extra 1 3", which offers "Color Correction".

>From my limited understanding how things work, these might be
problematic.  It seems to me that "Color Matching" should really have
three selectable option (currently it effectively only has one,
forcing use of ColorSync).  Those should be:

1) ColorSync: let ColorSync manage colors
2) Vendor: let driver (Gutenprint) manage color
3) No Color Matching: let application manage color

The "Color Correction" under Printer Features should be available (or
has effect) only if Color Matching is set to Vendor.  Or if it is
easier to do it the other way around, Color Matching should have
non-Vendor options selectable only if Color Correction is set to
Uncorrected.

An example of usage would be when creating color profile for the
printer.  For printing calibration patter, both Color Matching and
Color Correction should be turned off.  Currently it is possible to
disable Color Correction (by setting to Uncorrected), but Color
Matching is always forced to ColorSync.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Gimp-print-devel mailing list
Gimp-print-devel@...
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

[Michael R Sweet]

Aleksandar Milivojevic wrote:
> When using Gutenprint driver on Mac OS X, there are two places where
> color control options show up for R1800 (and probably other printers).
 > ...
> The first is under "Color Matching".  It shows two options,
> "ColorSync" and "Vendor Matching".  The later is always grayed out.

Right, we currently only advertise that we use sRGB or Generic CMYK
as the input colorspaces.  This is a compromise to ensure that we
get a consistent colorspace from applications, since the vendor
color matching path is limited to one of three RGB colorspaces...

> The second is under "Printer Features", "Feature Set: Output Control
> Extra 1 3", which offers "Color Correction".
>
>>From my limited understanding how things work, these might be
> problematic.  It seems to me that "Color Matching" should really have
> three selectable option (currently it effectively only has one,
> forcing use of ColorSync).  Those should be:
>
> 1) ColorSync: let ColorSync manage colors
> 2) Vendor: let driver (Gutenprint) manage color
> 3) No Color Matching: let application manage color
>
> The "Color Correction" under Printer Features should be available (or
> has effect) only if Color Matching is set to Vendor.  Or if it is
> easier to do it the other way around, Color Matching should have
> non-Vendor options selectable only if Color Correction is set to
> Uncorrected.
>
> An example of usage would be when creating color profile for the
> printer.  For printing calibration patter, both Color Matching and
> Color Correction should be turned off.  Currently it is possible to
> disable Color Correction (by setting to Uncorrected), but Color
> Matching is always forced to ColorSync.

Disabling the Gutenprint color controls will require a PDE, since
currently all of the options are managed by the generic "printer
features" PDE.  I am working on this, but it will *not* be part of
Gutenprint 5.2.  At the same time we can advertise the vendor
color matching mode in the PPD files, but keep in mind that for
Mac OS X vendor color matching is limited to the RGB color path.

That said, in Mac OS X the correct thing to do is register the color
profile you are using via the ColorSync Utility, which allows you to
select it in the Color Matching pane - then Gutenprint gets raster
data matched to your profile.

--
______________________________________________________________________
Michael R Sweet                        Senior Printing System Engineer

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Gimp-print-devel mailing list
Gimp-print-devel@...
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

[Aleksandar Milivojevic]

On Mon, Jul 21, 2008 at 10:24 AM, Michael R Sweet <msweet@...> wrote:

> Aleksandar Milivojevic wrote:
>>
>> When using Gutenprint driver on Mac OS X, there are two places where
>> color control options show up for R1800 (and probably other printers).
>
>> ...
>>
>> The first is under "Color Matching".  It shows two options,
>> "ColorSync" and "Vendor Matching".  The later is always grayed out.
>
> Right, we currently only advertise that we use sRGB or Generic CMYK
> as the input colorspaces.  This is a compromise to ensure that we
> get a consistent colorspace from applications, since the vendor
> color matching path is limited to one of three RGB colorspaces...
>
>> The second is under "Printer Features", "Feature Set: Output Control
>> Extra 1 3", which offers "Color Correction".
>>
>>> From my limited understanding how things work, these might be
>>
>> problematic.  It seems to me that "Color Matching" should really have
>> three selectable option (currently it effectively only has one,
>> forcing use of ColorSync).  Those should be:
>>
>> 1) ColorSync: let ColorSync manage colors
>> 2) Vendor: let driver (Gutenprint) manage color
>> 3) No Color Matching: let application manage color
>>
>> The "Color Correction" under Printer Features should be available (or
>> has effect) only if Color Matching is set to Vendor.  Or if it is
>> easier to do it the other way around, Color Matching should have
>> non-Vendor options selectable only if Color Correction is set to
>> Uncorrected.
>>
>> An example of usage would be when creating color profile for the
>> printer.  For printing calibration patter, both Color Matching and
>> Color Correction should be turned off.  Currently it is possible to
>> disable Color Correction (by setting to Uncorrected), but Color
>> Matching is always forced to ColorSync.
>
> Disabling the Gutenprint color controls will require a PDE, since
> currently all of the options are managed by the generic "printer
> features" PDE.  I am working on this, but it will *not* be part of
> Gutenprint 5.2.  At the same time we can advertise the vendor
> color matching mode in the PPD files, but keep in mind that for
> Mac OS X vendor color matching is limited to the RGB color path.
>
> That said, in Mac OS X the correct thing to do is register the color
> profile you are using via the ColorSync Utility, which allows you to
> select it in the Color Matching pane - then Gutenprint gets raster
> data matched to your profile.

Thanks for quick response.

Is there a way to prevent the printing system from touching the colors
(do any kind of color correction) when using Gutenprint driver?  The
way I read your response, it doesn't seem there is.

The applications I'm using (Photoshop and Aperture) will handle
colors, and will send already color corrected image when printing to
the printer (corrected for specific model of printer and type of paper
and ink).  If anything touches those colors (ColorSync or Gutenprint
driver), the colors will be ruined.

I could tell Photoshop and Aperture to leave color management to the
driver (which would produce suboptimal workflow and results).  However
this won't really work.  Because there is still problem how to create
ICC profile for the printer.

In order to create color profile for the printer, I need a way to
disable ColorSync (or any other color correction in the driver or
other parts of printing system) when printing calibration pattern.  My
spectrophotometer would be measuring the response of both the printer
and whatever profile ColorSync used.  Instead of just measuring the
response of the printer.  If I can't disable ColorSync in print
dialog, then I can't create a profile to be used by ColorSync.  Kind
of circular dependency.

Third possibility would be to select some generic color profile in
ColorSync, calibrate with it, and than let applications manage color.
This is very very suboptimal (the color profiles will be applied
twice, with custom generated profile correcting both the errors of
printer and generic profile).  Xrite tech support (manufacturer of my
spectrophotometer) strongly advised against this approach.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Gimp-print-devel mailing list
Gimp-print-devel@...
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

[Michael R Sweet]

Aleksandar Milivojevic wrote:
> ...
> Is there a way to prevent the printing system from touching the colors
> (do any kind of color correction) when using Gutenprint driver?  The
> way I read your response, it doesn't seem there is.

Basically, if you are printing in grayscale or RGB mode, make sure
that the working color space in your app is assigned to sRGB.  For
CMYK printing, use the system-supplied Generic CMYK profile.

If the source and destination color profiles match, then the system
does not alter the color values (identity transform).  This "trick"
also works for drivers that provide device-specific profiles, it just
is harder because there are more profiles to choose from...

--
______________________________________________________________________
Michael R Sweet                        Senior Printing System Engineer

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Gimp-print-devel mailing list
Gimp-print-devel@...
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

[Robert Krawitz-2]

   Date: Mon, 21 Jul 2008 11:04:56 -0700
   From: "Aleksandar Milivojevic" <alex@...>

   On Mon, Jul 21, 2008 at 10:24 AM, Michael R Sweet <msweet@...> wrote:
   > Aleksandar Milivojevic wrote:

   Thanks for quick response.

   Is there a way to prevent the printing system from touching the
   colors (do any kind of color correction) when using Gutenprint
   driver?  The way I read your response, it doesn't seem there is.

   The applications I'm using (Photoshop and Aperture) will handle
   colors, and will send already color corrected image when printing
   to the printer (corrected for specific model of printer and type of
   paper and ink).  If anything touches those colors (ColorSync or
   Gutenprint driver), the colors will be ruined.

So here's the really long answer to this, from the Gutenprint
standpoint:

There's an unequivocal yes answer, and several other yes answers with
varying degrees of equivocation, but I suspect that none of them are
what you want.

Inkjet printers, by their very nature, are not 8 or 16 bit monotonic
RGB devices.  They're 1 or 2 bit devices in what's at best a highly
nonlinear (and probably non-monotonic) inverse RGB color space.  Since
most inkjets aren't CMY devices (CMYK, CcMmYK, or even stranger
spaces), they're really DeviceN, and the Stylus Photo R1800 is one of
the worst in this regard (CMYKR"B", which is really purple).  So you
first face the problem of collapsing 8 or 16 bits down into 1 or 2
bits in an entirely foreign color space that's non-uniform, highly
non-linear, probably non-monotonic, non-orthogonal, and interacting
(mixtures of inks may not have the same response as the individual
inks).  The driver is going to do this in (almost) any event, so it's
performing a non-idempotent color transform in any case, which you
could interpret as being a "correction".

Gutenprint *does* offer a way to send true 1 or 2 bit DeviceN data to
the printer, which I can tell you about if you really, really want to
know, but I don't think you do (it's called raw input with Predithered
color "correction" -- basically low bit sampling).  That's the
unequivocal "yes" answer; in this case, the driver simply performs
weaving, generation of printer control codes, and ships it all off.
It offers additional options short of that:

2) 8 or 16 bit DeviceN input color space, which the driver dithers
   down to 1 or 2 bits with only ink drop size adjustment on variable
   ink drop size printers (this is called raw input with Raw color
   correction).

3) 8 or 16 bit RGB or CMYK input color space, which the driver
   converts to DeviceN color space with no linearization or density
   correction (called Raw color correction).  This provides reasonably
   complete results on printers without really exotic inks, but the
   R1800 is one of those printers with really exotic inks.

4) 8 or 16 bit RGB or CMYK input color space, which is converted to
   DeviceN with density correction but no linearization curves applied
   (called Density color correction).  This or Raw color correction
   are good choices for people who want to do their own linearization
   and ink limiting.

5) 8 or 16 bit RGB or CMYK input color color space, which is converted
   to DeviceN with density correction and linearization curves applied
   (however good or bad they may be), which is called Uncorrected
   color correction.  This is normally what we recommend people use
   with profiling.

Then there are various degrees of correction in HSL space: hue only,
adjustment offering brighter colors, and full adjustment.

The upshot of all this is that if you want to provide anything other
than DeviceN input, the driver *is* going to do something with your
input, and there's no way around it.  That's the nature of such a
device.

What I suspect you *really* mean is that you want the driver to
provide the same channel response as the Epson-supplied driver, which
we don't offer and have no plans to ever offer.  This would be a huge
job and wouldn't let us take advantage of any improvements that we
care to make.

BTW, it's not just the choice of paper and ink -- it's also choice of
resolution.

   I could tell Photoshop and Aperture to leave color management to
   the driver (which would produce suboptimal workflow and results).
   However this won't really work.  Because there is still problem how
   to create ICC profile for the printer.

As I explained above, you can't create an ICC profile for the
printer.  You need to create a profile for the combination of printer
and driver, because the printer's color space is so radically
different.  Monitors and scanners really do deal with hardware (or at
least firmware) RGB in reasonable bit depths, but inkjet printers
don't (dye sublimation printers do).

   In order to create color profile for the printer, I need a way to
   disable ColorSync (or any other color correction in the driver or
   other parts of printing system) when printing calibration pattern.
   My spectrophotometer would be measuring the response of both the
   printer and whatever profile ColorSync used.  Instead of just
   measuring the response of the printer.  If I can't disable
   ColorSync in print dialog, then I can't create a profile to be used
   by ColorSync.  Kind of circular dependency.

I agree that you need to be able to disable ColorSync for this, but
for the driver, you just need to select a reasonable choice of color
correction (Uncorrected, Density, or Raw depending upon just how fussy
you want to be with linearization and ink limiting) and stick with it.

   Third possibility would be to select some generic color profile in
   ColorSync, calibrate with it, and than let applications manage
   color.  This is very very suboptimal (the color profiles will be
   applied twice, with custom generated profile correcting both the
   errors of printer and generic profile).  Xrite tech support
   (manufacturer of my spectrophotometer) strongly advised against
   this approach.

Mike, perhaps ColorSync could offer an idempotent profile for just
this purpose?

--
Robert Krawitz                                     <rlk@...>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf@...
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Gimp-print-devel mailing list
Gimp-print-devel@...
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

[Michael R Sweet]

Robert Krawitz wrote:

> ...
>    Third possibility would be to select some generic color profile in
>    ColorSync, calibrate with it, and than let applications manage
>    color.  This is very very suboptimal (the color profiles will be
>    applied twice, with custom generated profile correcting both the
>    errors of printer and generic profile).  Xrite tech support
>    (manufacturer of my spectrophotometer) strongly advised against
>    this approach.
>
> Mike, perhaps ColorSync could offer an idempotent profile for just
> this purpose?

This is essentially what we have done by using the sRGB and Generic
CMYK profiles in the PPD file (the cupsICCProfile stuff...)  As I
mentioned in a previous response, all you need to do in the
application is use sRGB or Generic CMYK - trivial in any of the Adobe
apps.

--
______________________________________________________________________
Michael R Sweet                        Senior Printing System Engineer

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Gimp-print-devel mailing list
Gimp-print-devel@...
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

[Aleksandar Milivojevic]

Hi Robert,

Thanks again for very detailed response.

What I had in mind was actually using Uncorrected.  I don't thin
Photoshop is able to generate something that directly controls firing
of nozzles on inkjet printer :-)

My concern was really that I am not able to remove ColorSync from
equation when using Gutenprint driver.  With most other drivers (Epson
included), I usually have option on Color Matching page to either use
ColorSync, some kind of driver specific conversion (in Epson's case
there's choice of Standard, Vivid and Adobe, this is highly driver
dependent, but again I'm definitely not asking to emulate this aspect
of Epson driver), and finally no color matching at all.  It is this
last option that I'm really interested in seeing on Color Matching
page when using Gutenprint driver.  The only thing it does is to
disable ColorSync.  No more, no less.

As for Michael's suggestion, I have one "small" problem.  The device
I'm using (X-Rite ColorMunki, it's a consumer-level spectrophotometer,
well, consumer level in the sense it doesn't cost $1k) requires use of
it's own application, which prints color patterns directly to the
printer.  It first prints 50 color patches, measures them, and than
calculates another set of 50 patches for colors it deemed were most
problematic.  While the first set of 50 patches is fixed, the second
set is different for each calibration.  Although it uses only 100
color patches, it does surprisingly good job because second set of 50
patches is optimized for the printer.  Nowhere in the process I have
access to the image file with color patches I could load into
Photoshop, convert to some color profile (sRGB, Adobe, or whatever)
and than print it using the same profile for ColorSync.  It's all in
the black box called ColorMunki Photo App.  I could ask X-Rite tech
support what color profile is assigned to the print job their
application generates (hopefully it's Adobe, or failing that sRGB).
But I'm afraid that's it.  If they are not willing to disclose that
information, I'll be stuck.

Again, I'm not asking to emulate color response of Epson's driver.  I
don't really need that, since I have my own spectrophotometer, and I
can create my own profiles.

On Mon, Jul 21, 2008 at 5:40 PM, Robert Krawitz <rlk@...> wrote:

>   Date: Mon, 21 Jul 2008 11:04:56 -0700
>   From: "Aleksandar Milivojevic" <alex@...>
>
>   On Mon, Jul 21, 2008 at 10:24 AM, Michael R Sweet <msweet@...> wrote:
>   > Aleksandar Milivojevic wrote:
>
>   Thanks for quick response.
>
>   Is there a way to prevent the printing system from touching the
>   colors (do any kind of color correction) when using Gutenprint
>   driver?  The way I read your response, it doesn't seem there is.
>
>   The applications I'm using (Photoshop and Aperture) will handle
>   colors, and will send already color corrected image when printing
>   to the printer (corrected for specific model of printer and type of
>   paper and ink).  If anything touches those colors (ColorSync or
>   Gutenprint driver), the colors will be ruined.
>
> So here's the really long answer to this, from the Gutenprint
> standpoint:
>
> There's an unequivocal yes answer, and several other yes answers with
> varying degrees of equivocation, but I suspect that none of them are
> what you want.
>
> Inkjet printers, by their very nature, are not 8 or 16 bit monotonic
> RGB devices.  They're 1 or 2 bit devices in what's at best a highly
> nonlinear (and probably non-monotonic) inverse RGB color space.  Since
> most inkjets aren't CMY devices (CMYK, CcMmYK, or even stranger
> spaces), they're really DeviceN, and the Stylus Photo R1800 is one of
> the worst in this regard (CMYKR"B", which is really purple).  So you
> first face the problem of collapsing 8 or 16 bits down into 1 or 2
> bits in an entirely foreign color space that's non-uniform, highly
> non-linear, probably non-monotonic, non-orthogonal, and interacting
> (mixtures of inks may not have the same response as the individual
> inks).  The driver is going to do this in (almost) any event, so it's
> performing a non-idempotent color transform in any case, which you
> could interpret as being a "correction".
>
> Gutenprint *does* offer a way to send true 1 or 2 bit DeviceN data to
> the printer, which I can tell you about if you really, really want to
> know, but I don't think you do (it's called raw input with Predithered
> color "correction" -- basically low bit sampling).  That's the
> unequivocal "yes" answer; in this case, the driver simply performs
> weaving, generation of printer control codes, and ships it all off.
> It offers additional options short of that:
>
> 2) 8 or 16 bit DeviceN input color space, which the driver dithers
>   down to 1 or 2 bits with only ink drop size adjustment on variable
>   ink drop size printers (this is called raw input with Raw color
>   correction).
>
> 3) 8 or 16 bit RGB or CMYK input color space, which the driver
>   converts to DeviceN color space with no linearization or density
>   correction (called Raw color correction).  This provides reasonably
>   complete results on printers without really exotic inks, but the
>   R1800 is one of those printers with really exotic inks.
>
> 4) 8 or 16 bit RGB or CMYK input color space, which is converted to
>   DeviceN with density correction but no linearization curves applied
>   (called Density color correction).  This or Raw color correction
>   are good choices for people who want to do their own linearization
>   and ink limiting.
>
> 5) 8 or 16 bit RGB or CMYK input color color space, which is converted
>   to DeviceN with density correction and linearization curves applied
>   (however good or bad they may be), which is called Uncorrected
>   color correction.  This is normally what we recommend people use
>   with profiling.
>
> Then there are various degrees of correction in HSL space: hue only,
> adjustment offering brighter colors, and full adjustment.
>
> The upshot of all this is that if you want to provide anything other
> than DeviceN input, the driver *is* going to do something with your
> input, and there's no way around it.  That's the nature of such a
> device.
>
> What I suspect you *really* mean is that you want the driver to
> provide the same channel response as the Epson-supplied driver, which
> we don't offer and have no plans to ever offer.  This would be a huge
> job and wouldn't let us take advantage of any improvements that we
> care to make.
>
> BTW, it's not just the choice of paper and ink -- it's also choice of
> resolution.
>
>   I could tell Photoshop and Aperture to leave color management to
>   the driver (which would produce suboptimal workflow and results).
>   However this won't really work.  Because there is still problem how
>   to create ICC profile for the printer.
>
> As I explained above, you can't create an ICC profile for the
> printer.  You need to create a profile for the combination of printer
> and driver, because the printer's color space is so radically
> different.  Monitors and scanners really do deal with hardware (or at
> least firmware) RGB in reasonable bit depths, but inkjet printers
> don't (dye sublimation printers do).
>
>   In order to create color profile for the printer, I need a way to
>   disable ColorSync (or any other color correction in the driver or
>   other parts of printing system) when printing calibration pattern.
>   My spectrophotometer would be measuring the response of both the
>   printer and whatever profile ColorSync used.  Instead of just
>   measuring the response of the printer.  If I can't disable
>   ColorSync in print dialog, then I can't create a profile to be used
>   by ColorSync.  Kind of circular dependency.
>
> I agree that you need to be able to disable ColorSync for this, but
> for the driver, you just need to select a reasonable choice of color
> correction (Uncorrected, Density, or Raw depending upon just how fussy
> you want to be with linearization and ink limiting) and stick with it.
>
>   Third possibility would be to select some generic color profile in
>   ColorSync, calibrate with it, and than let applications manage
>   color.  This is very very suboptimal (the color profiles will be
>   applied twice, with custom generated profile correcting both the
>   errors of printer and generic profile).  Xrite tech support
>   (manufacturer of my spectrophotometer) strongly advised against
>   this approach.
>
> Mike, perhaps ColorSync could offer an idempotent profile for just
> this purpose?
>
> --
> Robert Krawitz                                     <rlk@...>
>
> Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
> Member of the League for Programming Freedom -- mail lpf@...
> Project lead for Gutenprint   --    http://gimp-print.sourceforge.net
>
> "Linux doesn't dictate how I work, I dictate how Linux works."
> --Eric Crampton
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Gimp-print-devel mailing list
Gimp-print-devel@...
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel