[Image-SIG] Convert to CMYK

[Gary Speer]

Hi Hans -
See below
----- Original Message -----
From: "Hans Svedåker" <hans.svedaker@bytbil.com>
To: "Gary Speer" <gspeer@cortech.org>
Sent: Tuesday, July 09, 2002 12:38 AM
Subject: Re: [Image-SIG] Convert to CMYK


> Hi Gary
>
> I use the PIL library to prepare the images for priting (inserted in a
> template for printing). Not to view them on screen (server based). And I
> have a "optimized" ICC profile that I uses. But why should PIL have the
> option to convert to CMYK if it isn't worth using. Are there other
> applications then printing that uses CMYK colorspace?

I would guess the reasons they built the CMYK converter was
to have technical Completeness - to have a full set of any-to-any converters
just in case it was needed.

Coding RGB to CMY is a straight forward application of technical formulas
and doesn't require knowing ICC standards or any discretion.  There is a
single 'right' answer to the conversion.  PIL does this conversion
correctly, it just may not be of value to you.  In essence it is the same as
converting in photoshop with GCR=0.

Coding RGB to CMYK is a bit of an art as the amount of GCR to use is
variable depending on the specific application and print process.  Coding in
one (which one, 18%, 20%) or several GCR curves, or even a single curve with
a total ink limit of 280 (or 240 or 300?) is a lot more work and the
result/effect is simply not viewable in a browser.  Replacing as much CM&Y
as you can with the equivalent black(gray) is far worse than replacing none.
The 'right answer' is different for every image, printer, paper, and
artist's eye.  Too many aesthetic variables for a mere technical converter
with no means of displaying the result..

Perhaps the licensed-for-fee version of PIL has GCR curves where the free
version does not.  Still, this is the domain of print applications, not web
applications, so there is little value to complicate PIL with what I expect
would be a limited use feature.  Just use littlecms.

Other uses of CMYK -
Image manipulation to enhance contrast (cyan channel), correct skin tones by
the numbers, or emphasize a spot color (all Photoshop stuff) for print.

Undo-able on-screen special effects achievable in the CMYK colorspace in
which the image occupies the CMY layers and the K layer is totally available
to render over-image text or watermarks that can be stripped out later by
discarding the black channel without affecting the underlying image.

Example - free v. pay websites for actor/actress photos or a photographer's
site.
On import of an RGB photo, use PIL to convert to CMY (with transparent K),
use PIL to render the watermark-style site logo across the image in only the
K channel.  Place the image in the database.  On 'free tours' convert to RGB
to permanently embed the watermark and display the altered image.  For
thumbnails and logged in / paid viewers, pass the image through a PIL filter
to strip the K channel before converting back to RGB and display a clean
image.  One image, one file, a completely removeable mark, simplified
administration.

Again, if the goal is to print-optimize what you see on the screen, stay in
RGB and let the print process apply the optimized ICC profile and preferred
GCR of your printer or use littlecms if you are doing straight to plate
separations.  None of the advantages of working in the CMYK colorspace as
opposed to the RGB colorspace are available until you create an on-line
equivalent of Photoshop that would let you select and manage the GCR curve,
selectively edit/enhance by channel, and use the printer-specific ICC
profile and/or give the user iterative access to the printer's output that
they are optizing for.

