Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open Source Color Management Is Broken

lieberbiber.de

Post reply on HN
Print view View original

51–60 of 129 posts

Re: Open Source Color Management Is Broken

#51

Post by zeta0134 »

LeoNatan25 wrote: post #38
userbinator wrote: post #36

Earlier quoted context omitted.

...and it'll be difficult to turn off for those not in the professions named in the other comments here which require accurate colour, using monitors with smaller gamuts, and would much prefer to have the "raw", "unmanaged" behaviour.

What does “unmanaged” even mean? Anyone should strive to have as accurate colors as possible.

Actually, a lot of us that don't work in the design space would be perfectly happy if our monitors simply had close enough to the same white between our dual screens. I absolutely do not care how color accurate my JavaScript code actually is in my editor, I would love to have the ability to manually tweak the balance so my monitors more or less render the same.

Right now, Linux just can't do that consistently. Most of the existing solutions want me to buy a very expensive color calibration tool that I can't justify or afford.

Re: Open Source Color Management Is Broken

#52

Post by coldtea »

userbinator wrote: post #47
LeoNatan25 wrote: post #38

Earlier quoted context omitted.

What does “unmanaged” even mean? Anyone should strive to have as accurate colors as possible.

Mapping directly into the full gamut of the monitor, the way that almost every common computer did before the whole "color management" stuff even became a thing. Anyone should strive to have as accurate colors as possible. No, people have different needs and set their monitors' brightness and contrast accordingly. It's only the mentioned industries which require that accuracy --- and the associated, often very expens…

>No, people have different needs and set their monitors' brightness and contrast accordingly. It's only the mentioned industries which require that accuracy --- and the associated, often very expensive, monitors and calibration equipment.

Except for accessibility reasons (e.g. high contrast for the visually impaired), there are no "different needs" that dictate that people should see colors rendered falsely compared to their reference if they're not in the creative professions.

Re: Open Source Color Management Is Broken

#53

Post by coldtea »

giovannicarruba wrote: post #42
LeoNatan25 wrote: post #38

Earlier quoted context omitted.

What does “unmanaged” even mean? Anyone should strive to have as accurate colors as possible.

Did you just assume my color space preferences?

No, parent just asserted that there are no "color space preferences" (outside of accessibility) people should have, period (and if they do have, OS/software makers and monitor companies should be OK to ignore them).

Re: Open Source Color Management Is Broken

#54

Post by seba_dos1 »

giovannicarruba wrote: post #35
seba_dos1 wrote: post #20

Earlier quoted context omitted.

I don't understand that attitude, that's a pretty low price for a niche open hardware device.

It's not. An Eizo EX3 sells for 85 bucks here, a Spyder 5 for 95. A ColorHug2 amounts to 115. Since the ColorHug2 doesn't include the actual calibration software, it is equal to the EX3. Paying 35% more just for the "Open Hardware" label and then not being able to reap the expected benefits (better support etc.) doesn't sound like a good deal.

It is.

Better support? Open Hardware means Open Hardware, and nothing more - you get the access to the schematics, documentation, sometimes also right to produce similar devices by yourself. You can expect greater hackability, definitely, but "Open Hardware" sticker means nothing in terms of support or reliability. It might be better, it might be worse, you can't tell.

The price in such projects is directly related to the production scale. How many EX3s, Spyders and ColorHugs have been produced? Open Hardware projects (especially the equivalents of already available non-free devices) are often costlier because it initially attracts only the people who really care about its hackability, which makes the yields low, which makes the prices high, which further strengthens that relation, and the circle is closed.

With userbase kept small, most users usually keep the firmware/software support just right enough to scratch their own itches.

Please remember that hardware is not software, and open hardware comes with completely different set of challenges than free (open) software and when it comes to hardware, you often really need to pay extra for the freedom - not just with your time, like we were used to with early FLOSS, but also with your money. If you choose a project because of its "Open Hardware" sticker, it's really more than likely that it will be costlier and it will be rough at edges, because it's usually harder to roll with such projects than with closed competitors and the ROIs are usually way smaller too. That's just how it is and there's nothing surprising about it; if you care about openness, you have to accept it, otherwise it will never get better.

Re: Open Source Color Management Is Broken

#55

Post by coldtea »

serf wrote: post #29
pjmlp wrote: post #25

Earlier quoted context omitted.

Not everyone is a developer, and this type of comments is why everyone that cares about UI/UX design professionally, eventually goes back to Windows or macOS.

That type of comment is also the underlying reason why Linux improves/fixes things at such an astronomical rate compared to either of the choices you listed. It's not just saying "Hey you, go fix that." , it's saying "Hey everyone viewing this comment on a public page : this exists and needs to be fixed. Someone grab a wrench."

>That type of comment is also the underlying reason why Linux improves/fixes things at such an astronomical rate compared to either of the choices you listed.

Huh? Linux is behind both Windows and OS X in most non-server related areas. They can't even agree on a good compositor...

Re: Open Source Color Management Is Broken

#56

Post by coldtea »

pzone wrote: post #50
coldtea wrote: post #49

