Wayland has no way of doing color management. It would be crazy to move to it while that’s not done. Basically it would mean that anyone doing any graphics, video or vfx work would have to move to another distro.
I’d rather hope that Canonical gets involved there to move things faster because they don’t know what they are doing at all and are learning as they go. None of them are color management experts, most of them haven’t ever made an icc profile.
Just look at this thread: https://discuss.pixls.us/t/wayland-color-management/10804/509
I would like to propose, if i may, that Canonical contacts and gives backing to Graeme W. Gill, the developer of Argyll CMS to make and propose a proper spec and to develop the implementation. He is pretty much the only color management expert who happens to be a developer and who happens to be into Linux. And is Argyll CMS is pretty much the only color management system that we have on Linux today thanks to him.
Let us not adopt something half baked. This has to be solved first.
Basic LUTs are good enough for MOST people using GNU/Linux — and quite frankly there aren’t many pros using Linux for Colour Correction. Linux is mostly used in Render Farms, right? So it’s an edge case and I wouldn’t want this to hold up XWayland/Wayland adoption. Most people doing colour correction these days are on MacOS using Adobe Products.
Pros aren’t using Linux for color correction. They do work that requires color correctness. For example all VFX industry, a portion of movie industry, web design, app design. Do you remember when designers of Adwaita told us it was grey but we could see it was purple? Well, they were early adopters of Wayland and there you go.
If this is not done properly it will impact a lot of people jobs.
Snap, deb, rpm etc numbers are not public, but Gimp Flatpak was downloaded over quarter of a million times.
All of those people need color management.
Add to those all the Blender, Inkscape, Darktable, Rawtherapee, Scribus users etc.
That’s only the FOSS software. How about you pay 9k USD for Nuke license and then find out that Wayland doesn’t have a proper color management. Or how about Houdini, DaVinci Resolve, BorisFX users?
What about the game developers? Unreal, Unity, Godot, CRYENGINE?
People and companies are taking the effort to bring their software to Linux to take advantage of it. Is Wayland going to drive them all away and bring us to square 0?
Countless hours volunteered and paid are being pored into the development of software for Linux for which color management is a critical component. It needs to be done and it needs to be done properly before mass adoption period.
Color management in Wayland has to be at least at the MacOS level before mass adoption. Otherwise it’s better for X to stay and we just skip Wayland because color management will get implemented in Wayland one way or another but if it’s not specd out properly now then it will be hacked later when devs realize they’ve messed up. I don’t like the current Wayland one bit atm. Devs are learning as they go and are refusing to listen to experts in the field which is such a shame because they won’t pay the price, users will.
I’m using Wayland and familiar with LUTs and colour correction having done colour reprodo professionally before retirement. I see no issues, but then I’m not doing professional work. Wouldn’t profiling the monitor be satisfactory? That’s all I would do if I was going to go back to work doing reproduction. If I correct images for white/greyscale they look good on other monitors using other OSes. And I haven’t even profiled my monitor with hardware!
Author: Graeme W. Gill
Date: 7th December 2020
Version: 1.0
This is general, but is writen in the context of adding modern color management
to the Wayland protocol.
R. Requirement
J. Justification/explanation
P. Priority
S. Current status within desktop application programming environments:
M = Supported by Microsoft Windows
A = Supported by Apple OS X
X = Supported by X11 based systems.
R: Applications need to know display pixels colorspace, and
be able to do color transforms into this colorspace for
display on that display device.
Practically this means reference and access to an ICC profile
that defines the colorspace of each display/pixel.
P: Mandatory
X: Some key applications deal with a wide range of source colorspaces,
and their core job is to accurately render these for display.
Sources are as diverse as other RGB colorspaces, CMYK and
higher number of colorant print spaces, named colors, device independent
color specifications, etc. Sources are not necessarily defined by ICC profiles.
(See for instance how PostScript, PDF and XPS allow colors to be defined.)
Accuracy of processing and correct gamut limitation/mapping handling
is only possible with a direct conversion between the native
source colorspace and the display colorspace. Existing application
code assumes this capability is available, and these complex applications
are not trivial to re-write or re-target.
S: M, A, X
R: Applications need to be able to upload & set the profile
that defines a displays colorspace.
P: Mandatory
X: Without this only the grossest problems of non-color managed displays
can be dealt with. Manufacturer supplied profiles are at best generic,
and often misleading when derived from (say) EDID information.
Color sensitive uses of computer systems require calibration and profiling
their specific display in a state of specific adjustment, and
require verification and re-calibration/profiling on a regular basis.
Applications used for calibration and profiling are normal applications
that expect to target the same devlopment environment and API’s as
any other color managed application to be able to do their job.
Like other complex and highly technical applications they are not trivial
to create, maintain or port to new environments.
S: M, A, X
R: System wide default color management. There should be a default source
colorspace that the system will color convert to the display colorspace
if the application doesn’t want to handle the color conversion itself.
P: Desirable
X: Many application writers do not have the necessary knowledge
to deal with color management, and the extra complexity needed
in rendering with color management cannot be justified for many
applications. This capability also allows for applications to work
sucessfully in the face of unanticipated changes in display
characteristics such as wide gamut, HDR etc.
S: A
R: System will honour defacto standard display calibration curves included
in display ICC profiles. Maximum HW precision will be used.
P: Mandatory
X: Although some displays have a capability of setting white point
and brightness progromatically, this is not true for all displays
and is not published, standardized or available via a standard API.
Using graphic card 1D LUTs allows universal and standardized setting of
these key display characteristics, and this is assumed by most
existing display ICC profiles and color management tools.
Additionally it is typicall that frame buffers have a more limited
resolution that the final output of graphics cards/display adapters
(i.e. 8 bit per component frame buffers typically have 10 bit outputs
after 1D lookup tables, 10 bit frame buffers have 12/14 bit 1D LUTs etc.),
and it is desirable to use this to ensure that the more limited precision
of the frame buffer is fully utilized by using the higher precision of
the 1D LUTs to perceptually even the quantization steps out.
S: M, A, X
R: Application is able to set and get display calibration curves
P: Mandatory
X: Display calibration and verification support. See explanation above in 2).
S: M, A, X
R: Application is able to display a rectangular window of pixels
on a chosen display and set un-managed pixel values.
P: Mandatory
X: Display calibration and profiling support. See explanation above in 2).
S: M, A, X
R: Commonly used profiles be readily available to applications
P: Desirable
X: Ties in with 3), as profiles are neede by the system for implementation,
and this allows an application to determine what default system color management
is actually doing.
S: none
R: Support for easy intermixing HDR and SDR displays. This means supplementing
the display and source spaces profile information with HDR profile and handling
details.
P: Highly desirable
X: ICC profiles don’t have complete enough information to convenienly specify
HDR ↔ SDR transformations.
S: none
R: Support global display modifications within the color managed context
for the purposes of applications such as “blue shift” or equivalent.
P: Desirable
X: People use and enjoy such application, and these typically rely on the
availablility of per channel lookp curves in the graphics hardware to do
crude global display modifications. A way of accomodating this while working
harmonously with color management is desirable.
How did the conversation shifted from pipewire to Wayland’s CM problems?
Pipewire is not just about Wayland. It’s the way GNOME will use to provide screencast/grab/sharing on every session, but it’s actually more.
It’s also about audio: a more customizable and efficient alternative to pulseaudio.
About video streams and sandboxed app. The way I understand it is: now a sandboxed version of Zoom to access the camera needs access to /dev/videoN and so this app will be granted access to /dev and this will hinder most of the sandboxing motivation. While, using pipewire, xdg-portal and xdg-app, the GNOME/Red Hat goals are to allow the app to access a pipewire stream after the user agreed. I might be wrong but this is my understanding of what the plan is.
Moreover, when proper pipewire session managers exists, we might have virtual webcam in userspace without using kernel stuff like v4l2-loopback.
Hey dude, nice to see you here too. I want to chime in on this. I need color correctness too. Ubuntu will lose every Blender and Resolve (and pretty much every other creative too) user if you don’t get display basics right.
I will switch distros in an instant if it breaks my workflow. I’m happy on Ubuntu right now. Easypeasy distro. But sh*t got to work or I go where it does.
But you’re not a customer of Ubuntu, are you? It’s free as in beer, so it’s not like you’ve got much invested in this — If you can program, then roll up your sleeves and help is usually the way stuff gets done on FOSS.
What other distro offers colour support that you’re wishing for? I come from a colour background and worked in prepress for many years. The best way to do colour corrections is by using the data - In other words the colour values, not what looks right on YOUR screen. So if you want to aim for Adobe standard, then use those rgb values or whatever. That’s how colour correction has always been done. You aim for a colour value target after it’s been proofed!
It’s not really Ubuntu at fault here. But they could throw their weight a bit on this issue and demand that Wayland meets some color management standards before the defaulting. I think they are defaulting it prematurely and that eventually we’ll end up with a hacked up color management when it’s too late to do it properly.
We’ll see how things progress on this issue.
Assuming much?
Scopes can only get you so far but when developing a creative grade and look for a movie you need to have great color management, monitor, pipeline and you need to use your eyes and develop the look by looking at your monitor having the full confidence that what it shows is correct and accurate. Trust in the display server, application and monitor is crucial.
Oh boy…
I think you are going by what you know and have worked on as a prepress technitian. Trust me when I say that’s just a tiny bit compared to the whole industry that requires great color management. Especially movie, 3D industry and as of lately, really especially, the gaming industry.
We’re looking at the future where we will expand the visual medium even more to the whole other field of fully immersive VR/AR experiences etc. It will be cheap and available. Linux has to be able to handle both the production and reproduction side of that if we are to be at all relevant.
It’s a modern world, Linux is finally catching up. We just need to; not screw it up. Especially by not listening to the experts.
Trust me when I tell you that us Prepress techs wrote the book on colour correction - Doing your type of colour correction is simple compared to the issues compared to putting ink on paper! I do know quite a bit about using colour managed workflows - the colour management genre has many charlatans too - especially in doing monitor calibrations with external calibration devices. Been there, done that.
Colour data values and white/greyscale balance is the ONLY way to do colour correction of any kind, regardless of monitors settings.
Even if developed for Linux, DaVinci Resolve (the video editor and colour grade tool I use) was made with RHEL and CentOS (R.I.P.) in mind and needs some tinkering in order to work with any Ubuntu-based distro.
If Fedora (the closet distro to RHEL for the end user) and Ubuntu (simply the most popular distro) move to Wayland, how will this affect the use of professional tools like DaVinci Resolve? What kind of work would need to be done to work around these issues?
