Color matching?

On Thu, 26 May 2016 21:56:06 -0700, isw wrote:

In article ,
Eric Stevens wrote:

On Wed, 25 May 2016 21:03:13 -0700, isw wrote:

In article ,
Bill W wrote:

On Wed, 25 May 2016 13:43:57 -0700, isw wrote:

In article , Me
wrote:

On 25/05/2016 16:09, isw wrote:
Apologies if this is not the right group; seemed like a good shot to
me
...

I'm trying to match some colors in an X11 environment. I pulled up
the
Wikipedia article on the subject:

https://en.wikipedia.org/wiki/X11_color_names

Found some colors I liked, copied the hex values into some code I
didn't
write but was tying to make look a bit better, and looked at the
resulting colors.

Which weren't the same as the color blocks in the article.

Worse, when I went probing with a "digital color meter" app that
samples
pixels on the screen, the RGB values from the Wikipedia page and the
ones put up by the program I'm running were not the same either --
that
is, the RGB hex values I read for the colors were not the ones I'd
typed
in, and also did not match the color blocks on the web page.

This was on a Mac, but it seems to me that whatever color
inaccuracies
or "translations" the machine was doing, it should do the same thing
both times.

So, can someone enlighten me as to why the color values were
different?

Isaac

Is your monitor calibrated?

I don't see how that could matter since whatever it's adjustment is, it
should be the same on the right-hand side of the screen (where the
Wikipedia page was) and the left-hand side (where the colors I was
adjusting were).

My understanding from some previous discussion here is that some
browsers also adjust the colors under some conditions. So if the
colors on the r/s were in a browser, and the l/s colors were in
another app, that could explain it.

Doesn't explain why, when I measured the RGB values on the screen, they
did not match the numbers I typed in to get those very colors.

Either because it has been transformed to a different color space or
it's using an ICC profile to correct what it believes to be color
display errors. Whatever, something is changing the original data for
some reason or other.

Well, yes; obviously. I'm trying to find out what, exactly, is doing
that.

And it can be bloody (Australian) frustrating.
--

Regards,

Eric Stevens

In article , isw
wrote:

I really doubt
that the browser's "color management" (so called) was changing those.

it was.

everything on a mac is colour managed. even finder icons.

