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
