
Open Source Color Management Is Broken - helmchenlord
http://www.lieberbiber.de/2018/02/24/open-source-color-management-is-broken/
======
jzl
The complaints in this article appear to be regarding OS-controlled lut
adjustments, i.e. via special X11 features. I've used color calibrated
monitors on linux in color-sensitive industries with hundreds or even
thousands of artist seats (including film, animation, vfx, real-time, etc.)
and the monitor has always been calibrated via the physical menus/buttons on
the bezel and _not_ a software/OS monitor-specific lut adjustment.

I'm not judging which is better or worse as it would indeed be nice if the
calibration could be controlled by the OS. I'm just saying that adjusting the
monitor hardware directly is what's being done in the pro linux content
creation world. Also, I imagine that certain brightness and color gamut
controls could only happen from the bezel controls. Dreamcolors can switch
between srgb & P3 for example.

~~~
appleflaxen
i don't know color management, but it sounds like the situation is analogous
to complaining that VLC on linux doesn't have volume controls (for example; of
course it does in reality...) when the solution is to reach over and twist
your hardware volume knob.

it's good to know that you've found the controls sufficient on the systems you
have adjusted!

------
cratermoon
The Linux community will attempt to solve the problem by attempting to create
an entirely new color management system, which will get at best 80% done with
a handful of outstanding Hard bugs, at least one of which will be bad enough
to break the entire thing except on one specific distro/gui/hardware
combination.

~~~
borplk
It will just be a sub-component of systemd. Named colord.

~~~
bitwize
Hackernews will tell us that we should really be using Wayland, because
Wayland will solve the color problem once and for all.

When it comes time to implement the color management stuff into Wayland, it's
declared out of scope for the core Wayland protocol, but don't worry guys --
someday, somehow, a consortium led by GNOME will implement it on a DBUS
interface that all compositors will understand. At least two, mutually
incompatible, such protocols emerge, neither of which fix the underlying
issues, both of which are tied to particular compositors.

Meanwhile, we are told that X11 is still horribly, irredeemably broken in this
regard and if we haven't yet switched to Wayland, we really should by now.

The professional colorist industry goes on using Xorg on Linux.

------
newnewpdro
It's unclear to me why there's no color palette/correction table exposed in
libdrm/KMS at the kernel. It should just be part of the video mode, maybe with
a bit to indicate when the driver/hardware doesn't support changing it. But
always be able to read it out, make it linear nonsense when the support isn't
there - that won't be worse than what we have now.

Then the layers up the stack like Wayland/X/GNOME/KDE are just messengers
to/from the bottom @ drm.

We also need floating point frame buffers to be first-class citizens at the
KMS level. I don't want to be forced into OpenGL/Vulkan just to be able to
have the hardware apply gamma correction on a software-rendered frame buffer,
and if I have the hardware do color correction, it kind of needs the HDR of
floats - not uchars, which I don't think libdrm supports with dumb buffers of
today. If not floats, at least more bits than 8 per color component.

Programs like Plymouth or other embedded style applications running directly
on libdrm should be able to have color-corrected output without needing
bespoke software implementations and their own calibration tables. I should be
able to tell the kernel the correction table, maybe compile it in, or another
payload on the boot parameters cmdline.

Hell there are fairly well-known simple algorithms for generating approximate
color tables from a single gamma value. If I only want to make things look
"better" in my linux kiosk, and care not about absolute color correctness, let
me stick a drm.gamma=.55 field on the kernel commandline to generate the
correction table in lieu of a full calibrated table.

~~~
braderhart
Have you created it, cause if not then that might explain why what you want in
detail doesn't exist.

~~~
newnewpdro
Is your point that I should get off my ass and do it instead of complaining?

Or is your point that it's substantially more complicated than it appears, and
I'd know that if I tried doing it myself?

~~~
braderhart
Yeah... I think both are applicable, but if you really want something done
then you do it yourself or pay someone to help do it, especially for open
source. It sounds like have a descent idea of where to start. I'd go find some
kernel developers working on the underlying components, and offer to pay them
or see if they have recommendations of people to get the work done.

~~~
newnewpdro
In doing some searches on the subject this [1] came up. So there seems to
already be movement on this front, and it's possible my knowledge of the
current situation is stale.

