> On Tue, Mar 8, 2011 at 3:12 PM, Bogdan Szczurek <thebod...@gmail.com>
> wrote:
> >> Considering the use cases where fine grained control over the
> >> resulting offset plates/actual ink used for C,M,Y,K to be a subset
> >> of the more general cases where individual ink control is desired
> >> (spot-colors (including metallic, glossy and other overprints) as
> >> well as duo tone and more).
> > I also have high hopes for GEGL, but I'd rather have it use some
> > more abstract color model for that. I know it's not so simple—maybe
> > even undoable–that way, but I do like the idea of color model that
> > has complete coverage of visible spectrum.
> Using a color model with full coverage of the visual spectrum would be
> an extension along the lines of RGB and the responses of the human
> visual system/physics, entirely additive.

Not entirely along the lines I'm afraid. First of all it strongly
depends which RGB we're talking about. Even if we take scRGB into
account there's still some considerable parts of visible spectrum that
can not be described by scRGB's triad. I know scRGB is tempting for
it's quite broad and seems easy to implement in RGB dominated world,
but I've got a premonition that using device agnostic color space would
pay off more. But again–I don't know that :).

> Spectral processing is not
> similar to subtractive models like CMYK

I can't agree more.

> models needed for simulating
> print, mixing aspects, subsurface scattering, ink interactions and
> more (some of which are better indirectly modeled by ICC transforms
> backed by actual test-runs).

Some effects can be modelled that way (maybe even all). Other thing is
if they actually are. Getting specific paper profile is most of the
time undoable. Maybe something could be done in that matter? For
example instead of painfully standard “color settings” dialog in
preferences and “assign profile”, “convert to profile” options some new
layout would work better? Maybe instead of going to a kind of “image
mode” menu, we should go to “color workspace” menu with all available
profiles listed there? The truth is that whenever we use color model
that is unable to describe whole visible spectrum we are using some
cutout of this spectrum, a working space. Giving an option to
just convert image to “grayscale” or “CMYK” seems to blur that truth
and IMHO tries to bury color management concept.

> >> with almost enforced
> >> strict working spaces for the algorithms to ensure predictability.
> >> The ability to do separation to CMYK, spot colors and more with
> >> associated processing on such will most easily be done as
> >> abstractions implemented using a planar approach where each ink is
> >> represented by a graylevel buffer.
> >
> > True enough, but we mustn't forget about target material
> > characteristics when considering print (and soft proofing), paint
> > printing order and their attributes (opacity among them too).
> All of these, like the simulation of glossiness or reflectiveness of
> metallic inks are things for the final separation/composite/simulation
> though - which very well can take into account both substrate and
> perhaps even an animated illuminant ;)

Tempting… tempting… :)

> Such soft-proofing would not
> be a space that GEGL itself would be doing processing in however, even
> though it might have op(s) to take the individual grey level buffers
> to create an RGB simulation to be shown on a display,. taking into
> account the RGB profile.
> Allowing the user to configure a largeish set of predefinable inks for
> separation and simulation/softproofing would possibly allow some very
> nice workflows in GIMP and other softwares using GEGL.

Yup! That's what I hope for too.

> Implementing the capabilities of doing such workflows is something
> that only can happen after GIMP itself has more naive initial support
> for storing its image data in GeglBuffers of higher bit depths. So if
> someone wants to play with, research and make prototypes for such a
> thing it would be a nice and welcome addition.

I don't think that higher bit depths are more important for
transformations than for storing color samples. If image is to be
displayed, most of the time it'll end up being crammed into 3 8-bit
values :). If it's about to be printed most often it'll be pushed into
finite (and not so big) number of possible raster point sizes. I think
transformations are really the things that are to benefit most from
bigger number of possible sample values. Images of course too, but not

Best regards!

Attachment: signature.asc
Description: PGP signature

Gimp-developer mailing list

Reply via email to