[scribus] Colour Profiles - make colour matching worse!

[John Beardmore]

Peter Nermander wrote:

>> Yeh well thats not entirely logical either!  You should be able to
 >>output to an industry standard and then tell the printer here's a
 >>job thats in industry standard format - use the printer specific
 >>profile built into the printer to output the job adjusted for the
 >>printer.
> 
> The above statement makes me think you don't have the slightest idea
> about the problems with color management.
> 
> First of all we have the colorspace. The colorspace tells which
> physical color (usually defined by CIELAB) a certain numerical value
> (as for example the RGB value of a pixel in a JPEG pictore)
> corresponds to.
> 
> So for example a pixel with values RGB 12:34:56 is one color in sRGB,
> but a completely different color in for example AdobeRGB.
> 
> Now, CIELAB contains all colors visible by the human eye (as far as I
> understand it), however other colorspaces contain only a subset. That
> means that for example the colorspace AdobeRGB contains some colors
> that CAN NOT be reproduced in the colorspace sRGB. The coverage of a
> certain colorspaceis called gamut, colors that can not be reproduced
> are "out of gamut" (and Scribus has support for showing you which
> colors are out of gamut for the end device, if you have correct
> profiles).
> 
> Also RGB and CMYK are totally different. When you tell Scribus to
> produce a PDF for print, it creates a CMYK PDF. But from what you are
> writing (that your printer is using its built in profile) I think your
> printer wants RGB data, so you should create a PDF intended for screen
> (the only difference is RGB vs CMYK).
> 
> This page doesn't cover everything, but is has links to further reading.
> http://en.wikipedia.org/wiki/Color_management
> 
> Color management is VERY complicated, and you have to make sure you
> understand which profiles are needed for which translation. I know
> enough about color management to understand that I shouldn't be using
> it yet... I need to learn more.

Same here, but I suppose the frustration is that the documentation of 
most software doesn't make colour handling particularly clear.

It would seem logical that if CIELAB is a colour space that can describe 
anything the human eye can perceive, that all images be stored 
internally in this format. This then requires a profile that describes 
the conversion of each input devices colour space to CIELAB, and another 
profile for each output space describing the conversion from CIELAB to 
the printer specific output.

For PDFs which are frequently multi use things, it would presumably be 
sensible to keep images in the CIELAB format then use profiles for each 
VDU, CRT, LCD and mobile phone used to view them, or each windows or 
press printer that might be used to put them on paper.

In the absence of such clear and well defined data flow, the mumblings 
about the complexity of CMS seem to contribute to a small of bad design.

Is CMS something that needs to be complex, or just something that's got 
complex because of the lack of standard methods and clear description / 
specification ?


In some ways it would be great to get into CMS and have everything come 
out as it should all the time, but for many, the pragmatic approach is 
to tweak curves a bit in gimp taking account of your experience with the 
target printer.


I can't help thinking that CMS is an area that needs a good sort out, 
not so much in Scribus, but industry wide.


Cheers, J/.
-- 
John Beardmore, MSc EDM (Open), B.A. Chem (Oxon), CMIOSH, AIEMA, MEI
Managing Director, T4 Sustainability Limited. http://www.T4sLtd.co.uk/
Energy Audit, Carbon Management, Design Advice, Sustainable Energy
Consultancy and Installation, Carbon Trust Standard Registered Assessor
Phone: 0845 4561332   Mobile: 07785 563116   Skype: t4sustainability