Earlier quoted context omitted.

> Every large visual effects studio runs on linux, with hundreds of linux workstations at each one. Color sensitive work like lighting and compositing has been done for well over a decade on linux. That's for rendering, where the OS and Desktop experience doesn't really matter, and the cheaper it is the better. Few pros do the actual editing and color work (where the decisions are made, not the rendering part) on Lin…

That's not right - Linux is used on desktop workstations as well. Check out the discussion in this recent thread. https://www.reddit.com/r/linux/comments/7zms77/gnome_2_spott...

For 3D yes.

Re: Open Source Color Management Is Broken

#57

Post by GhostVII »

LeoNatan25 wrote: post #38
userbinator wrote: post #36

Earlier quoted context omitted.

...and it'll be difficult to turn off for those not in the professions named in the other comments here which require accurate colour, using monitors with smaller gamuts, and would much prefer to have the "raw", "unmanaged" behaviour.

What does “unmanaged” even mean? Anyone should strive to have as accurate colors as possible.

> Anyone should strive to have as accurate colors as possible

Why is that? I like to have my monitors with a bit of a warmer colour balance, since it is nicer on my eyes, and I have no need for 100% colour reproduction. I think that everyone should strive for the most comfortable colours as long as they aren't doing photo editing or something.

Re: Open Source Color Management Is Broken

#58

Post by seba_dos1 »

pjmlp wrote: post #25
seba_dos1 wrote: post #11

> Except that they only set it for the primary output. Turns out if you have multiple displays, the profile for the first one is put into the _ICC_PROFILE X11 atom, but the profile for the second one in the _ICC_PROFILE_1 X11 atom, for the third display in the _ICC_PROFILE_2 X11 atom, and so on. It’s just that nobody seems to do this. Sounds like an easy thing to fix. I'd suggest the author to try and make some patch…

Not everyone is a developer, and this type of comments is why everyone that cares about UI/UX design professionally, eventually goes back to Windows or macOS.

...and this type of replies is why it stays that way.

Well, at least when ignoring the UI/UX mention that has absolutely nothing to do with the discussion here (color correction is required in many fields, but UI and UX aren't really those ones).

The author seems to be technical enough to make a nice analysis of what's done and what needs to be done. I suspect he might be able to provide this particular fix himself - or, if he isn't, then he might be able to contribute by providing a well-detailed feature request for others to implement (with that even I might be able to go and fix it, while without it I surely won't, as I lack the knowledge, hardware and in fact even awareness of this problem; only reading this post put some light on it for me).

Some people don't do the mental switch between "I'll wait for fix" and "I'll fix it" if they're not used to it, even if they are perfectly capable of fixing it and have time for it. I see it on my own example, as there were some parts of the stack I never really considered digging into to fix stuff by myself, and when I finally tried, turned out there was no reason to keep myself restrained. It's just a friendly reminder that you can often fix such stuff by yourself and it might be not as hard as it seems.

Re: Open Source Color Management Is Broken

#59

Post by ancientworldnow »

coldtea wrote: post #49
AboutTheWhisles wrote: post #39

Earlier quoted context omitted.

Every large visual effects studio runs on linux, with hundreds of linux workstations at each one. Color sensitive work like lighting and compositing has been done for well over a decade on linux. Artist workstations are calibrated and every major computer graphics application has support for look up tables.

> Every large visual effects studio runs on linux, with hundreds of linux workstations at each one. Color sensitive work like lighting and compositing has been done for well over a decade on linux. That's for rendering, where the OS and Desktop experience doesn't really matter, and the cheaper it is the better. Few pros do the actual editing and color work (where the decisions are made, not the rendering part) on Lin…

This is just not true, you're spreading misinformation. I am a colorist, I'm the person making these final decisions. Every single high end color suite I've ever been in runs Linux. In fact, the full version of Baselight (one of the defacto color correction suites) only runs on Linux. DaVinci Resolve (one of the other major ones) ran only on Linux for the majority of it's existence and the full panel version (the pro choice) only ran on Linux until last year.

Every major color house I've worked in runs Linux exclusively in their suites (CO3, The Mill, Technicolor, etc).

That's not to say windows and OSX suites don't exist, I use them and my own suite runs windows, but the highest end of color is basically Linux only.

Re: Open Source Color Management Is Broken

#60

Post by hughsient »

seba_dos1 wrote: post #11

> Except that they only set it for the primary output. Turns out if you have multiple displays, the profile for the first one is put into the _ICC_PROFILE X11 atom, but the profile for the second one in the _ICC_PROFILE_1 X11 atom, for the third display in the _ICC_PROFILE_2 X11 atom, and so on. It’s just that nobody seems to do this. Sounds like an easy thing to fix. I'd suggest the author to try and make some patch…

Not an easy thing. The ICC-in-X specification specifies the index as the Xinerama screen number, which has no meaning with XRANDR-on-XOrg, and even less meaning on Wayland. There's nothing in the protocol to tie the ID to a monitor, or even a predictable hotplug order. This is why the device-id in colord exists.

Source: colord author.

Post reply on HN