Re: [gentoo-user] CMYK comparison to sRGB between platforms

[Mick]

On Thursday 10 Sep 2015 22:07:44 wabenbau@×××××.com wrote:
> Mick <michaelkintzios@×××××.com> wrote:
> > On the same hardware I noticed that a CMYK photograph converted to
> > sRGB looked mostly the same (indistinguishable) on Linux, but the
> > sRGB colours were brighter on MSWindows.
> >
> > I tried this by dual booting between MSWindows and Linux.
> >
> > Then I tried it by running MSWindows within a VM on a Linux host and
> > the MSWindows showed a clear difference in brightness between the two
> > formats.
> >
> > Finally, I checked on an AppleMac and the difference between the CMYK
> > and sRGB photographs was even more prominent than MSWindows.
> >
> > So, the Linux renedering seems to be misleading the user.  Have you
> > noticed the same?
> >
> > BTW, both Linux machines that I tried this on are running radeon
> > drivers - are these to blame?  The AppleMac is running Intel graphics
> > with its 'retina' monitor.  Is it a matter of somehow tuning the Xorg
> > settings on my Linux PCs?
>
> First I must say that even though I'm working as a photographer I'm not
> an expert on Color Models. The professional exposure and print service
> that I use only accepts RGB Color Models. They use laser projectors to
> expose photographic papers. No conversion to CMYK is necessary.
> If I order fine art prints, they are doing the conversion by them self.
> All I have to do is softproofing my pictures in Lightroom using their
> different ICC profiles, to make sure that I don't deliver pictures that
> are out of the destination gamut.
> So I don't have any practical experiences with CMYK pictures. I only
> have some incomplete theoretical knowledge about it.
>
> CMYK is a subtractive color model and RGB is an additive color model,
> they are working completely different. It is not possible to convert
> one in to the other by just simply adjust some gamma curves or using a
> LUT as it is done by color management systems like lcms.
>
> When you are watching a CMYK picture, your picture viewer has to convert
> it to a RGB color space (sRGB or AdobeRGB or similar), because that is
> what your monitor needs. And I think there are not much picture viewers
> that are able to display a CMYK picture.
>
> This conversion can not be done by the graphics driver, regardless what
> kind of OS you use. Indeed Linux drivers can only use 8 bits per color
> channel (that's really poor IMHO) and Windows can use 10 bits per channel
> (depends on the graphics card), but this can't make big differences in
> brightness or saturation. It only leads to smother color transitions in
> some pictures.
> So I don't think that the drivers have anything to do with your problem.
>
> Apart from the different color models (CMYK vs RGB) there exist different
> color spaces (eg. AdobeRGB and sRGB). When you convert one color space in
> to an other, there are parameters like black point compensation and
> different rendering intents (perceptual and relative or absolute
> colorimetric), that can make a difference in the resulting picture.
>
> You didn't told exactly what you have done. This makes it difficult to
> find a reason for the problem. But I can think of different reasons for
> the phenomenon you observed:
>
> Different picture viewers and/or different color management systems and/or
> different color spaces (including different rendering intents respectively
> black point compensations). :-)
>
> --
> Regards
> wabe

Thank you all for your answers.  They guided me to do some reading in this 
field, which is quite a science all on its own!

The problem I had was caused by the use of ImageMagick's 'convert -colorspace 
RGB' which is an approximation rather than specific to the colour profile of a 
particular image.  As I posted the colours of the original and the converted 
looked similarly saturated, over-brightened, on Linux.  On AppleMac (different 
box) and MSWindows (same box and same monitors) the difference between the two 
images was more noticeable.

I spent some time adjusting the brightness, contrast and RGB colours on the 
two monitors to make them as close to each other as possible and as close to 
some images I had of some fabrics.  I used these because I also had physical 
samples of these same fabrics, so I could compare them against the real thing.

I also used colour patterns I found on the Internet for calibrating monitors.  
The match between the two monitors was not perfect, because one is LCD and the 
other a much brighter LED.

Then I played with the System Settings/Display/Gamma of KDE, but noticed I 
could only affect the RGB colours on the left monitor.  So I started searching 
for various applications that would allow me to finely tune the calibration of 
the monitors.

I ended up installing media-libs/oyranos and kde-misc/kolor-manager.  The 
oyranos application connects to the Taxi DB of icc profiles[1] and fetches the 
icc profiles for different monitors that contributors have submitted 
calibration settings for.  This means that I do not have to use a spectrometer 
or calorimeter, as long as I am happy to live with some variation that may 
exist between monitors of the same make and model.

Kolor-manager adds a new setting selection in System Settings of KDE which 
allows me to select each monitor in turn, see the EDID icc that the OS reads 
from the monitor chipset and then fetch any profiles that people have updated 
to the Taxi DB and use them instead.  In addition, the Kolor-manager saves any 
such profiles locally in ~/.local/share/color/icc/ and loads what I select 
when X starts.

There are other non-KDE applications like monica, which adds gamma correction 
values to .monicarc and then a call for loading these values in .xinitrc, or 
.bashrc, so that when X starts the appropriate icc file is sourced.

Peter's description does not mention which application loads the .icc file 
that the hughski creates, but I'm guessing there must be something that does 
read it, if the monitor settings are indeed altered.


With the monitors sorted as best as I could adjust them manually I loaded the 
icc files with Kolor-manager.  I could not see any change in the colors 
displayed by the monitors.  They are both wide gamut monitors, so perhaps the 
RGB changes were within the narrower RGB spectrum and that's why I did not 
notice a difference - not to mention that my eyes are not they used to be. :p


Having done all this, I revisited ImageMagick.  I ran identify -verbose and 
discovered that the original jpg image did not have an embedded icc profile.  
So I reran the command specifying a cmyk profile for the input file and an 
sRGB for the output file.  The result is now satisfactory and comparable on 
all operating systems.

I am still a bit unclear if on non-KDE dekstops xserver will pick up any icc 
files for the monitor from ~/.local/share/color/icc and load them at start up 
all on its own, or if any additional software is necessary to achieve this.

Thanks again for your help.


[1] http://icc.opensuse.org/
-- 
Regards,
Mick