[Scribus] CMYK image processing

[pixelnate]

Craig Ringer wrote:
>> - You've got a photo which looks nice on screen but a bit too yellow
>>   when printed - you'll just remove some yellow after conversion to CMYK.
>>     
>
> I'd argue that the need to do that means your colour management profiles
> / configuration / tools are deficient. It's possible there's no way to
> get them good enough - I won't be able to say until I've personally
> been using it in production for a while - but off the top of my head I'd
> be surprised if it were necessary to work manually with CMYK data most
> of the time.
>
>   
Alright there Craig, just which OSS tools allow for the proper creation 
and editing of profiles from within linux? Without the tools to set 
things up 'properly' and no CMYK photo editing apps we (very) 
experienced color correction guys can _never_ trust linux for this kind 
of work. When you are setting documents up for sending to the printer, 
the CMYK image will 99.999% of the time need to be massaged before it 
goes out. CMYK is a necessity to get professionals to use the OSS tools. 
Period! No CMYK, no mass acceptance by the pros. It is as simple as that.

Without good CMYK support in Gimp, I would certainly go for Photoshop 
running with Crossover Office. Until there is a real alternative this 
will be the case for many others as well.
>> - You're using printed color reference charts to get colors right. They
>>   are always in CMYK since that's what will be used to print.
>>     
>
> Using CMYK values from a chart doesn't necessarily get things to match,
> unless the chart was printed by - or to match - your target output
> device. That's unusual. I've learned from "interesting" personal
> experience that a CMYK value does come out different on different
> targets, media (eg basic vs whiter newspaper), and so on. The staff at
> work rely on Photoshop correction tables, manual offsets based on
> experience, and PANTONE spots to handle this - they too know that a CMYK
> colour looks different in different contexts. We've done tests
> (usually unwittingly due to customers or our staff doing something
> wrong, but sometimes intentionally) where we print a PANTONE named spot
> colour directly beside the CMYK alternative provided for that spot. The
> difference is usually remarkable.
>
>   
This is why it is necessary for the proper profile creation tools to be 
available in linux. And Pantone colors are never properly duplicated in 
CMYK values. That is the reason for the existence of spot colors.
> As it happens, at work we also work on images in RGB in Photoshop,
> previewing the CMYK result after profiled conversion. We use Photoshop
> to do the CMYK conversion, but it'd be the SAME to use the DTP app to do
> it (if the profiles and CMM are the same), it's just that our version of
> Quark is not capable of doing so. The POST's printers actually recommend
> working in RGB and deferring the CMYK conversion to the last minute,
> which we do.  In that sense, we already rely on colour management.
>
>   
I also do most of my color correction in RGB. There is a greater range 
of color available for pushing and pulling around. I will also say that 
I rely heavily on the CMYK preview in PS to see what the image will look 
like in CMYK. But, and this is a big one, the CMYK document will 
_always_ be further manipulated once it has been converted. It is very 
difficult to get the contrast in the RGB image to translate to CMYK. And 
the black values are almost never correct in the midtones, and the 
shadow CMYK values will always need some work as well.

And yes, I use the proper profiles for my image work, I am not a rookie.
> This is what the GIMP should support doing soon, if I understand
> correctly. Since Scribus will be able to perform the desired CMYK
> conversion on the fly (using the same profiles and CMM that GIMP used to
> make the screen preview), you should be just fine.
>   
That is something you just don't seem to be getting. I don't really care 
that Scribus will convert the images on the fly. It is certainly nice 
that the devs have built this into the app, especially considering the 
shortcomings of the Gimp. That said I would never trust QuarkXpress or 
InDesign to convert my images either, even with the proper profiles 
built. Each image is different and will respond differently to that 
conversion.
> By the way, the fact that CMYK colours look different on different
> devices and media is also why I think it's not that important to handle
> manual tweaking of images. Whether you're working in CMYK or RGB, you
> need colour management (whether ICC, hand display profiling, some
> proprietary system, etc) to see on screen what you will see in print.
> Given that, why not let the colour management engine take care of the
> final RGB->CMYK managed conversion - you already know what the result
> will look like within the limits your display device is capable of
> showing.
>   
That is heresy for a color correction expert. The image can always be 
better than after a default color conversion.
> I'm NOT an expert in this by any stretch. Colour management is complex,
> I don't know it as well as I'd like, and I'm still learning fast. I'd be
> happy to be corrected, and I'll gladly listen to other opinions. I don't
> personally think the issues bought up thus far are a big deal (except
> for being used to working in CMYK - and we must all deal with change
> eventually). Again, I'm not saying CMYK bitmap editing is irrelevant,
> just that I don't think it's as important as it used to be, and that
> many or most users should be just fine without it now.
>   
As long as you send documents to a printer (a location, not the device), 
there will be a need for CMYK bitmap editing. Always. It will never be 
irrelevant.
>> Having a fully color-managed workflow is a nice goal. But in practice, there
>> are a lot of people who will not put a lot of effort into this since
>> it's okay for them to work in CMYK and they are used to it. IMO it's a
>> matter of complexity.
It is also expensive to have someone set up your color workflow 
properly, and there are precious few who do it well. Where I work, the 
cheapskates I work for refuse to buy the devices so that I can set up 
the profiles for our printers and monitors, and they don't want to pay 
the very able area rep that can do it for us. So I am _the_ eyes in the 
agency where I work. All color is corrected on my monitor and approved 
by me before it goes to press. I rely on editing images in CMYK. If the 
tools don't support that, then I find tools that can. It is as simple as 
that.
>> Complexity, and resistance to change (by virtue of not wanting to invest
>> the time to learn and tweak and set up the new method, if nothing else.
>> Entirely understandable.).  I'm not sure that - when the documentation
>> is good and the tools do the sensible thing by default (neither of which
>> is now as true as it could be), a colour managed workflow is any harder
>> than hand-correcting CMYK images by eye, experience, and hand-tweaked
>> displays. Of course if you already know how to manage a workflow that
>> uses early conversion to CMYK you'll want to keep doing that. I'm just
>> arguing that you don't have to work that way to get the results you
>> want, and that existing OSS tools can provide another method that'll
>> produce results as good, where they can't currently provide support for
>> working the way you're used to. I don't think it'll be _necessary_ or
>> even that important to have CMYK support in GIMP to get good print
>> results, though of course it's always _nice_, and not having it will
>> force some people to adopt a new and thus initially challenging
>> workflow.
>>     
I am not concerned with good, I am concerned with great. While I would 
love to work in an environment set up with proper color profiles on all 
devices, very few have that luxury. Any tool that helps you get the job 
done is a useful tool, but the fact remains that no profile is good for 
every image. For your image editor to be taken seriously by the pros, it 
must have good CMYK tools. All (and I do mean _all_) of the products 
that have tried to compete with Photoshop (i.e. LiveImage, xRes, Paint 
Shop Pro, et. al.) have failed because their developers have failed to 
include professional CMYK tools. IMHO, the lack of CMYK tools will 
forever hamstring the adoption of OSS for the professional print world.

-End of line.   Nate