[gentoo-user] CMYK comparison to sRGB between platforms

[gentoo-user] CMYK comparison to sRGB between platforms

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 881 bytes --]

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?

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[wraeth]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/09/15 04:42, Mick 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?

While I'm certainly not an expert on this sort of thing, one key piece
of information that would affect this is what software you used.
Specifically, did you use the same software on each platform
(therefore the same method of conversion)?

- -- 
wraeth <wraeth@wraeth.id.au>
GnuPG Key: B2D9F759
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlXvZewACgkQXcRKerLZ91k1FgD/SGsgaIev8ryxjXZPbb84tswc
4FKX3QCqMcOzeDwbciEA+wdjNr//nepKXeN1fZa04/GfgwfYVvlFNyAqiTQqsQzx
=j+0r
-----END PGP SIGNATURE-----

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

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1942 bytes --]

On Tuesday 08 Sep 2015 23:49:21 wraeth wrote:
> On 09/09/15 04:42, Mick 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?
> 
> While I'm certainly not an expert on this sort of thing, one key piece
> of information that would affect this is what software you used.
> Specifically, did you use the same software on each platform
> (therefore the same method of conversion)?

The conversion from CMYK to sRGB was performed on Linux.  The user 
experimented with different CMYK.icc and sRGB.icc files using imagemagick and 
also Gimp.  Then the original CMYK and resultant sRGB files were moved around 
different PCs and OS and their difference observed.  The difference was more 
prominent in a MacBook Pro, next (almost equally) visible in MSWindows 7 
either run natively or in a VM and finally least visible difference (you had 
to squint to see it) was in the Linux PCs.

The only common thing between the Linux PCs was that they are both running 
Gentoo but have different radeon cards & different firmware.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Peter Humphrey]

On Tuesday 08 September 2015 19:42:08 Mick wrote:

--->8

> 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?

Have you calibrated your monitors? That seems to be the first thing to do. I 
bought a device six months ago and it's transformed my viewing experience:

	http://www.hughski.com/

(Usual disclaimer.)

-- 
Rgds
Peter

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

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1469 bytes --]

On Wednesday 09 Sep 2015 09:28:54 Peter Humphrey wrote:
> On Tuesday 08 September 2015 19:42:08 Mick wrote:
> 
> --->8
> 
> > 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?
> 
> Have you calibrated your monitors? That seems to be the first thing to do.
> I bought a device six months ago and it's transformed my viewing
> experience:
> 
> 	http://www.hughski.com/
> 
> (Usual disclaimer.)

The desktop has two monitors, of different ages and quality.  However, the 
difference between images I'm referring to in this thread, is visible on the 
*same* monitor when using MSWindows (either natively or within a VM), but much 
less so on Linux.  I've tried to make the two monitors' colours look similar, 
but the old Dell monitor has a lot more red in it which I can't take out using 
the hardware adjustments.

I have been thinking to buy one of these little measuring devices and now may 
be a good time.

Would you mind explaining how it works?  You measure the icc of a monitor - 
what do you do with this then?  Do you need to be running something like 
colord all the time to feed some correction data to xranrd?

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Peter Humphrey]

On Wednesday 09 September 2015 14:41:19 Mick wrote:
> On Wednesday 09 Sep 2015 09:28:54 Peter Humphrey wrote:
> > On Tuesday 08 September 2015 19:42:08 Mick wrote:
> > 
> > --->8
> > 
> > > 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?
> > 
> > Have you calibrated your monitors? That seems to be the first thing to do.
> > I bought a device six months ago and it's transformed my viewing
> > 
> > experience:
> > 	http://www.hughski.com/
> > 
> > (Usual disclaimer.)
> 
> The desktop has two monitors, of different ages and quality.  However, the
> difference between images I'm referring to in this thread, is visible on the
> *same* monitor when using MSWindows (either natively or within a VM), but
> much less so on Linux.  I've tried to make the two monitors' colours look
> similar, but the old Dell monitor has a lot more red in it which I can't
> take out using the hardware adjustments.
> 
> I have been thinking to buy one of these little measuring devices and now
> may be a good time.
> 
> Would you mind explaining how it works?  You measure the icc of a monitor -
> what do you do with this then?  Do you need to be running something like
> colord all the time to feed some correction data to xranrd?

I'll have to go through the process again because I can't remember. (Six 
months? Not a chance!)

I'll let you know when I've done it; probably tomorrow.

-- 
Rgds
Peter

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

[Peter Humphrey]

On Wednesday 09 September 2015 14:41:19 Mick wrote:

> Would you mind explaining how it works?  You measure the icc of a monitor -
> what do you do with this then?  Do you need to be running something like
> colord all the time to feed some correction data to xranrd?

