5 ms·

That's not where it stops... wayland was designed without giving any thought to color management at all. Beware, long read ahead, not happy ending: https://disc

by M1nase 5y ago

That's not where it stops... wayland was designed without giving any thought to color management at all. Beware, long read ahead, not happy ending: https://discuss.pixls.us/t/wayland-color-management/10804 https://discuss.pixls.us/t/wayland-color-management/10804 I will abandon Linux on desktop after ~20 years if that happens. Once upon a time we had a browser with real color management (firefox)... and lost it. Now it seems that time has come to other things as well.

kaba0 5y ago
https://www.collabora.com/news-and-blog/blog/2020/11/19/developing-wayland-color-management-and-high-dynamic-range/ https://www.collabora.com/news-and-blog/blog/2020/11/19/deve... Not sure about the current state but there was some initiative to implement it. And as far as I know, the deliberately lean protocol will easily allow for this extension, that’s the cool part of Wayland.
- magicalhippo 5y ago
  Wayland was released in 2008. In 2008 color management should not be an afterthought for something which entire purpose is to ensure pixels end up on the screen, but rather an integral component. Having a bunch of pixels with no knowledge of which color space they're in is useless.
  - pierrebai 5y ago
    You think that color management belongs in the window manager / compositor. Wayland thinks color management belongs in the app. The main difference, though, is not this disagreement, but your righteous insistence that your opinion is not an opinion but a very simple obvious fact. I can tell you from having been part of many dev teams of many major app having to do color management that such apps really, really like to be in control. So no, the lack of color management in wayland is not such an obvious wrong decision. It's debatable, with pros and cons.
    - magicalhippo 5y ago
      My point is, regardless of who does what when it comes to color management Wayland simply cannot be agnostic about it. At least since it wants to touch pixel data. Alternatively they could have given up on that and never introduced wl_buffer, leaving all the buffer management and drawing up to the client. edit: At least HDR has finally made Wayland devs wake up and smell the coffee. A good write-up here[1], with ongoing talk in the merge request[2]. Lots of good work going on there, but should be part of core and not an extension. Maybe it's time for Wayland2 soon? [1]: https://ppaalanen.blogspot.com/2020/11/developing-wayland-color-management-and.html https://ppaalanen.blogspot.com/2020/11/developing-wayland-co... [2]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
      - kaba0 5y ago
        Why does it matter that it is merged into an extension that will become core, or it was already core at inception? It is hard to get everything right at once, so starting small is not bad, imo. Wayland has a really sane way of extension querying so it is not like clients will suffer due to these — they are already written in a way to query the capabilities.
        magicalhippo 5y ago
        > Why does it matter that it is merged into an extension that will become core, or it was already core at inception? > Wayland has a really sane way of extension querying so it is not like clients will suffer due to these A client shouldn't be able to use Wayland without considering the color space of the pixels it's providing. By not having it in core from day one, there's already apps out there which will need patching to work properly. Here's[1] a random Wayland hello world example I found. It memcpy's the image it wants to display into a wl_buffer. What color space is that pixel data in? How can this work correctly without changes when the Wayland color management protocol lands? [1]: https://github.com/emersion/hello-wayland/blob/master/main.c#L130 https://github.com/emersion/hello-wayland/blob/master/main.c...
- nsajko 5y ago
  > the deliberately lean protocol will easily allow for this extension, that’s the cool part of Wayland. That's a strange way to look at it. It's more like the Wayland folks decided that basically everything of import is out of scope of the protocol. This way any graphical system built on top of Wayland is ridiculously inelegant, but hey, at least there is no responsibility on Wayland itself.
vanviegen 5y ago
> Once upon a time we had a browser with real color management (firefox)... I remember that episode... at some point it was basically impossible to display an image that uses the exact same color as some color used in your CSS. Lot's of logos with just the wrong. I'm sure the web platform could be extended to properly support color management in some way, but what Firefox did back than wasn't it.

by M1nase 5y ago

kaba0 5y ago

https://www.collabora.com/news-and-blog/blog/2020/11/19/developing-wayland-color-management-and-high-dynamic-range/ https://www.collabora.com/news-and-blog/blog/2020/11/19/deve... Not sure about the current state but there was some initiative to implement it. And as far as I know, the deliberately lean protocol will easily allow for this extension, that’s the cool part of Wayland.

magicalhippo 5y ago
Wayland was released in 2008. In 2008 color management should not be an afterthought for something which entire purpose is to ensure pixels end up on the screen, but rather an integral component. Having a bunch of pixels with no knowledge of which color space they're in is useless.
- pierrebai 5y ago
  You think that color management belongs in the window manager / compositor. Wayland thinks color management belongs in the app. The main difference, though, is not this disagreement, but your righteous insistence that your opinion is not an opinion but a very simple obvious fact. I can tell you from having been part of many dev teams of many major app having to do color management that such apps really, really like to be in control. So no, the lack of color management in wayland is not such an obvious wrong decision. It's debatable, with pros and cons.
  - magicalhippo 5y ago
    My point is, regardless of who does what when it comes to color management Wayland simply cannot be agnostic about it. At least since it wants to touch pixel data. Alternatively they could have given up on that and never introduced wl_buffer, leaving all the buffer management and drawing up to the client. edit: At least HDR has finally made Wayland devs wake up and smell the coffee. A good write-up here[1], with ongoing talk in the merge request[2]. Lots of good work going on there, but should be part of core and not an extension. Maybe it's time for Wayland2 soon? [1]: https://ppaalanen.blogspot.com/2020/11/developing-wayland-color-management-and.html https://ppaalanen.blogspot.com/2020/11/developing-wayland-co... [2]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
    - kaba0 5y ago
      Why does it matter that it is merged into an extension that will become core, or it was already core at inception? It is hard to get everything right at once, so starting small is not bad, imo. Wayland has a really sane way of extension querying so it is not like clients will suffer due to these — they are already written in a way to query the capabilities.
      - magicalhippo 5y ago
        > Why does it matter that it is merged into an extension that will become core, or it was already core at inception? > Wayland has a really sane way of extension querying so it is not like clients will suffer due to these A client shouldn't be able to use Wayland without considering the color space of the pixels it's providing. By not having it in core from day one, there's already apps out there which will need patching to work properly. Here's[1] a random Wayland hello world example I found. It memcpy's the image it wants to display into a wl_buffer. What color space is that pixel data in? How can this work correctly without changes when the Wayland color management protocol lands? [1]: https://github.com/emersion/hello-wayland/blob/master/main.c#L130 https://github.com/emersion/hello-wayland/blob/master/main.c...
nsajko 5y ago
> the deliberately lean protocol will easily allow for this extension, that’s the cool part of Wayland. That's a strange way to look at it. It's more like the Wayland folks decided that basically everything of import is out of scope of the protocol. This way any graphical system built on top of Wayland is ridiculously inelegant, but hey, at least there is no responsibility on Wayland itself.

vanviegen 5y ago

> Once upon a time we had a browser with real color management (firefox)... I remember that episode... at some point it was basically impossible to display an image that uses the exact same color as some color used in your CSS. Lot's of logos with just the wrong. I'm sure the web platform could be extended to properly support color management in some way, but what Firefox did back than wasn't it.