Color matching?

On Fri, 27 May 2016 21:20:17 -0700, isw wrote:

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

might want to try sci.engr.color or sci.image.processing
--
Dale
http://www.dalekelly.org

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.

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.

You didn't read what I wrote. I was talkingabout the *text* of the RGB
values, i.e. "#FFA566" no OS will modify those *in the text*.

Isaac

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.

You didn't read what I wrote. I was talkingabout the *text* of the RGB
values, i.e. "#FFA566" no OS will modify those *in the text*.

you said you were using the digital color meter utility to read the
displayed triplets, which has gone through a profile conversion and
won't match the values you typed in.

In article ,
nospam wrote:

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?

I need an accounting app that (1) runs on MacOS x 10.7, (2) can import
"Quicken" files, (3) print checks, (4) is *not* Quicken, and (5) doesn't
cost much.

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

I looked around pretty carefully,and GnuCash is the only thing that fit
the bill. Any suggestions that you *know* will work, I'll be happy to
look at.

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

Whatever else, GnuCash is free, and is actually not, as you state,
"poorly designed"; it merely came with a poor set of colors in the UI,
and that has been fixed -- whether or not I understand all the
color-matching issues.

Isaac