Qt Contributors Summit 2022 - Program/Color space in Qt - issues and possibilities

Session Summary

• What are color spaces
  • Wide gamut color spaces
  • HDR color spaces
  • "Gamma" curves
    • Why is gamma correction difficult, especially with text
• What can Qt currently do
  • QColorSpace and image transforms
  • Linear color spaces
  • Floating point image formats
• What can't Qt currently do
  • Gamma correct blending
    • Non fast-path text rendering
    • Real instead of platform faked gamma-correction on text fast path
    • Other gamma corrected text painting without linear color spaces
  • Automatic color correction
    • From QImage inputs
    • To QPA outputs (for instance DP3 macs)
• What APIs can we add to help
  • QPainter API
  • QScreen/QSurface API
    • QPA integration
  • QFont API?
  • QColorSpace API
    • XYZ,XYy
    • Luminosity
    • RT2100
    • Double table ICC formats

Session Owners

• Allan Sandfeld Jensen

Notes

(Taken by CristianMaureiraFredes)

The session was based on slides that will be shared afterwards. These are notes on the discussion.

• Comments & Comments
  • Friedemann: Note Qt was mentioned as one library implementing color spaces correctly at Meeting C++ https://meetingcpp.com/mcpp/online/talkview.php?tid=2
  • Nicolas Fella: For colors on Wayland there is https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14
  • Lars Knoll: There is some stuff available there that Laszlo has been working on. I'm using that for Qt MM.
  • Lars Knoll: But it's preview and doesn't work on all platforms.
  • Andy: There is a huge performance impact for software rendering for doing this. And image formats "lie" about the color space as well. It's hard to just expect it to work given a random image file. In Qt Quick 3D we do all the rendering in linear color space and tonemap back out to sRGB space. But all user input via textures colors needs to be converted based on context. Qt Declarative just mixes everything

• • Max: So we could implement some of that on the RHI level?
    • Sure, but we need to check if that would have an impact on performance

• • Lars: comments on the topic of multimedia

we have to be very careful with QPAinter (rendering on sw) things can become too expensive. What you want to do is to render images, but assume linear blending? Alan: yeah, that's considered. Maybe we need a setting to correct that... maybe a setting tool to correct the images on load? other thing...some work on the output side. Some of the rendered colors, you need built-in tone mapping support. We can't get into some colorspaces, but there are limits with HDR colors on screen. without the mapping is saturated. Alan: ack it's expensive, and we need to do it in hw I think Alan: for videos..yeah, in hw. videos go up in luminosity like 5, 10, or 15. Modern macbook HDR 700 nits, if the display is at max bright, then luminosity of 3 you can render properly. for a low surrounding light setting, maybe a factor of 8. You need to get that factor out of the OS, and tone it to that. Alan: we need also the default value for SDR values (windows) I'm using the same in all platforms... Alan: most screens have 200 nits, maximize makes that blurry... for macos they tell you SDR value, then the range that they support on top of that. So a luminosity on 1 is what the max SDR gives you, then you need to cut it off. (Things will be followed up with the changes in multimedia, to gather more insights)

• • Alexandru Croitor: Are there commercial users asking for better color support? It feels like all improvements are done because the developers feel passionate about it, rather than paying users needing it? Which is surprising to me
    • Andy: I think thats correct. Currently customers just make it look good regardless of what we do. Doing it perfectly everywhere will be painful (esspecially in Widgets and 2D Quick, and both painful for us as well as the users in breakages of existing code + performance penalties).
    • Fabian: Well, at least for font rendering, we had bug reports
    • Andy: Ideally we should do all (2D) rendering in linear color space as well and output to whatever is the ideal color space for the output, but there is a cost.

• • Shawn: sounds a bit like hidpi: let's plan for getting it really proper eventually, make sure it can be hardware-accelerated, and try not to have it take 10 years this time
  • Albert Astals Cid: Related to colorspaces but unrelated to this presentation, in KDE we'd super like if QColorSpace had CMYK support. We're trying to support loading CMYK PSD files and it's not great we have to solved it in our side :D https://invent.kde.org/frameworks/kimageformats/-/merge_requests/72wn Rutledge: sounds a bit like hidpi: let's plan for getting it really proper eventually, make sure it can be hardware-accelerated, and try not to have it take 10 years this time

• • Lars: I think correct colorspace handling is needed for our users at least for photos and videos.