You get a live DVD (Fedora) with the calibration program and some user notes. 
The device comes with a strap to hold it against the middle of the screen, and 
a 6' USB lead. The measuring process is straightforward, though complicated 
for me by the fact that my screen is LED, not LCD. Still, I told it to treat 
it as an LCD and the result, though a bit bright for my eyes, appears accurate 
enough. It also knows about CRTs and projectors.

Once the calibration is complete (about 10 minutes for the standard 
calibration) you have to copy the .icc directory from ~/.local/share to a USB 
stick or something, then reboot into your usual system and double-click on the 
file in your GUI file manager. That transfers the data to the monitor, 
apparently permanently.

Simple, once you get out of the habit of using the CLI. Well, it would be, 
except that I had to run:

$ Find / -iname \*.icc 2> /dev/null
$ mv .local/share/icc .

Then I could see the icc folder in the file manager and drag it to the USB 
stick.

As for double monitors, the calibration program on the DVD asks you to choose 
the monitor to calibrate, so it can detect more than one at a time, but I 
don't know how transferring the .icc in the main system would work with two 
monitors. You might have to download and install the client tools.

HTH.

-- 
Rgds
Peter

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

[Rich Freeman]

On Tue, Sep 8, 2015 at 2:42 PM, 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.
>

If everything is working correctly then the CMYK original and sRGB
copy should look identical, with the exception of any out-of-gamut
colors (as I understand it, very little of CYMK is out-of-gamut for
sRGB).

If they're not identical then something is wrong, so I wouldn't assume
that Linux is at fault (though it could be if the file looks wrong
when created on Linux and viewed on another OS, and both OSes are
using calibration).

Imagine if your original email read like this:

On the same hardware I noticed that when I saved my simple OpenOffice
document in MS Word format in Linux, and then opened the MS Word file,
the text was identical.  I tried doing the same thing on both Windows
and OSX and in both cases there were lots of weird symbols in the text
of the document.  What is wrong with my Linux OpenOffice program? Why
doesn't it mke my dcment lok lik ths like the other OSes?

or like this:

On the same hardware I noticed that when I copied a file from a fat32
USB stick to an ext4 USB stick the md5sum of the files remained
unchanged.  However, if I perform the copy on OSX or Windows the
md5sum changes.  What is wrong with my linux filesystem drivers?  Why
doesn't it randomly modify my data when I try to copy it?  And, darn
it, why does it seem like I never have to reboot the thing to keep it
from crashing?

Now if one OS or another isn't properly calibrated to your monitor the
same file could have different appearances, and if for whatever reason
your viewer for the CYMK file applies calibration data differently
than the viewer for the sRGB file that would also cause issues.  So,
the problem might be in the viewing of the files, or in the
conversion.  Based solely on the testing you performed I can't really
be sure which if any of your conversions are being done correctly.
The file might appear unchanged on Linux but it could be a result of
cancelling errors in the creation and rendering of the file.

However, since the whole goal of the conversion process is to avoid
making visible changes to the file to the greatest degree possible,
I'd tend to look at the other OSes for problems first.

-- 
Rich

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

[wabenbau]

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

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

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 7204 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Peter Humphrey]

On Saturday 26 September 2015 16:11:04 Mick wrote:

> 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!

--->8

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

As far as I remember, it's the colorhug's own program that sets the monitor at
the end of its calibration process. After that, the monitor has kept those
settings and hasn't needed any further tweaking.

I do have the two .icc files in .local/share/icc:

$ ls -l .local/share/icc
total 28K
-rw-r--r-- 1 prh prh 1.2K Sep  9 16:51 edid-fbec4f9c1804ea718b6e1b585fc234ad.icc
-rw-rw-r-- 1 prh prh  21K Sep 10 10:41 GCM - Samsung - SMS27A350H - unknown (2015-09-10) [04-58-44].icc

/usr/bin/file shows them both as "ColorSync ICC Profile". I don't know why there
are two, nor why they have such different sizes.

Maybe I'm mistaken and KDE is reading what it needs at startup from those
Files. I'll try moving them and see what happens.

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

Yes, I'm also unclear on this.

-- 
Rgds
Peter

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

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 3831 bytes --]

On Sunday 27 Sep 2015 09:58:43 Peter Humphrey wrote:
> On Saturday 26 September 2015 16:11:04 Mick wrote:
> > 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!
> 
> --->8
> 
> > 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.
> 
> As far as I remember, it's the colorhug's own program that sets the monitor
> at the end of its calibration process. After that, the monitor has kept
> those settings and hasn't needed any further tweaking.
> 
> I do have the two .icc files in .local/share/icc:
> 
> $ ls -l .local/share/icc
> total 28K
> -rw-r--r-- 1 prh prh 1.2K Sep  9 16:51
> edid-fbec4f9c1804ea718b6e1b585fc234ad.icc -rw-rw-r-- 1 prh prh  21K Sep 10
> 10:41 GCM - Samsung - SMS27A350H - unknown (2015-09-10) [04-58-44].icc
> 
> /usr/bin/file shows them both as "ColorSync ICC Profile". I don't know why
> there are two, nor why they have such different sizes.

