[Scribus] getting started with colour management

[Craig Ringer]

jrm wrote:
> It seems to be standard advice, when setting up colour management,
> to set the monitor to high contrast. When I do this, much of
 > the text on my monitor is fuzzier and harder to read.

This is true for CRT monitors. You should ignore any such advice for LCD 
monitors, at least when using a digital (DVI or HDMI) connection. With a 
digital signal these monitors are already at "perfect" contrast.

Most LCD displays that permit you to increase contrast above the default 
are actually transforming pixel values away from the correct original 
values. I've never understood why they do it.

Occasionally an LCD that does something sane with contrast on the VGA or 
other analogue inputs will turn up. Mostly they're just as bad on 
analogue input.

Similarly, many panels have a "sharpness" option - often a range from 1 
- 5, with 3 being the default. Changing it is a bad idea, since it's 
really a blur / sharpen scale with 3 being "don't mess with my pixels, I 
like them how my computer says they should be!".

In general, avoid altering the contrast or sharpness settings of LCD 
displays. It's not necessary and rarely useful.

> Another thing I've never understood is why, with colour management
> turned off, graphics have been looking quite different in
> Gimp 2.2 as compared with Scribus 1.3.  For example, I have some
> TIFF files with a red that shows very bright in Gimp but
> considerably darker in Scribus.  I'm *guessing* that Gimp and
> Scribus have been implicitly defaulting to quite different
> colour profiles, but I don't even know whether that's a sensible
> way of phrasing it.

Assuming it's an RGB TIFF, with colour management turned off, both 
should be sending the exact same pixel values to the window system, and 
through to the display. Are you *SURE* colour management is off in Scribus?

If the TIFF is not RGB, all bets are off. There is no meaningful 
transformation from CMYK to RGB without some information about what 
those colours *mean* on the source and target devices. Applications must 
use horrible quick and dirty fixed transforms, and they generally work 
very badly. Scribus and the GIMP probably use different ones. They're 
both bad, and really can't be anything else. The only app I've ever seen 
do this vaguely sanely was early versions of Photoshop, which basically 
hard coded a non-linear CMYK <> RGB translation table for a small set of 
presses. In essence, it hard coded profiles and conversion routines for 
sRGB <> SWOP etc. It was bad, but not as bad as what the GIMP and 
Scribus use when no colour management engine is available.

> I've got the vague idea that most software assumes the monitor
> profile would be some flavour of sRGB, with *which* flavour
> being application dependent.

Nope. Without colour management it assumes nothing at all - it just 
sends raw RGB values through, and murders CMYK colours horribly. Avoid 
at all costs.

> If I knew what Scribus assumes,
> then I'd know how to choose a "no-op" monitor profile matching
> the default assumption.

There really isn't any such thing. The closest to a "no op" profile 
setup is where your inputs are in the same colour space as your monitor. 
This is often the case if you've told your apps that your monitor is 
sRGB, and your images are tagged as sRGB. You should in this case see 
on-screen results practically the same as if colour management is 
disabled. Of course, anything involving CMYK works differently, since 
Scribus will use the CMS engine to transform the colours according to 
the profile rather than using a fixed (terrible) transform function.

Even with an inaccurate generic display and printer profile, you'll 
still get better results from Scribus using colour management than 
without it. You won't get on-screen images looking like they'll print, 
but you'll get a better printed result and a closer approximation of 
CMYK colours on screen.

--
Craig Ringer