Re: CMYK separations: a correction

From: Katharine Thayer ^lt;[email protected]>
Date: 12/17/04-02:25:12 PM Z
Message-id: <>

Hi Mark,
I must have explained that very badly, because I don't think we're
talking about the same thing. Did you look at the separations? The
problem isn't in the image; the colors in the image don't change. The
problem is in the separations. The problem seems to be that if the file
isn't big enough or within a certain range of resolution/size values,
the separation engine doesn't create accurate separations, but makes
separations that are basically strange and don't have a lot to do with
the actual image. The yellow and magenta separations (I've seen this now
in three images) are much too thin and look almost solarized; they look
very strange, flat and low contrast, with outlines around the edges of
some shapes. And if you print them on gum, you get a really otherwordly
color balance. But if I start with a bigger or less complicated image,
the separations are a more accurate reflection of the CMYK profile.

I disagree about 360 being optimal; the higher the image resolution the
better negatives I get, especially with regard to small test negatives.
Some of my best test negatives were made from 35mm negatives scanned at
actual size at the highest resolution of the film scanner and printed
directly from a file that size and resolution, at 1440 dpi which is the
highest resolution my old printer will print at. These negatives print
gum really great even that small, whereas the same size negative from a
360 ppi file wouldn't work very well at all.
Katharine wrote:
> Katherine,
> I'm curious regarding why image resolution would affect color and
> density of an image.† I understand that image resolution would affect
> detail in an image, with the detail being interpolated up or down, but
> otherwise the rendering of the colors in the separations and relative
> densities should not change.† I'm not talking about RGB vs CMYK, but
> just the CMYK info you mentioned below.
> Are you sure your Photoshop settings and Printer Driver settings were
> identical in all cases?† Order of inversion of seperations in the
> workflow all the same?
> With regards to PPI of the file sent to the printer driver, I've not
> seen evidence that anything other than 360 is optimum.
> I'm not doubting that you saw something different, just baffled that
> it could possibly be resolution causing it‚*”unless the file was so
> tiny and interpolated up so far that so much data was lost that it
> would be impossible to render the image‚*”however if that was the
> case, you would easily see this on the original image on the screen.
> Best Wishes,
> Mark Nelson
> Purchase the eBook & System for Your Own Custom Workflow@
> Precision Digital Negatives
> PDN's Own 31-Step Tablet Now Available‚*”produced by Stouffer
> Industries
> Credit Card & Paypal now accepted
> In a message dated 12/17/04 3:15:10 PM, writes:
> Dear Friends,
> A while back (a month? two months?) I posted CMY separations
> from the
> RGB file  along with default CMYK separations, for an image
> of three
> calla lilies. The CMYK separations made no sense to me; I
> couldn't make
> sense of them in terms of either the original image or the
> image I
> wanted to print.
> I now believe that these separations made no sense not just
> because I'm
> used to looking at RGB separations, as I supposed, but
> because they
> simply made no sense; in fact they were garbage
> separations,  incorrect
> separations that resulted from using a smaller image than
> Photoshop
> could comfortably produce accurate CMYK separations for.  I
> came to this
> conclusion this morning when I decided to re-print all these
> calla
> separations in a bigger size because I didn't think the very
> small
> separations would express the subtle shading in the image
> well when
> printed on gum.  When I printed the separations larger
> (with the same
> identical default CMYK settings as before) the separations
> came out
> looking much more reasonable and sensible; a person could
> actually make
> sense of them. I could even make sense of them.
> I like making test prints with small negatives because I can
> get the
> information I need without expending a lot of time or
> materials. I can
> easily produce small tricolors from small RGB separations
> (like 2x3
> inches) that are reasonably accurate representations of what
> a larger
> print of the same image would look like.  Apprently one
> cannot do the
> same with CMYK separations. I'm not sure where the cutoff is
> for
> accurate separations, but it seems to be somewhat dependent
> first on
> image size, then on resolution, but also on the level of
> detail in the
> image.
> For example, with this calla image, any resolution from 72
> to 1600 gives
> me bad separations if the file is as small as 4 inches. When
> I made
> 6-inch separations from a 720 ppi file, the separations were
> what I have
> come to believe today are the right default separations for
> this file.
> But when I changed the resolution to 360 ppi for the 6-inch
> image, I got
> the wrong separations again. To complicate matters further,
> a 4-inch
> file at 360 ppi printed what looked, and printed, like
> accurate
> separations when the image consisted of five simple color
> patches with
> no detail in the color patches. So as I said, it seems to be
> dependent
> on image size, image resolution, and level of detail all
> together, how
> small an image you can get accurate default CMYK separations
> for. 
> I've posted the correct CMYK separations along with the
> incorrect ones;
> I will soon remove the incorrect ones from the page, which
> will
> eventually be incorporated as a permanent page on my
> website, but it
> seems right to keep them there for the moment so you can see
> what can
> happen if you try to generate separations outside
> Photoshop's apparent
> range of size and resolution for files it can comfortably
> generate
> accurate separations for. The separations are clear at the
> bottom of the
> page.
> Katharine Thayer
Received on Fri Dec 17 22:22:34 2004

This archive was generated by hypermail 2.1.8 : 01/03/05-09:29:44 AM Z CST