From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-user+bounces-167669-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id 3AFDB13881D
for <garchives@archives.gentoo.org>; Sat, 26 Sep 2015 15:11:32 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 6241721C0B1;
Sat, 26 Sep 2015 15:11:19 +0000 (UTC)
Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id EEFC721C00A
for <gentoo-user@lists.gentoo.org>; Sat, 26 Sep 2015 15:11:17 +0000 (UTC)
Received: by wicfx3 with SMTP id fx3so51607067wic.0
for <gentoo-user@lists.gentoo.org>; Sat, 26 Sep 2015 08:11:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=from:reply-to:to:subject:date:user-agent:references:in-reply-to
:mime-version:content-type:content-transfer-encoding:message-id;
bh=uO86HZndEMkLbGXycRHC0ZXVnW2l21rASnonrQR6s0k=;
b=NRHnbHffz9B8td8dIDddue0YLCVoPz7QF3cCrCe0CePR1gPJnTEPDyBiWN91PDbCXp
GcfBmL5gk5oMQq8SVUM3hby+Zv7v86o8DsJ0gRu0JkvmAxhADK+ikMugRYq6CLnl92CX
LrhArvR7idaHSUvkpRRKnLIKEPbQxlEItOVlmF4hUchBfgg+/TBF76B9SllGAZT91wrJ
oZe0JH/RbzNkuGzMPLWrX/HiAsvscHr5u9z9LqnUi8gtbUmDAjOk5S01jARxEbM+wB1N
5reQoYZi9flbv8J+t3+eg0nj1Bp3J1XVq4jaPfRU93qVfWlhNteKbzarUWGIGH112wiw
HSqg==
X-Received: by 10.194.85.163 with SMTP id i3mr12119387wjz.75.1443280276713;
Sat, 26 Sep 2015 08:11:16 -0700 (PDT)
Received: from dell_xps.localnet (230.3.169.217.in-addr.arpa. [217.169.3.230])
by smtp.gmail.com with ESMTPSA id ki7sm8770406wjc.28.2015.09.26.08.11.14
for <gentoo-user@lists.gentoo.org>
(version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Sat, 26 Sep 2015 08:11:14 -0700 (PDT)
From: Mick <michaelkintzios@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] CMYK comparison to sRGB between platforms
Date: Sat, 26 Sep 2015 16:11:04 +0100
User-Agent: KMail/1.13.7 (Linux/4.0.5-gentoo; KDE/4.14.8; x86_64; ; )
References: <201509081942.10580.michaelkintzios@gmail.com> <20150910230744.6aff0af2@hal9000.localdomain>
In-Reply-To: <20150910230744.6aff0af2@hal9000.localdomain>
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
MIME-Version: 1.0
Content-Type: multipart/signed;
boundary="nextPart10694771.St1WiPCHgx";
protocol="application/pgp-signature";
micalg=pgp-sha256
Content-Transfer-Encoding: 7bit
Message-Id: <201509261611.14108.michaelkintzios@gmail.com>
X-Archives-Salt: 07d6cae0-2035-4379-b822-8da69cc03179
X-Archives-Hash: 1ba60e335acb05962067b80a5de9127b
--nextPart10694771.St1WiPCHgx
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
On Thursday 10 Sep 2015 22:07:44 wabenbau@gmail.com wrote:
> Mick <michaelkintzios@gmail.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.
> >=20
> > I tried this by dual booting between MSWindows and Linux.
> >=20
> > 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.
> >=20
> > Finally, I checked on an AppleMac and the difference between the CMYK
> > and sRGB photographs was even more prominent than MSWindows.
> >=20
> > So, the Linux renedering seems to be misleading the user. Have you
> > noticed the same?
> >=20
> > 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?
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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:
>=20
> Different picture viewers and/or different color management systems and/or
> different color spaces (including different rendering intents respectively
> black point compensations). :-)
>=20
> --
> Regards
> wabe
Thank you all for your answers. They guided me to do some reading in this=
=20
field, which is quite a science all on its own!
The problem I had was caused by the use of ImageMagick's 'convert -colorspa=
ce=20
RGB' which is an approximation rather than specific to the colour profile o=
f a=20
particular image. As I posted the colours of the original and the converte=
d=20
looked similarly saturated, over-brightened, on Linux. On AppleMac (differ=
ent=20
box) and MSWindows (same box and same monitors) the difference between the =
two=20
images was more noticeable.
I spent some time adjusting the brightness, contrast and RGB colours on the=
=20
two monitors to make them as close to each other as possible and as close t=
o=20
some images I had of some fabrics. I used these because I also had physica=
l=20
samples of these same fabrics, so I could compare them against the real thi=
ng.
I also used colour patterns I found on the Internet for calibrating monitor=
s. =20
The match between the two monitors was not perfect, because one is LCD and =
the=20
other a much brighter LED.
Then I played with the System Settings/Display/Gamma of KDE, but noticed I=
=20
could only affect the RGB colours on the left monitor. So I started search=
ing=20
for various applications that would allow me to finely tune the calibration=
of=20
the monitors.
I ended up installing media-libs/oyranos and kde-misc/kolor-manager. The=20
oyranos application connects to the Taxi DB of icc profiles[1] and fetches =
the=20
icc profiles for different monitors that contributors have submitted=20
calibration settings for. This means that I do not have to use a spectrome=
ter=20
or calorimeter, as long as I am happy to live with some variation that may=
=20
exist between monitors of the same make and model.
Kolor-manager adds a new setting selection in System Settings of KDE which=
=20
allows me to select each monitor in turn, see the EDID icc that the OS read=
s=20
from the monitor chipset and then fetch any profiles that people have updat=
ed=20
to the Taxi DB and use them instead. In addition, the Kolor-manager saves =
any=20
such profiles locally in ~/.local/share/color/icc/ and loads what I select=
=20
when X starts.
There are other non-KDE applications like monica, which adds gamma correcti=
on=20
values to .monicarc and then a call for loading these values in .xinitrc, o=
r=20
=2Ebashrc, so that when X starts the appropriate icc file is sourced.
Peter's description does not mention which application loads the .icc file=
=20
that the hughski creates, but I'm guessing there must be something that doe=
s=20
read it, if the monitor settings are indeed altered.
With the monitors sorted as best as I could adjust them manually I loaded t=
he=20
icc files with Kolor-manager. I could not see any change in the colors=20
displayed by the monitors. They are both wide gamut monitors, so perhaps t=
he=20
RGB changes were within the narrower RGB spectrum and that's why I did not=
=20
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=
=20
discovered that the original jpg image did not have an embedded icc profile=
=2E =20
So I reran the command specifying a cmyk profile for the input file and an=
=20
sRGB for the output file. The result is now satisfactory and comparable on=
=20
all operating systems.
I am still a bit unclear if on non-KDE dekstops xserver will pick up any ic=
c=20
files for the monitor from ~/.local/share/color/icc and load them at start =
up=20
all on its own, or if any additional software is necessary to achieve this.
Thanks again for your help.
[1] http://icc.opensuse.org/
=2D-=20
Regards,
Mick
--nextPart10694771.St1WiPCHgx
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAABCAAGBQJWBrWSAAoJELAdA+zwE4YeKVEH+wSuVAeRypuFNed97k3L42Im
xFtSwDePi6oBj0yMt1HYy5rFLj0CaquicPCwWXm/IZwAm5vV4GYNNDtmoNjk0hrO
QyNvzDx2n7mmSHKmamjFaNr7SfbW072ueYReaOQB4zw4UBdYveVtJoFQ6qJOZ6mh
WVzDkxIvCyMeMKPsQzyLpXAXSGLNfVFbqsM19Wnuu4Wf0p63nJg1qv2a8GwWMJxI
bCJ0/9lvJzivdWrJlQSxEDkQkfx4HhTE3mPAZanGC8tT01kEA3DaOOSOGgoKvXK7
Yq1+vxpQOOCyFeglUam729eZSedNqeZ8PJ/Y2BaBk9hKl9iM9imohCkeOhoGmuE=
=spte
-----END PGP SIGNATURE-----
--nextPart10694771.St1WiPCHgx--