Re: [Gimp-developer] Color space support

[Jason Simanek]

On Fri, May 7, 2010 at 1:49 PM, Chris Mohler  wrote:
> As long as they insist on CMYK artwork, CMYK mode is a necessary evil.

I guess I thought Separate+ handled that necessary evil. But I don't
use it myself, so it might be pretty sketchy.

> But this has all been discussed in depth on this list, and once gegl
> is fully integrated we'll have all the tools needed for a managed
> workflow, and also the necessary evil of CMYK mode :)

Yes, indeed. Thanks, Peter, for the URL of your post discussing the
plan for addressing CMYK and other color mode outputs. That sounds
beautiful.

-Jason Simanek
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Color space support

[Guillermo Espertino]

If you take a look on the list archives you'll find that I was one of those
designers saying that GIMP sucks because it doesn't have a CMYK mode. But I
changed my mind! :-D
Honestly, It took me to really understand how color management works and
leave some old bad habits alone to get it.
Now I'm working in RGB and sending to print shops with good results. I send
sRGB images or CMYK separated with Separate+ or CMYKtool.
CMYK mode is a legacy from the past, and with the growing adoption of CTP
and DI systems we shouldn't be discussing this. Both Adobe and Pantone are
recommending to work with late binding, although Adobe software still allows
to work with early binding. So no matter what designers say, even their
loved flagship companies are thinking different.

What is hard to understand for desingers is that the problem isn't CMYK but
spot colors. We tend to use CMYK because we see it as an image created by 4
spot colors instead of a device dependent interpretation of an RGB image.
It took me some time to get used to it, but the idea of creating a
separation projection on the top o a color managed RGB image, letting the
user define spot colors, is growing on me as the best way to tackle this
difficult issue.

So forget CMYK, The projections system proposed by Peter will take spot
channels in consideration and that will solve most of our problems.  Not
going back to a legacy hack.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Color space support

[Chris Mohler]

On Fri, May 7, 2010 at 8:42 AM, Jason Simanek  wrote:
> The trouble that most contemporary designers have when it comes to
> creating professional graphics with the Gimp (and Inkscape, Scribus,
> etc.) is due to their lack of knowledge.

(Also anecdotal) - personally, the trouble I have is with the vendors
that require CMYK artwork.  If we could convince the entire industry
to accept color-managed RGB, well sure we'd not need to design
anything in CMYK except corner cases like rich black and overprinting.
 However, from what I can tell of the printing industry (at least in
the US), this is just a nice dream.  As long as they insist on CMYK
artwork, CMYK mode is a necessary evil.

I worked for a printing company for a while.  They preferred CMYK
artwork, the rationale being: people tend to send something with a
#FF background and get angry when the final printed item comes out
different (of course a good proofing system helps here).

But this has all been discussed in depth on this list, and once gegl
is fully integrated we'll have all the tools needed for a managed
workflow, and also the necessary evil of CMYK mode :)

Chris
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Color space support

[peter sikking]

hey guys,

we went last year through a big discussion here with input from pre- 
press
professionals. The result from that is that I filtered out the needs
of these users and taking the concepts from pippin, made UI/workflow
solution that avoids copying old hacks and bad ideas.

this was presented at last year's LGM and blogged:




so there we go,

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Color space support

[Jason Simanek]

On 05/07/2010 06:13 AM, Cristian Secară wrote:
> On Fri,  7 May 2010 12:24:19 +0200 (CEST), Easyword wrote:
>> - GIMP supports only RGB color space
>>
>> This is a limitation, which prevents the use of the software in
>> professional use. You may use GIMP to create graphics for
>> professionals, but you may not receive any professional graphics.
>
> It depends what „professional” for you means.
> I am working in television/video area, where all graphics are in RGB
> (sometimes with additional key channel (alpha)). For me the CYMK color
> space is of no use (and I get in trouble when someone gives some color
> specifications in non-RGB values).

As a professional graphic designer I think that there's a real lack of 
understanding about color spaces among graphic designers. I know lots of 
designers that do color corrections in Photoshop with an image in CMYK 
color mode. In fact they do everything in CMYK mode if they open 
Photoshop at all.