The "those" I was referring to were the text letters and numbers
describing the color patches (i.e. #5F9EA0). No OS will reach in and
change those.

any os that is properly designed will.

In article , isw
wrote:

If you've adjusted it so it doesn't render untagged images by default in
sRGB and is using aRGB or whatever, then they will be displayed
incorrectly and will measure incorrectly from a screen grab.

When I run the "Digital Color Meter" app over the color patches in the
browser window, it displays exactly the RGB hex values specified for
that particular patch.

So far so good.

The app I'm trying to adjust uses X11, FWIW. It reads a text document
that specifies the colors for certain objects it displays. Being an
X11/gtk environment, it understands the color "names" as well as the hex
triplets (i.e. "Cadet Blue" or "#5F9EA0" will produce the same result).

there's the problem.

The problem is that when I enter either of those into the controlling
document and then run the app, the color that comes up on the screen, as
read by the Color Meter is *not* "#5F9EA0"; it is "#779D9F" (when the
meter is set to "Display native values"; it has other color spaces too,
but none of them produces a match either).

rgb is device dependent. #5F9EA0 is meaningless without an output
profile, which means it *will* change.

if you want a specific colour that's not dependent on a particular
device, use lab.

What I'm trying to find out is where the change to the hex values is
taking place, and why.

it's taking place because everything on the mac is colour managed.

I have noticed similar "mismatches" between apps before, but have never
taken the time to pursue the problem.

it's not a problem. it's the way it's supposed to work.

Meanwhile, I have some "special words" for the X11/gtk people ...

why are you bothering with x11? it's garbage and always has been.

On Wed, 25 May 2016 13:43:57 -0700, isw wrote:

In article , Me
wrote:

On 25/05/2016 16:09, isw wrote:
Apologies if this is not the right group; seemed like a good shot to me
...

I'm trying to match some colors in an X11 environment. I pulled up the
Wikipedia article on the subject:

https://en.wikipedia.org/wiki/X11_color_names

Found some colors I liked, copied the hex values into some code I didn't
write but was tying to make look a bit better, and looked at the
resulting colors.

Which weren't the same as the color blocks in the article.

Worse, when I went probing with a "digital color meter" app that samples
pixels on the screen, the RGB values from the Wikipedia page and the
ones put up by the program I'm running were not the same either -- that
is, the RGB hex values I read for the colors were not the ones I'd typed
in, and also did not match the color blocks on the web page.

This was on a Mac, but it seems to me that whatever color inaccuracies
or "translations" the machine was doing, it should do the same thing
both times.

So, can someone enlighten me as to why the color values were different?

Isaac

Is your monitor calibrated?

I don't see how that could matter since whatever it's adjustment is, it
should be the same on the right-hand side of the screen (where the
Wikipedia page was) and the left-hand side (where the colors I was
adjusting were).

W3C uses sRGB as its assumption, don't know if it pulls an embedded
profile into sRGB

your left side might use a different configuration than W3C

don't know if the wikipedia set uses W3C

a named color might be better to choose from, there are probably
monitor palettes from the vendor of the named colors


And yes, it is calibrated, using Apple's built-in procedure.

Isaac

calibration is not characterization, characterization is where you get
a profile from that is compatible with the translation of your color
management system, calibration in the color management sense is just a
steady state to characterize from

--
Dale
http://www.dalekelly.org

On Thu, 26 May 2016 22:07:30 -0700, Bill W
wrote:

On Thu, 26 May 2016 21:56:06 -0700, isw wrote:

In article ,
Eric Stevens wrote:

On Wed, 25 May 2016 21:03:13 -0700, isw wrote:

In article ,
Bill W wrote:

On Wed, 25 May 2016 13:43:57 -0700, isw wrote:

In article , Me
wrote:

On 25/05/2016 16:09, isw wrote:
Apologies if this is not the right group; seemed like a good shot to
me
...

I'm trying to match some colors in an X11 environment. I pulled up
the
Wikipedia article on the subject:

https://en.wikipedia.org/wiki/X11_color_names

Found some colors I liked, copied the hex values into some code I
didn't
write but was tying to make look a bit better, and looked at the
resulting colors.

Which weren't the same as the color blocks in the article.

Worse, when I went probing with a "digital color meter" app that
samples
pixels on the screen, the RGB values from the Wikipedia page and the
ones put up by the program I'm running were not the same either --
that
is, the RGB hex values I read for the colors were not the ones I'd
typed
in, and also did not match the color blocks on the web page.

This was on a Mac, but it seems to me that whatever color
inaccuracies
or "translations" the machine was doing, it should do the same thing
both times.

So, can someone enlighten me as to why the color values were
different?

Isaac

Is your monitor calibrated?

I don't see how that could matter since whatever it's adjustment is, it
should be the same on the right-hand side of the screen (where the
Wikipedia page was) and the left-hand side (where the colors I was
adjusting were).

My understanding from some previous discussion here is that some
browsers also adjust the colors under some conditions. So if the
colors on the r/s were in a browser, and the l/s colors were in
another app, that could explain it.

Doesn't explain why, when I measured the RGB values on the screen, they
did not match the numbers I typed in to get those very colors.

Either because it has been transformed to a different color space or
it's using an ICC profile to correct what it believes to be color
display errors. Whatever, something is changing the original data for
some reason or other.

Well, yes; obviously. I'm trying to find out what, exactly, is doing
that.



Try different browsers.

W3C uses sRGB
--
Dale
http://www.dalekelly.org

In article ,
nospam wrote:

In article , isw
wrote:

If you've adjusted it so it doesn't render untagged images by default in
sRGB and is using aRGB or whatever, then they will be displayed
incorrectly and will measure incorrectly from a screen grab.

When I run the "Digital Color Meter" app over the color patches in the
browser window, it displays exactly the RGB hex values specified for
that particular patch.

So far so good.

The app I'm trying to adjust uses X11, FWIW. It reads a text document
that specifies the colors for certain objects it displays. Being an
X11/gtk environment, it understands the color "names" as well as the hex
triplets (i.e. "Cadet Blue" or "#5F9EA0" will produce the same result).

there's the problem.

The problem is that when I enter either of those into the controlling
document and then run the app, the color that comes up on the screen, as
read by the Color Meter is *not* "#5F9EA0"; it is "#779D9F" (when the
meter is set to "Display native values"; it has other color spaces too,
but none of them produces a match either).

rgb is device dependent. #5F9EA0 is meaningless without an output
profile, which means it *will* change.

if you want a specific colour that's not dependent on a particular
device, use lab.

I'm slightly familiar with that; I've used it in GIMP. Do you know a way
to coerce gtk into using L*a*b?

What I'm trying to find out is where the change to the hex values is
taking place, and why.

it's taking place because everything on the mac is colour managed.

I have noticed similar "mismatches" between apps before, but have never
taken the time to pursue the problem.

it's not a problem. it's the way it's supposed to work.

Meanwhile, I have some "special words" for the X11/gtk people ...

why are you bothering with x11? it's garbage and always has been.

Yup; I agree. Felt that way for a long time. But the app I need to use
runs in the X11 environment, so I'm kind of stuck. It came with a
tasteless color scheme ("designed" by the programmers, probably), that
the actual user hates, so I'm trying to make it better for her.

But if, as you say, "everything on the mac is colour managed", why does
the Color Meter give the "right" answer in the browser window, but not
in the X11 one? Is it because color is actually *not* managed when using
X11?

Isaac

In article ,
Bill W wrote:

On Thu, 26 May 2016 21:56:06 -0700, isw wrote:

In article ,
Eric Stevens wrote:

On Wed, 25 May 2016 21:03:13 -0700, isw wrote:

In article ,
Bill W wrote:

On Wed, 25 May 2016 13:43:57 -0700, isw wrote:

In article , Me
wrote:

On 25/05/2016 16:09, isw wrote:
Apologies if this is not the right group; seemed like a good shot
to
me
...

I'm trying to match some colors in an X11 environment. I pulled up
the
Wikipedia article on the subject:

https://en.wikipedia.org/wiki/X11_color_names

Found some colors I liked, copied the hex values into some code I
didn't
write but was tying to make look a bit better, and looked at the
resulting colors.

Which weren't the same as the color blocks in the article.

Worse, when I went probing with a "digital color meter" app that
samples
pixels on the screen, the RGB values from the Wikipedia page and
the
ones put up by the program I'm running were not the same either --
that
is, the RGB hex values I read for the colors were not the ones I'd
typed
in, and also did not match the color blocks on the web page.

This was on a Mac, but it seems to me that whatever color
inaccuracies
or "translations" the machine was doing, it should do the same
thing
both times.

So, can someone enlighten me as to why the color values were
different?

Isaac

Is your monitor calibrated?

I don't see how that could matter since whatever it's adjustment is,
it
should be the same on the right-hand side of the screen (where the
Wikipedia page was) and the left-hand side (where the colors I was
adjusting were).

My understanding from some previous discussion here is that some
browsers also adjust the colors under some conditions. So if the
colors on the r/s were in a browser, and the l/s colors were in
another app, that could explain it.

Doesn't explain why, when I measured the RGB values on the screen, they
did not match the numbers I typed in to get those very colors.

Either because it has been transformed to a different color space or
it's using an ICC profile to correct what it believes to be color
display errors. Whatever, something is changing the original data for
some reason or other.

Well, yes; obviously. I'm trying to find out what, exactly, is doing
that.

Try different browsers.

The browser (Firefox) gives correct results; I doubt that using a
different one would help.

Isaac

In article ,
nospam wrote:

In article , isw
wrote:

I really doubt
that the browser's "color management" (so called) was changing those.

it was.

everything on a mac is colour managed. even finder icons.

The "those" I was referring to were the text letters and numbers
describing the color patches (i.e. #5F9EA0). No OS will reach in and
change those.

any os that is properly designed will.

OK; I'll bite: name one.

Isaac

In article , isw
wrote:


The problem is that when I enter either of those into the controlling
document and then run the app, the color that comes up on the screen, as
read by the Color Meter is *not* "#5F9EA0"; it is "#779D9F" (when the
meter is set to "Display native values"; it has other color spaces too,
but none of them produces a match either).

rgb is device dependent. #5F9EA0 is meaningless without an output
profile, which means it *will* change.

if you want a specific colour that's not dependent on a particular
device, use lab.

I'm slightly familiar with that; I've used it in GIMP. Do you know a way
to coerce gtk into using L*a*b?

this might work:
http://www.gpick.org

the real question is why are you torturing yourself using x11 apps?
there are much better options available, ones that aren't user-hostile.

What I'm trying to find out is where the change to the hex values is
taking place, and why.

it's taking place because everything on the mac is colour managed.

I have noticed similar "mismatches" between apps before, but have never
taken the time to pursue the problem.

it's not a problem. it's the way it's supposed to work.

Meanwhile, I have some "special words" for the X11/gtk people ...

why are you bothering with x11? it's garbage and always has been.

Yup; I agree. Felt that way for a long time. But the app I need to use
runs in the X11 environment, so I'm kind of stuck.

why do you need to use that particular app?

It came with a
tasteless color scheme ("designed" by the programmers, probably), that
the actual user hates, so I'm trying to make it better for her.

the best way to make it better is ditch x11 entirely.

even with exactly the colours you want, you're still stuck with x11 and
a poorly designed app.

But if, as you say, "everything on the mac is colour managed", why does
the Color Meter give the "right" answer in the browser window, but not
in the X11 one? Is it because color is actually *not* managed when using
X11?

dunno. it could be a bug or it could be to maintain compatibility with
x11 on other systems.

In article , isw
wrote:

I really doubt
that the browser's "color management" (so called) was changing those.

it was.

everything on a mac is colour managed. even finder icons.

The "those" I was referring to were the text letters and numbers
describing the color patches (i.e. #5F9EA0). No OS will reach in and
change those.

any os that is properly designed will.

OK; I'll bite: name one.

mac os x.

as i said, rgb triplets are device dependent, so a properly written os
*must* modify them based on the output device, otherwise things will
look wrong.