On Tue, Mar 8, 2011 at 3:34 PM, Øyvind Kolås <pip...@gimp.org> wrote:
> On Tue, Mar 8, 2011 at 1:33 PM, Bogdan Szczurek <thebod...@gmail.com> wrote:
>> have nice black background. Most of the times CMS will try to simulate
>> that with all colors while it's better to use e.g. just full black and
>> cyan. Another example: you need to do some trapping. Sometimes it can
>> be done in RIP but you need to trust that to RIP itself and print
>> house. These are only a couple of arguments, leaving aside quite
>> similar cases of printing with paints different than C, M, Y and K.
>
> There are use cases where direct control over the separated result to
> CMYK is desired, this is however the corner cases and not the generic
> sense,

True enough, but I'm living on "that edge" ;).

> it is my impression that a lot of people are editing in CMYK
> without understanding color management at all, effectively
> circumventing proper color management to happen.

I believe, color management is one of the most misunderstood and
non-understood subjects out there generally :).

> In the few cases
> where you need to include text or vector elements on top (or embedded
> within) an image and want to ensure a matching color with the
> (adjusted) photo,. or do other things to avoid problems with
> registration problems yes I see this as beneficial. To edit photos in
> a device specific (or even geography specified least common
> denominator CMYK profile) by default is however in my opinion not good
> advice.

I don't see it different.

> 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 love that notion! I think of it similarly. Yet there's one thing in
print specific color models that's notoriously neglected in color
managed systems: image isn't magically put on some white (what is
white exactly? ;)) universal material. Image goes through CtP (most of
the time nowadays), machine and is placed on material of different
characteristics. So, what is really needed for good color management
is the profile of each of these stages, or at least whole process. Of
course there are some "standard" profiles (e.g. FOGRA) but they all
fall short when one is to use for example uncoated, dark red paper. I
know, I know… egde case, yet as I said before I'm quite often on such
edge :).

> This the direction I have encouraged GIMP to move in on the UI level.
> This distances it from color managed, photo retouching etc. In the
> foreseeable future I see GEGL as primarily aiming to provide the core
> to do color manipulation, processing and image processing in
> colorimetrically managed (RGB) color spaces;

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.

> 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).

Best regards!
thebodzio
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Reply via email to