[scribus] Colour Profiles - make colour matching worse!

[John Beardmore]

Hal V. Engel wrote:
> On Sunday 26 July 2009 04:45:11 pm John Beardmore wrote:
>> Peter Nermander wrote:

>>> 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).

I think this terminology causes confusion because most desktop printers 
don't need CYMK ?

I would have though some words along the lines of

   * RGB for general purpose PDF output, typically for web use
     and desktop printing.

   * CYMK PDF, typically for commercial printing.


>>> 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.
> 
> This is what the color management engine does although there is no requirement 
> that images or anything for that matter be stored in CIELab or any other 
> device independent color space.

Which is possibly a large part of the problem as the variety of possible 
profiles and incompatibilities must go up rapidly with the number of 
possible input and output devices in the absence of a common internal 
format.


>  Profiles can also use CIEXYZ as the Profile 
> Conversion Space (PCS) as well as CIELab and the CMS knows how to handle 
> conversions between CIELab and CIEXYZ so that it can handle conversions that 
> involve either or both PCS types.

OK -  if there are only two PCS types, that's a start.


>> 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 fact the PDF specification calls for support for various color spaces 
> including what the spec calls CIE Based color spaces.  One of these is CIELab  
> but this also includes objects where the color space is specified by an ICC 
> profile.  In addition the spec allows for what it calls CalRGB, CalCMYK and 
> CalGray color spaces which are basically specified by a combination of an XYZ 
> white point and some gamma curves (actually a gamma curve formulas) and the 
> XYZ values of the primaries.  Internally when a PDF is sent to a device for 
> display/printing the PDF spec calls for everything not in the device color 
> space to be converted from what ever color space the individual objects are in 
> to CIEXYZ and then from CIEXYZ to the output device color space.   It does not 
> really make sense  to store everything in the PDF in CIELab since the 
> specification calls for everything to be converted to CIEXYZ as an 
> intermediate step and as long as all of the objects in the PDF have well 
> specified color spaces then the conversion process is unambiguous.  As a side 
> note anything in a "device" color space is in fact not well defined in most 
> cases and this is were many issues pop up. 

>> In the absence of such clear and well defined data flow, 
> 
> As you can see from the above the color data flow is well defined and very 
> clear but is also complex.  But I think what you were trying to say is that 
> this is not clear to users.

Yes -  to a significant extent.  Though I suspect that is CMS were to be 
redesigned from scratch, we might end up with something less complex as 
well as more accessible.

Apart from the disk space used, I don't really see anything wrong with

     profiles from devices to
     universal colour space to
     profiles to output devices


The fact that "the PDF specification calls for support for various color 
spaces" may be a reflection of history rather than what's needed to get 
the job done.

Of course, I don't expect the historical legacy to go away, but I do 
wonder if the CMS world could converge on something better.


>  Which leads to
> 
>> 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 ?
> 
> The CMS needs to be complex.  It is the nature of the beast.  The ICC 
> specifications are clear and are based on science dating from the 1920's and 
> 1930's dealing with human perception of color.  This by it's nature is complex 
> because it actually deals with how the human mind works.  


So why does anything more complex that the full gamut of what is visible 
to the eye need to be described ?  Surely the point of CMS is to 
reproduce original colours accurately, not to interpret them ?


> It should be possible to hide at least some of this complexity from users.  
> The real issue is that at present users are forced to deal with at least some 
> of this complexity and app and OS vendors/developers have not done a good job 
> of shielding users from it.

Or describing it.


>  In fairness this is difficult because of the 
> complexity and because many subsystems are involved in the process.  OS/X is 
> probably the best at hiding this complexity but it still has issues in this 
> regard.  Windows is only slightly better than Linux and other unix variants in 
> this area and both are far behind OS/X with respect to user accessibility.  
> There is lots of work being done on the *nix side to help with this issue 
> (there are a number of GSoC projects currently underway for example) but it 
> will likely be a while before a significant amount of this effort filters down 
> to end users.

I suppose if a full CMS requires huge complexity and an understanding of 
human perception, maybe there is scope to implement something which is 
much simpler and just reproduces the colours accurately.


>> 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.
> 
> Well actually the correct approach is to understand and correctly use the CMS.

In most businesses the correct approach is to convey the information in 
a document of which the pictures may be a small part. Brownie points are 
awarded for doing fast and doing it pretty.

Except in very specialist businesses, management does not award points 
for the use of CMS, nor more formally correct use of CMS.


> It is very powerful and if you understand how it works and how to correctly 
> set things up it will have a very positive impact on the quality and 
> consistency of your work as well as actually streamlining your work flow.

Yes -  it's that streamlining that attracts me to it, and the notion 
that if I print to a different device I can get the same colours.


> Having said that it takes a lot of up front effort to do this which makes 
> getting past the learning curve a difficult task for many users. 

Yes -  and the need to buy kit to calibrate monitors and print output 
doesn't help either.


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