LWN: Comments on "The state of color"

ColorHug

nye — Wed, 27 May 2015 16:17:30 +0000

>Sadly his V1 model didn't live up to expectations for many, the V2 model that is on the way should be better

Do you mean the ColorHug+? That's really not a V2; it's a different device with a different target audience. Suggesting that people should choose it over the original is like saying that people should choose a car over a bicycle: it has broadly the same goal, but a very different set of tradeoffs.

The state of color

halla — Thu, 21 May 2015 13:42:05 +0000

I don't know your code, so I don't know if it works. Heck, I don't recognize your nick, so I don't know who you are and what you're working on. I don't owe you any deep and detailed explanations either. But what the heck...

What I do know is that the icc profiles in X spec is dead as a doornail, just check it: http://www.freedesktop.org/wiki/Specifications/icc_profil.... It's always been a very iffy spec with no two applications interpreting it the same way, so it never worked in practice. Sure, _you_ may feel that _you_ did it right and got it working, but that means zilch if no other application uses it the same way. And it's a dead spec anyway.

As for your goings on about colord being Linux only, and remote X11 displays -- I don't care. There is no reason for me to care. There is nobody using X11 except for Linux users anymore, and there's nothing Linux specific about colord anyway.

If there's anyone left who uses FreeBSD or Solaris or AIX or HPUX or whatever, they can port colord. Maybe they already did, I don't know. And using an application like Krita over a remote connection is a completely ridiculous proposition anway. So, yeah, short and clear: it's not a pity and not a step backwards for Krita to use colord instead of _ICC_PROFILE. It's a step forwards, because Krita now works with multiple moniros for the majority of Linux users (who now have it better than Windows users, who still need to manually configure the monitor profiles).

The state of color

gwg — Thu, 21 May 2015 11:24:31 +0000

> No, it doesn't.
> No, it isn't.

I bow to your deep and detailed explanations.

I guess I'm simply imagining that my code works.

The state of color

halla — Thu, 21 May 2015 08:55:09 +0000

"It works fine using X11 & XRANDR, as mentioned by the OP. "

No, it doesn't.

"That's pity and a real step backward"

No, it isn't.

The state of color

gwg — Thu, 21 May 2015 04:46:09 +0000

> What do we need to improve the color gamut? I don't think it's just a matter of
> raising the range of the phosphors - if the information was provided and stored,
> would adding a yellow phosphor, like Sharp did a couple of years ago, help?

Be careful what you wish for. Wide gamut brings some problems, a main one being
that few desktop UI's are color managed, making for eye-watering garishness.

Handling more than 3 colorants is hard - by most accounts Sharp didn't do this
very well, and there is a lot of complexity added to print systems to handle
the black channel. 3 Color displays with extreme RGB primaries expose issues
with observer variation - you are much more likely to end up in situations
where different people see slightly different color on such a screen.

The state of color

gwg — Thu, 21 May 2015 04:40:43 +0000

> That's true for application that rely on the X11 atom for getting the icc profile: while
> there's > pages out there that suggest that that system works in a multi-monitor setup,
> it doesn't, at all.

It works fine using X11 & XRANDR, as mentioned by the OP.

> However, colord supports multi-monitor support quite well, and that's the reason I
> ported Krita 2.9 > from the X11 atom system to colord, so at least Krita now supports
> per-monitor profiles out of the > box. And I know it works, because I use it with
> the dell/cintiq hybrid companion setup I use to develop Krita :-)

That's pity and a real step backwards. The X11 mechanism is system independent - it will work with any system the X11 server and client are running on, as well as remotely, just as X11 should. In contrast, colord is Linux distro. specific, and some sort of parallel remote connection would be needed for it to work with a remote X11 display.

ColorHug

petur — Fri, 15 May 2015 08:39:13 +0000

Sadly his V1 model didn't live up to expectations for many, the V2 model that is on the way should be better (and more expensive) so if you're going to get a ColorHug, better wait for the new hardware...

The state of color

Tara_Li — Thu, 14 May 2015 15:24:09 +0000

What do we need to improve the color gamut? I don't think it's just a matter of raising the range of the phosphors - if the information was provided and stored, would adding a yellow phosphor, like Sharp did a couple of years ago, help? I know a lot of inkjet printers have gone past CMYK, sometimes adding an orange and purple to the mix to increase their gamut (though like Sharp's TV attempt, it doesn't seem to be a hugely popular thing in part because the source material still tends to be RGB or CMYK...)

The state of color

halla — Thu, 14 May 2015 15:00:37 +0000

That's true for application that rely on the X11 atom for getting the icc profile: while there's pages out there that suggest that that system works in a multi-monitor setup, it doesn't, at all.

However, colord supports multi-monitor support quite well, and that's the reason I ported Krita 2.9 from the X11 atom system to colord, so at least Krita now supports per-monitor profiles out of the box. And I know it works, because I use it with the dell/cintiq hybrid companion setup I use to develop Krita :-)

The state of color

jhoblitt — Thu, 14 May 2015 14:28:04 +0000

One of the difficulties I've encountered with color management is the lack of [any] multi-monitor support by applications. I run 3 wide gamut displays both at home and work. I generate ICC profiles with a colorimeter for each individual display. X handles per display profiles reasonably well via either argyll-dispwin or gnome3. The trouble is that virtually all color aware applications such as firefox, darktable, or gimp only support a single manually set display profile and have no awareness of which display they are rendering on. For my current setup(s) this isn't critical as the displays on each system are identical models with reasonably similar profiles. However, the situation would be painful with mixed response displays.