Hi all,
As Fedora 34 try to use PipeWire by default to replace PulseAudio (https://fedoraproject.org/wiki/Changes/DefaultPipeWire), I think Ubuntu should consider the switch also. I wanted to try pipewire (0.3.15) on Ubuntu 21.04 (dev) without luck, because all documentation is for Fedora, and I can’t make it default, btw there’s a newer package (0.3.18) from pipewire. Can somebody help me how can I try it on Ubuntu? What are the necessary steps?
Marked of ‘Low Importance’. I do hope Ubuntu gets serious about Wayland, soon.
Sounds like the desktop team has no choice soon: “GNOME Shell will start depending on it in the next release and this is what is going to pull it in main.” (https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/1802533/comments/30)
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!
No
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.
S: A