PIL was designed for on-line images in web pages.  Its a lot to ask for to
have PIL accomodate the many more variables associated with print
optimization (plug-ins like littlecms, uploading and selecting ICC profiles,
knowing if it is rendering to screen (unconverted profile) as opposed to
print (converted profile) since the target is always a browser, tweaking the
GCR and UCR curves, the results of which can only be viewed on a printer and
vary printer-to-printer.  In essence, concerning PIL is designed for
multiple users, what is displayed through a browser should be ICC neutral so
anyone can view it, use it, print it using the profile of their printer.
The ICC neutral version of an image that starts out as RGB is to stay RGB.
The moment you decide how the K channel is to be rendered by converting to
the same CMYK version for everyone and without any special reason to (like
to generically modify the K channel content to have a watermark) you make it
so that someone going to print the image using their printer's wider profile
(say, using a lighter GCR than you specified) must convert the image back to
RGB in order to convert to CMYK again with a different GCR value.  In short,
the process you describe should not be distributed on the web for everyone
to manage differently when they cannot see the effect on the actual printer,
but should be a single-user process at print time.
>
> Maybe add support för littlecms to PIL? That would help me a lot. No
> need to convert images before, just load any format into PIL and apply
> the ICC profile and save it in CMYK format, ready for print.
Again, the reason you would convert sooner than print-time is because you
plan to manipulate the image in a manner specific to the CMYK color space,
which is hard to do in a browser without an extensive application toolset,
(can you say Java) in which case the CMYK conversion is one of the more
trivial aspects of building one.  This is certainly way beyond the
capabilities of HTML and Javascript.

I just don't think PIL is the right tool to use to get from submitted RGB
images in templates that are uploaded on a server and display well in a
browser, to ICC-optimized plate separations for a newsprinter.

One opinion, for what its worth!
Gary
>
> Gary Speer wrote:
> > Hi -
> > The ICC profile of each specific printer is different and it is the ICC
> > profile of the printer that optimizes GCR as you shift from an ICC
standard
> > colorspace to printer-specific values.  I would understand going through
the
> > effort to doing a PIL conversion if an intranet-style system was being
used
> > to layout newspaper pages that print straight to the newsprinter.  For a
> > webuser that has no visibility to a test print, it does not make sense
to
> > shift away from a non-printer-specific colorspace.  Ideally all images
would
> > come in optimized for how the submitter sees them, in RGB, and enhanced
for
> > printing in general by how they look on the submitter's printer,
converted
> > via that user's ICC profile for his printer.  If the submitter is going
to
> > use a tool that will enhance by channel (eg photoshop), let that tool do
the
> > RGB to CMYK conversion with GCR set by that image professional to get
the
> > result they want.  When they are done, they submit the CMYK result that
will
> > adapt to the newsprint printer via that printer's ICC profile at print
time.
> > To apply a printer profile before print time will distort the onscreen
> > appearance and cause people to try to adjust out the apparent distortion
you
> > would see on screen after an image has been converted to the printer's
color
> > curves.
> >
> > I'm suggesting that users see images in the colorspace they work in -
RGB.
> > If they are going to enhance an image to optimize it for print over how
RGB
> > would translate to CMYK via the newsprinter's ICC profile, then they
either
> > need direct access to the printer's output to see their tweaks (hence
you
> > are no longer in a browser app) or they need to work in a pre-conversion
> > colorspace so the image will adapt to each printer via that printer's
ICC
> > profile.
> >
> > In short, to apply a printer-specific ICC conversion via PIL will
distort
> > the image as viewed on screen after such conversion, and impair the
ability
> > of submitters to optimize the CMYK separation to achieve a desired
effect.
> > If they are not optimizing, again there is no reason to convert to the
> > printer's colorspace until after the RGB-optimized image is inserted
into a
> > printable page and submitted for printing.  At that point a server-based
> > converter like littlecms can do separations according to the ICC profile
of
> > the newsprinter and spool the printjob to that printer.
> >
> > Thank you for sharing the project details.  To embed a printer-specific
ICC
> > conversion in PIL just to avoid using either Littlecms or the printer
driver
> > when the print job is submitted doesn't seem to make sense.  To use it
> > before then, distorts the image as seen in the browser.
> > Regards,
> > Gary
> >
> > ----- Original Message -----
> > From: "Hans Svedåker" <hans.svedaker@bytbil.com>
> > To: "Gary Speer" <gspeer@cortech.org>
> > Sent: Monday, July 08, 2002 12:44 AM
> > Subject: Re: [Image-SIG] Convert to CMYK
> >
> >
> >
> >>Hi
> >>
> >>Gary Speer wrote:
> >>
> >>>Hans & Kevin -
> >>>As a user that does a lot of design for print, it does not make sense
to
> >>
> > me
> >
> >>>to build a complex converter to CMYK.  Just about every printer driver
> >>
> > has
> >
> >>>an optimized CMYK GCR/UCR converter that closely matches the printer's
> >>>characteristics when you send it an RGB print job.  A PIL based generic
> >>>converter to a light (under 20%) GCR will always look worse than the
> >>
> > printer
> >
> >>>driver's formula optimized to the specific printer's characteristics.
> >>
> > If
> >
> >>>the converter matching the printer is not adequate, then no amount of
> >>
> > PIL
> >
> >>>tweaking will come close to adjusting on the client side using
something
> >>>like Photoshop.  There is no real on-screen way to produce a browser
app
> >>>that will display the results of the separation curve since it will
> >>
> > always
> >
> >>>go back to the same RGB values on the browser screen.  Unless I'm
> >>
> > missing
> >
> >>>something, I just don't see the value in converting server-side.
> >>>
> >>>Kevin - I would hate to see you waste time on an optimized converter
> >>
> > without
> >
> >>>a purpose.  All I can think of as a benefit is a method of increasing
> >>>contrast with on-line tools without throwing in a color shift.  If so,
> >>>switch to LAB and expand the luminosity histogram - a much easier and
> >>>reliable method than doing so in RGB or CMYK.  Now, color enhancing
> >>
> > using
> >
> >>>colorspace shifting filter curves - that could be cool!
> >>>
> >>>Hans - If you can expand on the purpose, perhaps we can suggest a
better
> >>>technique.  Otherwise, the RGB version of the JPEG will always look
> >>
> > better
> >
> >>>on your CMYK printer because of the printer-specific optimized driver
is
> >>>doing the grey color replacement optimized to avoid over-inking.and
> >>
> > produce
> >
> >>>even color replacement based largely on the paper selection and its
> >>
> > total
> >
> >>>ink limits.
> >>>Gary
> >>
> >>I use a program called "tifficc" that i found at
> >>"http://www.littlecms.com/" that uses ICC profiles to convert the
> >>picture (www.color.org). If you use an ICC profile in PIL, then i maybe
> >>would be worhth implementing in PIL. The purpose of the software is to
> >>convert pictures so that they are ready for print in a news papper.
> >>
> >>/Hans
> >>
> >>
> >>>----- Original Message -----
> >>>From: "Kevin@Cazabon.com" <kevin@cazabon.com>
> >>>To: "Hans Svedåker" <hans.svedaker@bytbil.com>; "image-sig"
> >>><image-sig@python.org>
> >>>Sent: Friday, July 05, 2002 7:58 PM
> >>>Subject: Re: [Image-SIG] Convert to CMYK
> >>>
> >>>
> >>>
> >>>
> >>>>The built-in RGB/CMYK conversion in PIL is not an optomized one...
> >>>
> > there's
> >
> >>>>no GCR/UCR, it's basically a RGB/CMY flop.
> >>>>
> >>>>Formulas for UCR/GCR are fairly easily available, maybe we should look
> >>>
> > at
> >
> >>>>implementing a tunable conversion method in the core of PIL?  I've
> >>>
> >>>mentioned
> >>>
> >>>
> >>>>this before, I just haven't had the time to do anything myself yet...
> >>>>
> >>>>Kevin.
> >>>>
> >>>>
> >>>>----- Original Message -----
> >>>>From: "Hans Svedåker" <hans.svedaker@bytbil.com>
> >>>>To: "image-sig" <image-sig@python.org>
> >>>>Sent: Thursday, July 04, 2002 1:43 AM
> >>>>Subject: [Image-SIG] Convert to CMYK
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Hi
> >>>>>
> >>>>>I'm trying to convert JPG image to CMYK format. And it works fine,
> >>>>>except for one thing. When there is black (or gray) in the image it
is
> >>>>>converted to (255,255,255,0) instead of (0,0,0,255). There are never
> >>>>
> > any
> >
> >>>>> black in the image, insted i blends max cyan, magenta and yellow to
> >>>>>get black. How shuld i do to get that?
> >>>>>
> >>>>>/Hans Svedåker
> >>>>>
> >>>>>
> >>>>>
> >>>>>_______________________________________________
> >>>>>Image-SIG maillist  -  Image-SIG@python.org
> >>>>>http://mail.python.org/mailman/listinfo/image-sig
> >>>>
>
>