[1] [https://lists.freedesktop.org/archives/intel-
gfx/2015-Septem...](https://lists.freedesktop.org/archives/intel-
gfx/2015-September/076001.html)

~~~
newnewpdro
There's definitely some level of gamma/color correction funtionality at the
DRM level already in the kernel [1]. So my desires may already be largely
fulfilled, and maybe userspace just needs to get its act together.

[1]
[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i915/intel_color.c)

------
mark-r
If you write the calibration info to the video LUT, why does software also
need to know about it? Isn't your monitor displaying perfectly calibrated sRGB
at that point?

~~~
theatrus2
This is assuming all the content is sRGB, which is not a safe assumption
especially if you care about color management to begin with.

~~~
seba_dos1
If the content is not in sRGB, don't you need to actually know the contents
color profile in order to convert it to sRGB? How does the monitor profile
matter at this point?

(not challenging, just asking, I know next to nothing about color correction)

~~~
wereHamster
You don't want to convert to sRGB, you want to convert to the display device
color space (which in professional displays is often larger than sRGB).

Most desktop environments and applications assume that the source is sRGB,
unless specifically tagged (in image metadata).

So you have two points: source (image, video) and reproduction device
(display, printer etc). And you convert colors from the former to the later.
sRGB may not even come into play if the source image is AdobeRGB and the
display is a wide-gammut pro LCD display!

~~~
mark-r
Does the software know how to bypass the LUT, or do you in effect get a double
conversion?

~~~
wereHamster
which LUT?

------
seba_dos1
> 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
patches - don't know about GNOME, but KDE is pretty friendly and easy to
contribute to.

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

~~~
serf
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."

~~~
pjmlp
Yet the two most successfully desktop experiences among common users, based on
Linux, don't expose any details of its eco-system. Quite telling.

~~~
giovannicarruba
Which two are those?

~~~
pjmlp
ChromeOS and Android.

~~~
giovannicarruba
I have yet to see an Android desktop.

~~~
pjmlp
Easy, get a Chromebook.

[https://sites.google.com/a/chromium.org/dev/chromium-
os/chro...](https://sites.google.com/a/chromium.org/dev/chromium-os/chrome-os-
systems-supporting-android-apps?visit_id=1-636551452624253216-612273770&rd=1)

Or if you prefer to jump on Apple's bandwagon about how regular computers are
outdated, a detachable keyboard and mouse for an Android 10"/12" tablet.

------
unhammer
I've been using the ColorHug 1, and found it worked quite nicely. The included
Fedora CD (yes, this was some time ago) let me calibrate just fine. Once I
wanted to do it straight from XCFE, I ran into a few challenges, but it wasn't
unsurmountable: [https://askubuntu.com/questions/427821/can-i-run-gcm-
calibra...](https://askubuntu.com/questions/427821/can-i-run-gcm-calibrate-on-
xubuntu-without-installing-all-of-gnome) Basically, you have to run xiccd in
the background, since XFCE doesn't have built-in colord support to set the X11
atom[1]. I've never used multiple monitors though, I don't know if that's
possible with xiccd+xfce instead of Gnome.

