On Fri, 2001-11-30 at 10:06, [EMAIL PROTECTED] wrote:
> On Fri, Nov 30, 2001 at 03:38:10AM -0800, Jay Cox <[EMAIL PROTECTED]> wrote:
> [cmyk comversion]
> > Where I work it is a very critical process.
> Any tips here? If gimp would support CMYK on-screen, how would the users work
> be different? Do users actually adjust CMYK themselves or do they just draw
> using predefined CMYK values?
Users actually adjust the cmyk values.
> I mean, is the principal problem the missing CMYK colours in RGB, or is
> the principal problem the "looks the same on-screen as on print". The
> latter could be solved largely outside the gimp (tiff plug-in), the former
> obviously not.
Having the image on screen look similar to the printed image is nice,
but not required.
The problem with rgb is not that it can't represent some colors
available with CMYK inks. The problem is that aproximatly 20% of the
colors available in RGB cannot be represented in CMYK. If you simply
map the colors that are outside of the CMYK gamut to the closest
possible color you end up with flat spots in your image. There are
other methods for mapping between dissimilar gamuts such as the
different ICC profile rendering intents, but none of them work well on
all images (and for many images none of them work well).
The most important task that prepress image editing applications have to
accomplish is this: After looking at a proof of your image you must be
able to correct the image so that your next proof will look like what
you want it to (usually the transparency that it was scanned from).
This is generaly easier to do when you are working in the same
colorspace as your printing device. There are certain classes of
corrections which would require deep voodoo if you were trying to do
them in RGB mode (for example getting rid of banding in individual
seperations, or adding shape to highly saturated portions of your
Gimp-developer mailing list