I'm guessing that the 'edid-fbec4f9c1804ea718b6e1b585fc234ad.icc' was 
extracted from your monitor's EEPROM chip through the i2c bus and saved on 
disk by the LiveCD you ran, but the 'GCM - Samsung - SMS27A350H - unknown 
(2015-09-10) [04-58-44].icc' was generated by the colorimeter during your 
calibration exercise.

I'm also guessing that the smaller size of the first file is because your 
monitor's EDID is of an earlier version, e.g. EDID-v1.1 or some such, which 
used to only contain a 128-byte data structure.  I seem to recall that very 
early EDID versions didn't even contain colospace and Gamma data, but may be 
wrong.

These are the sizes :

ls -n ~/.local/share/color/icc/devices/Display/
total 800
-rw-r--r-- 1 1001 1001   1944 Sep 18 18:16 ACI ASUS VS239 
EALMTF200702_edid.icc
-rw-r--r-- 1 1001 1001   2016 Sep 18 18:16 Dell Computer DELL ST2320L 
MP82K0712EJL_edid.icc
-rw-r--r-- 1 1001 1001  20884 Sep 18 19:01 P2311H 2012-06-20 2.2 MQ-HQ 
3xCurve+MTX.icc
-rw-r--r-- 1 1001 1001 783804 Sep 18 19:02 PA248 2015-04-18 S XYZLUT+MTX.icc

The first two are from the monitors' EDID content, the latter are the profiles 
I downloaded from the Taxi DB.  Some of these contributors' profiles were 
created with spyder or other expensive colorimeters, so I am surmising that 
they capture more data points and contain more information, than the 
manufacturers EDID which is primarily contains other than colorspace and Gamma 
data.


> Maybe I'm mistaken and KDE is reading what it needs at startup from those
> Files. I'll try moving them and see what happens.
> 
> > 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.
> 
> Yes, I'm also unclear on this.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Peter Humphrey]

On Sunday 27 September 2015 10:47:51 Mick wrote:
> On Sunday 27 Sep 2015 09:58:43 Peter Humphrey wrote:
> > I do have the two .icc files in .local/share/icc:
> > 
> > $ ls -l .local/share/icc
> > total 28K
> > -rw-r--r-- 1 prh prh 1.2K Sep  9 16:51
> > edid-fbec4f9c1804ea718b6e1b585fc234ad.icc -rw-rw-r-- 1 prh prh  21K Sep 10
> > 10:41 GCM - Samsung - SMS27A350H - unknown (2015-09-10) [04-58-44].icc
> > 
> > /usr/bin/file shows them both as "ColorSync ICC Profile". I don't know why
> > there are two, nor why they have such different sizes.
> 
> I'm guessing that the 'edid-fbec4f9c1804ea718b6e1b585fc234ad.icc' was
> extracted from your monitor's EEPROM chip through the i2c bus and saved on
> disk by the LiveCD you ran, but the 'GCM - Samsung - SMS27A350H - unknown
> (2015-09-10) [04-58-44].icc' was generated by the colorimeter during your
> calibration exercise.
> 
> I'm also guessing that the smaller size of the first file is because your
> monitor's EDID is of an earlier version, e.g. EDID-v1.1 or some such, which
> used to only contain a 128-byte data structure.  I seem to recall that very
> early EDID versions didn't even contain colospace and Gamma data, but may be
> wrong.

I've just visited the Taxi site you mentioned to see what's there for my 
monitor. Nothing! So I tried uploading my ColorHug data. The page asked for a 
metadata file and a profile data file, from which I supposed that my smaller file 
is metadata about the content of the larger one. But when I tried to upload 
the two files on that assumption I got a server error. Same when I tried them 
the other way round.

Looking at the larger file with less, I find eight lines of binary data at the 
head followed by 400-odd lines of legible textual data. Interesting stuff, 
though of course I don't know what to do with it myself.

> These are [Mick's] sizes :
> 
> ls -n ~/.local/share/color/icc/devices/Display/
> total 800
> -rw-r--r-- 1 1001 1001   1944 Sep 18 18:16 ACI ASUS VS239
> EALMTF200702_edid.icc
> -rw-r--r-- 1 1001 1001   2016 Sep 18 18:16 Dell Computer DELL ST2320L
> MP82K0712EJL_edid.icc
> -rw-r--r-- 1 1001 1001  20884 Sep 18 19:01 P2311H 2012-06-20 2.2 MQ-HQ
> 3xCurve+MTX.icc
> -rw-r--r-- 1 1001 1001 783804 Sep 18 19:02 PA248 2015-04-18 S 
XYZLUT+MTX.icc
> 
> The first two are from the monitors' EDID content, the latter are the
> profiles I downloaded from the Taxi DB.  Some of these contributors'
> profiles were created with spyder or other expensive colorimeters, so I am
> surmising that they capture more data points and contain more information,
> than the manufacturers EDID which is primarily contains other than
> colorspace and Gamma data.

Lucky you! As I said, my monitor hasn't made it into the database yet. And it 
seems I can't contribute to it either.

-- 
Rgds
Peter

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

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 3357 bytes --]