[1]
[https://bugzilla.xfce.org/show_bug.cgi?id=8559](https://bugzilla.xfce.org/show_bug.cgi?id=8559)

------
cornholio
I think niche market software, used by a limited number of highly specialized
professionals, is somewhat incompatible with the open source economic model.
When a piece of software is used by very many users, and there is a strong
overlap with coders or companies capable of coding, say an operating system or
a a web server, open sources shines: there is adequate development investment
by the power-users, in their regular course of using and adapting the
software, that can be redistributed to regular users for free in an open,
functional package.

At the other end of the spectrum, when the target audience is comprised of a
small number of professionals that don't code, for example advanced graphic or
music editors or an engineering toolbox, open source struggles to keep up with
proprietary because the economic model is less adequate: each professional
would gladly pay, say, $200 each to cover the development costs for a
fantastic product they could use forever, but there is a prisoner dilema that
your personal $200 donation does not make others pay and does not directly
improve your experience. Because the userbase is small and non-software
oriented, the occasional contributions from outside are rare, so the project
is largely driven by the core authors who lack the resources to compete with
proprietary software _that can_ charge $200 per seat. And once the proprietary
software becomes entrenched, there is a strong tendency for monopolistic
behavior (Adobe) because of the large moat and no opportunity to fork, so
people will be asked to pay $1000 per seat every year by the market leader
simply because it can.

A solution I'm brainstorming could be a hybrid commercial & open source
license with a limited, 5 year period where the software, provided with full
source, is commercial and not free to copy (for these markets DRM is not
necessary, license terms are enough to dissuade most professionals from making
or using a rogue compile with license key verification disabled).

After the 5 year period, the software reverts to an open source hybrid, and
anyone can fork it as open source, or publish a commercial derivative with the
same time-limited protection. The company developing the software gets a
chance to cover it's initial investment and must continue to invest in it to
warant the price for the latest non-free release, or somebody else might
release another free or cheap derivative starting from a 5-year old release.
So the market leader could periodically change and people would only pay to
use the most advanced and inovative branch, ensuring that development
investment is paid for and then redistributed to everybody else.

------
gugagore
Is there anyway to display something in Linux without any color management?
Can you access the buffer that gets read directly to the monitor?

I've wanted to know whether two colors I'm displaying actually get
distinguished by the monitor or if the LIST maps then to the same output
value.

------
Bitcoin_McPonzi
Many of my (Hollywood) clients need to do color grading and other accurate
color work.

What platforms do they all use? Not Macintosh, despite its reputation for
being the platform for "graphics professionals" (it was missing 10 bit/channel
color until very recently). And not Linux, despite its use in render farms.

They use Windows 10 and HP DreamColor monitors. That's the only platform that
works and works well for people who need to care about color.

~~~
ancientworldnow
I'm a colorist. Many of us do use windows, many use OSX, many more use Linux.
Every major color critical application supports many types of LUTs and color
management.

Further, HP Dreamcolors have tons of problems and aren't considered solid for
color critical work (but are fine for semi color accurate stuff like
intermediate comps etc). Color accurate work is done over SDI with dedicated
LUT boxes handling the color transforms and the cheapest monitors being $7500
Flanders Scientific Inc 25" OLED panels.

~~~
pvg
_I 'm a colorist_

This sounds pretty interesting. What do you actually do, in layperson-y terms?

~~~
muzfuz
Sit in darkened rooms, spin 3 trackballs, and turn a few knobs to make
pictures look pretty, mostly. DaVinci Resolve[1] and Baselight[2] are quite
popular, take a look at the websites to give yourself an idea of what it looks
like.

1\.
[https://www.blackmagicdesign.com/products/davinciresolve/](https://www.blackmagicdesign.com/products/davinciresolve/)

2\.
[https://www.filmlight.ltd.uk/products/baselight/overview_bl....](https://www.filmlight.ltd.uk/products/baselight/overview_bl.php)

~~~
pvg
Hah, thanks! I should have been a little bit clearer - not an ELI5-layperson,
a layperson who has some vague handwavey idea of how video/film is made and
once read a popular article about orange/teal contrast.

It's more stuff like 'what is it about this process that makes a dedicated
colour specialist necessary?', 'what are the things things they're supposed to
accomplish?', 'what are their technical and creative
constraints/inputs/deliverables?', etc.

~~~
pzone
Check out this YouTube tutorial to see the kinds of things they're doing with
those knobs and panels.

The inputs are roughly "An ordered sequence of footage clips" and the output
is roughly "A final projection/broadcast/download-ready movie"

[https://youtu.be/ojjfhCrjDus](https://youtu.be/ojjfhCrjDus)

------
gigogkggi
This all sounds interesting but I have 0 clue about what the author is talking
about. Can somebody explain what is being talked about, what color calibration
is and all? Not a designer, but a systems programmer. I do understand rgb, hsv
colors but that's it.

~~~
gsich
The author cries about being not able to boot from the USB stick and that his
ColorHug2 might be broken.

~~~
Accacin
He wrote a pretty detailed blog article explaining his issues and how he got
around them, this is all very useful information to someone who is looking to
do something similar.

Spending €100 also isn't an insignificant amount, and for that price I would
expect what I'm buying to work properly.

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

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

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

~~~
rootw0rm
This is one of the more important comments here, imo. Open hardware != free
software. As someone who's been in the unfortunate position of having to work
with locked down chips on many occasions, just simply having access to proper
documentation is awesome. It can take a lot of work and dedication to
interface with open hardware, but we all benefit when the fruits of that labor
are shared. This is a struggle we should all be willing to undertake.

