Wayland color management

Hi,
why not organize a fund baked by end users and sponsors to develop Wayland Color Management fork?
I would love to donate ( even with limited resources ) to this project and i think that the community that work with colors should care about it.

As alternative it could possible maybe to try Epic MegaGrants, for what i understand they are open to free and open source projects :

The color management is not a personal need of few users with a “turbo-tweaked setup” but a necessity of an entire community that work with colors.

5 Likes

I have now taken the time to quickly read through the color management proposal for Wayland discussed in the article @darix linked to previously (Wayland color management - #450 by darix): unstable/color-management/color.rst · color · Sebastian Wick / wayland-protocols · GitLab

What is the objection against that - is it the content or that it is too late and/or not realisticaly happening any time soon? Not a rhetorical question, I’d really like to know.

I am no expert, so I might have gotten it completely wrong, so please correct me when appropriate. Ignoring the HDR part, the protocol seems quite straight forward: Wayland knows the display profiles, for any number of physical displays. Applications either don’t care about color management, in which case their output is considered to be sRGB, or applications can get info on the displays involved from wayland and can specify their own color space to wayland. Wayland will then convert data to an internal color space to do blending and such and then output with the correct profile to the monitor. An application can even target the output color space, and if no blending is involved, the wayland compositor will not change the data at all (with blending it should still produce the same output, just with a roundtrip to the internal color space). Sounds like that should already be enough to accomodate profiling and color managed apps, shouldn’t it?

3 Likes

I do not think you want to be harassed by users, so you should not advocate for harassing other devs either. Please watch your language.

Cooperation often leads to better results than being aggressive.

3 Likes

I guess this is the latest ongoing discussion:

For the invention of GUI see PARC (company) - Wikipedia

The X11 part of colord is a containment for lacking X11 support (at least in part), and arguably something like oyranos would have been preferred (hindsight is 20/20 as they say) alas most software that cared already did their own color-management so oyranos was completely overkill. (especially when gnome decided that colord would be part of their default stack)

The whole point is that Scribus doesn’t have to do that, some initial proposals from the wayland team would have required yes and from your statement you can already imagine the nightmare that would be.

If they want to contribute they are probably more willing to listen these days (especially @swick ) but only because a lot of effort was put explaining (and re-explaining) things up beforehand (and yes that was a tedious and non-rewarding job), although I can understand if they don’t want to anymore given their previous experience.

2 Likes

But what else could everyone here complain about then?

@gwgill just ignores the protocol because it doesn’t do calibration and profiling. He hasn’t given any feedback, never read the actual protocol or design document. If anyone has the NIH syndrome… well, it might be the guy who wants to fork wayland and write his own protocol.

Anyway, I would still appreciate your feedback, @gwgill. Even if you’re insulting everyone left and right (you should consider yourself lucky that some people are still willing to work with you; not everyone I know would).

@anon41087856 where is your input on tone mapping? We have to deal with varying viewing conditions and giving clients enough information to do the mapping on their own and I’m not happy with anything we’ve come up so far.

Also, the protocol has been in a state where you could have experimented with it for a year now. Nobody, literally nobody, has done so. Everyone here claims that this protocol is oh-so-important to their work yet nobody is willing to even read the damn thing and give feedback, much less so making a prototype which actually uses the protocol.

The slow adoption will be much slower if clients are not invested and only give feedback when we declare it stable or someone eventually has to use wayland for some reason. Convince them to get involved. Go to Krita, darktable and whoever else might be interested.

This thread has again become so toxic that I won’t be answering anything here. If you want to get involved you can do so in my wayland-protocols repo where you can open issues for anything or write a mail to the wayland-devel mailing list or to me directly.

9 Likes

Only think missing AFAICT I would say is someway to easily create custom calibration curves which are needed for

  1. Cheap screens that don’t over a lot of controls (looking at laptop screens mostly)
  2. In case someone wants to change the output color space (e.g. display adobe rgb on a nearly 100% DCI-3p screen, if it was an 100% screen we could pre-calculate), though this does get into niche territory

But to be fair that is orthogonal to the current protocol; in a way a full color mangement solution is like the complex plane, where the real axis is applications wanting correct color to the screen and profiling and calibration is the imaginary axis (yes I know it is not imaginary but some stupid mathematician though those numbers would never be useful)

I don’ t blame you it is in part this toxicity that has burned me out, hope to give some feedback soon plus maybe a a try at at calibration/profiling protocol.

How is that niche? I know that it is generally but with people that need color management it probably isn’t. All screens for photography, video and vfx are nearly or 100% DCI-P3 or 99%-100% Adobe RGB.
Eizo, Benq, Asus, LG, ViewSonic all offer many displays like that.
Cameras also offer Adobe RGB and DCI-P3 in addition to sRBG

It’s essential for developing content for cinema projectors etc.

You misunderstood me what I meant is using calibration curves to force a screen that is made to display DCI-3p to display something more constrained (as in for example adobe-rgb or even sRGB), or to put it differently after loading these calibration curves the display will behave as if it has a smaller color space this might be useful in some rare cases. Most people won’t need this because the normal color management can easily take care of the transform from e.g. adobeRGB to DCI-3p, that is what I meant with niche.

2 Likes

Indeed I did. :slight_smile:

I must be missing something but indeed, I don’t see what advantage this would provide?

Besides, if by calibration curves, you are referring to the per-channel GPU gamma tables, those cannot achieve that effect. You need a 3D transform for that, 1D won’t cut it.

1 Like

My .5 cents because I’m in the mood…

But what else could everyone here complain about then?

Honestly, I’m not even so sure. This year has been awful all around outside of anything even remotely related to color management and software development, and I don’t think many people are in the best of moods (I certainly include myself, so yeah you’ll have to deal with me being cranky).

This discussion just continues to irk me.

@gwgill just ignores the protocol because it doesn’t do calibration and profiling.

Well apart from you having to define “ignore”: That surprises you why, exactly? You are aware that he is the author of about the only viable calibration and profiling solution available for Linux, yes? So even if you consider him an “a-hole insulting everyone” (paraphrasing your thoughts probably more than your words), don’t you think that sometimes it might be wise to have a very knowledgeable “a-hole” with decades of experience in his field as an asset (again, talking color management here, not X vs Wayland or some other rather unimportant differences)? This drives me nuts! It’s so short-sighted! An you have the gall to talk about NIH? Heck, he probably was active in the field before some of you were even born! NIH indeed, my frickin’ ass! Ok, calming down…

Anyway, I would still appreciate your feedback, @gwgill. Even if you’re insulting everyone left and right (you should consider yourself lucky that some people are still willing to work with you; not everyone I know would).

Oh come on now, get off your high horse will ya, it’s ridiculous. I’ve met you in person and consider you an aspiring lad, but you’re far too young for THAT level of arrogance, that should be reserved for someone of at least my age :slight_smile: (also, honestly, if I were in Graeme’s shoes, I can tell you that I would not really loose anything if people wouldn’t want to work with me on this, and personally I wouldn’t care that much. And I say this as someone who happily sat down with you and heard you out, and would probably do so again if I were asked. My stance, not his, obviously).

I’ll say it, even though it should be obvious: In this case HE should be an asset to YOU, not the other way 'round (btw, don’t get me wrong, ideally it would go both ways, but I’m only talking about the color management aspects here). Jesus christ. I’ll repeat: There are not many experts in the field (of color management) that also write code and are interested in Linux. You have more to loose by alienating him (which the weird discussions on wayland-devel months ago have already managed to do, even though you were not personally as involved) than the other way 'round. If Wayland was a business and was MY business, I would have dealt with this whole situation differently. And it certainly wouldn’t have included not taking you or anyone else involved with Wayland development seriously, by the way. But alas, I have no stake.

Also, the protocol has been in a state where you could have experimented with it for a year now. Nobody, literally nobody, has done so.

Well, I hope you’re not already out of breath :slight_smile:

This thread has again become so toxic that I won’t be answering anything here

“Toxic” is an overused word, although I’ll have to admit I’ve seen more productive forms of discourse than this thread (but also, far, FAR worse).

Rant over… for now.

3 Likes

Was mostly going on from point 1 and 2 from here: About display monitor settings and targets but yes I did misremember it (was quite a while I read it, and haven’t done much with that knowledge in the last few years) is not a full color space transform but more a tweak to brightness and possibly whitepoint (and maybe to some extend improve non-color managed applications but that is a moot point with full screen color management), still if things like that are done to a “drastic” extend (i.e. not just fixing a cheap laptop screen) it is a somewhat niche use case (though an important one)

Also AFAIK there is some work going on to provide full 3d luts in video cards and there are already options for some expensive reference monitors (this includes external lut boxes).

1 Like

Those only work with SDI input and require proprietary software for MacOS or Windows.
Maybe it exists but I’ve never seen one with USB type-c, Display Port or even HDMI input.

I’m sure one could stack multiple adapters and get something working but I don’t like that kind of jerry rigged solution.

And even then. Those boxes cost as much as EIZO 99% Adobe RGB 16bit monitors

They are also expensive, the point is more that these things exist and was just given as an example of an option (to be fair only an option to people who have way to much money to spend) and yes for 99.9% of the people it is complete overkill and an EIZO monitor would be a much better way to spend their money

1 Like

Rather than critique the proposal in detail, let me point you to this, and you can check it off against each requirement and see how it scores. How does it compare to MSWindows, OS X and X11 ?

The only thing I’ll add is that there seem to be some unnecessarily complexity to it too - I don’t see a need to specify arbitrary additive colorspaces in the protocol itself. If an application needs/wants to do that, you can pretty easily use lcms to construct a profile on the fly to do it.

5 Likes

I’ve looked it over, but I don’t see the point of commenting much on it. You think you are right, and are pursuing an implementation regardless of my opinion or the reasons behind my opinion.

It would be far more rewarding for me to have someone with a better knowledge of Wayland and a reasonable understanding of what color management encompasses to critique and improve my proposed/sketch of a protocol. It appears that such a person doesn’t exist though.

If my intention was to insult people you would know it! : - )
But as always, I’ll call things as I see them, and that may hurt some peoples feelings I guess.

4 Likes

Tone mapping is none of you business, HDR screens use either Dolby PQ OETF or HLG OETF, just provide something to apply a LUT and fill it with those curves. If output supports 10bits, write SDR between 0-255 and HDR between 0-1024. Get that working and we will have some ground to fight surround light/Bartleson-Breneman effect with a proper CAM, which is much more difficult than applying a profile. Meanwhile, people have a hardware backlight dial.

2 Likes

That was my initial thought as well, but: Developing Wayland Color Management and High Dynamic Range