On Sunday 27 Sep 2015 11:50:54 Peter Humphrey wrote:
> On Sunday 27 September 2015 10:47:51 Mick wrote:
> > On Sunday 27 Sep 2015 09:58:43 Peter Humphrey wrote:
> > > I do have the two .icc files in .local/share/icc:
> > > 
> > > $ ls -l .local/share/icc
> > > total 28K
> > > -rw-r--r-- 1 prh prh 1.2K Sep  9 16:51
> > > edid-fbec4f9c1804ea718b6e1b585fc234ad.icc -rw-rw-r-- 1 prh prh  21K Sep
> > > 10 10:41 GCM - Samsung - SMS27A350H - unknown (2015-09-10)
> > > [04-58-44].icc
> > > 
> > > /usr/bin/file shows them both as "ColorSync ICC Profile". I don't know
> > > why there are two, nor why they have such different sizes.
> > 
> > I'm guessing that the 'edid-fbec4f9c1804ea718b6e1b585fc234ad.icc' was
> > extracted from your monitor's EEPROM chip through the i2c bus and saved
> > on disk by the LiveCD you ran, but the 'GCM - Samsung - SMS27A350H -
> > unknown (2015-09-10) [04-58-44].icc' was generated by the colorimeter
> > during your calibration exercise.
> > 
> > I'm also guessing that the smaller size of the first file is because your
> > monitor's EDID is of an earlier version, e.g. EDID-v1.1 or some such,
> > which used to only contain a 128-byte data structure.  I seem to recall
> > that very early EDID versions didn't even contain colospace and Gamma
> > data, but may be wrong.
> 
> I've just visited the Taxi site you mentioned to see what's there for my
> monitor. Nothing! So I tried uploading my ColorHug data. The page asked for
> a metadata file and a profile data file, from which I supposed that my
> smaller file is metadata about the content of the larger one. But when I
> tried to upload the two files on that assumption I got a server error.
> Same when I tried them the other way round.
> 
> Looking at the larger file with less, I find eight lines of binary data at
> the head followed by 400-odd lines of legible textual data. Interesting
> stuff, though of course I don't know what to do with it myself.
> 
> > These are [Mick's] sizes :
> > 
> > ls -n ~/.local/share/color/icc/devices/Display/
> > total 800
> > -rw-r--r-- 1 1001 1001   1944 Sep 18 18:16 ACI ASUS VS239
> > EALMTF200702_edid.icc
> > -rw-r--r-- 1 1001 1001   2016 Sep 18 18:16 Dell Computer DELL ST2320L
> > MP82K0712EJL_edid.icc
> > -rw-r--r-- 1 1001 1001  20884 Sep 18 19:01 P2311H 2012-06-20 2.2 MQ-HQ
> > 3xCurve+MTX.icc
> > -rw-r--r-- 1 1001 1001 783804 Sep 18 19:02 PA248 2015-04-18 S
> 
> XYZLUT+MTX.icc
> 
> > The first two are from the monitors' EDID content, the latter are the
> > profiles I downloaded from the Taxi DB.  Some of these contributors'
> > profiles were created with spyder or other expensive colorimeters, so I
> > am surmising that they capture more data points and contain more
> > information, than the manufacturers EDID which is primarily contains
> > other than colorspace and Gamma data.
> 
> Lucky you! As I said, my monitor hasn't made it into the database yet. And
> it seems I can't contribute to it either.


Contributing is more involved than simply downloading a profile.  I think you 
have to use the TaxiDB API:

http://sourceforge.net/p/openicc/taxi/ci/master/tree/docs/api_doc.txt

I you are interested then you can contact the OpenICC project to ask for 
details:

 http://www.freedesktop.org/wiki/OpenIcc/

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Peter Humphrey]

On Sunday 27 September 2015 12:36:27 Mick wrote:

> Contributing is more involved than simply downloading a profile.  I think
> you have to use the TaxiDB API:
> 
> http://sourceforge.net/p/openicc/taxi/ci/master/tree/docs/api_doc.txt

Hm. I see what you mean.

> I you are interested then you can contact the OpenICC project to ask for
> details:
> 
>  http://www.freedesktop.org/wiki/OpenIcc/

I'll go and explore a bit, and report back if I find anything interesting.

-- 
Rgds
Peter