On Thu, Mar 26, 2009 at 10:14 PM, Andrew A. Gill
<superluser@xxxxxxxxxxxxxxx> wrote:
> As little as I trust Pantone to CMYK, I trust Pantone to RGB
> even less.
>
>> By this i mean anything which can't be done by processing
>> the "plates" as separate grayscale channels (see ?yvind Kolas's post).
>
> This is not fun. What you are suggesting is a very laborious
> process, and having such a process work properly would probably
> result in tens of minutes to hours of wasted time, depending on
> the image in question.
>
> And it still would result in one of the following:
>
> 1.) A helper application which creates the CMYK image
> 2.) GIMP still is unable to deal with trapping or rich black.
I was not describing user interface anywhere in my mail, I was describing
underlying implementation mechanisms. GEGL stores pixels in buffers
that can store and on demand convert to and from RGB, YCbCr, CIE Lab
and Grayscale (dynamically extendable with other color models).
Allowing image processing operations to be implemented using the
models best fit for a particular operation.
GeglBuffers are not designed to deal with the special cases of multi
spectral images (lets say 32bands), spot colors (print plates). Render
layers as present in EXR files (blender for instance produces multiple
layers that are useful in post processing of the render). These will
have
to be dealt with on top.
For CMYK the following ops need to be implemented:
CMYK-from-RGB - takes a GeglBuffer as input, has options for black
subtraction, ICC profile selection, gamut handling and similar,
provides four gray scale GeglBuffers as output.
CMYK-to-RGB - takes a four separate gray scale GeglBuffers as input
and provides an RGB soft proof.
CMYK-to-CMYK - which converts to a CMYK GeglBuffer (OK, GEGL and babl
actually support very naive CMYK buffers, these buffers are fragile
and
should probably only be used as a prestep to passing the buffer to a
TIFF or similar saving op.
Similar duotone-from-RGB and a configurable duotone-to-RGB or special
five channel ops for use with CMYK with additional spot colors, or
perhaps even a generic configurable ink-mixer op could be implemented.
If a person with interest in these things want to he could also add
support for 1bit GeglBuffers and generate the final raster to be
printed at the printers native DPI.
The primitives above should provide both preview and control over CMYK
the fact that the innermost core doesn't care about CMYK would
probably bleed into the user interface in the form that not all
operations operate on CMYK images like they do on RGB images, it might
not even make sense to accomodate for having layers of CMYK objects
but only cater to the hard-core CMYK needs of pre-press, with a core
set of the tools (color picker, color balance, curves, color picker)
aware of how to deal with the CMYK bundle. Doing things like blurs and
pastes would normally operate on the single selected plate, but
electing to process for all plates should be possible.
At the moment I do not have interest in CMYK but the above outline is
in line with my ideas on how GEGL should evolve.
/Øyvind K.
--
«The future is already here. It's just not very evenly distributed»
-- William Gibson
http://pippin.gimp.org/ http://ffii.org/
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