Unless you are creating a graphic that is intended to specifically match 
a printed color, this method of working in CMYK is unnecessary and ill 
advised. The belief that working with photographs in CMYK mode is 
'professional' and more color accurate is wrong. An image should only be 
translated to CMYK mode once it's finished and ready to go to press. And 
that translation needs to happen in a color managed process.

The CMYK mode in Photoshop is merely an estimation of the CMYK color 
space. It understands the gamut of CMYK but the representation of those 
colors on the screen is an estimation dependent on a calibrated display 
and fully color managed workflow. After all, your display renders colors 
in RGB.

It's much more important to work in a color managed environment. I've 
worked with many, many 'professional' designers that have very little or 
no understanding of color profiles or color management. I've even seen 
them discard the color profiles of images when they open them in 
Photoshop. That was actually the recommended practice at a magazine I 
worked at. Unbelievable. Don't believe it? I still can't believe it.

Of course, this is all anecdotal. I don't mean to start a flame war. My 
point is that Gimp is not Photoshop. A lot of folks give Gimp a try and 
frequently criticize Gimp for not being a complete clone of Photoshop. 
Granted, Photoshop is a great tool in many ways and a good ruler for 
Gimp to measure itself against. But assuming that Photoshop is 
infallible and that every aspect of it is sacrosanct is a mistake.

The developers are addressing aspects of Gimp that they find useful and 
interesting. The CMYK color mode is complex I'm sure, mostly due to all 
of the color estimation that is needed to display the mode on screen (as 
mentioned above). Alexia is right. This is building things from scratch. 
And we do have the Separation plugin to export to CMYK. But no, Gimp 
does not have the safety blanket of CMYK color mode to give graphic 
designers the assurance that their colors look right (even if the 
accuracy of those colors is an estimation dependent on a color managed 
and calibrated display).

Gimp CAN be used to create professional graphics. You can also make 
professional graphics with printed photos, rubylith, paste, pens, ink, 
lead type and paper. Both of these approaches are dependent on the 
creator having a certain level of knowledge about the printing process.

The trouble that most contemporary designers have when it comes to 
creating professional graphics with the Gimp (and Inkscape, Scribus, 
etc.) is due to their lack of knowledge. That's not an insult. They're 
just used to working with a lot of programs that handle most of the 
technical details that graphic designers and prepress workers needed to 
know in the past. These open source programs, as great as they are, just 
aren't entirely to that point yet.

One of the big reasons that they aren't to that point is because they 
are developed by very smart people that only need the program to take 
the project to a certain point. The other reason is that most of the 
developers are not professional graphic designers. Along with that, most 
professional graphic designers know very little about programming.

If graphic designers want great open source tools that meet their needs, 
they're going to have to start contributing to the projects. That's what 
I've been trying to do. You got to put your money (or time and effort) 
where your mouth is.

Thanks for listening.

-Jason Simanek
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Color space support

[Cristian Secară]

On Fri,  7 May 2010 12:24:19 +0200 (CEST), Easyword wrote:

> One of these problems is:
> 
> - GIMP supports only RGB color space
> 
> This is a limitation, which prevents the use of the software in
> professional use. You may use GIMP to create graphics for
> professionals, but you may not receive any professional graphics.

It depends what „professional” for you means.
I am working in television/video area, where all graphics are in RGB
(sometimes with additional key channel (alpha)). For me the CYMK color
space is of no use (and I get in trouble when someone gives some color
specifications in non-RGB values).

(perhaps the 8 bit per color limitation might be a limitation in my
professional area)

Cristi

-- 
Cristian Secară
http://www.secarica.ro/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Color space support

[Alexia Death]

On Fri, May 7, 2010 at 1:24 PM, Easyword  wrote:
> It is like you would have a car without tyres. You have very nice car, but
> you cannot use it. Hopefully, developers would consider this type of problems
> in the future.

And what makes you think they are NOT in fact considered right now?
Here's a hint: They are and have been for some time. Work towards
supporting whatever pixel representations has been ongoing for years
now and is going to take a few years more. If you want it faster, come
and help us do the work. Please find out where development is headed.
Also, have you ever tired to make your tires from scratch?

-- 
--Alexia
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer