Use a linear color space when rendering

[10110111]

Historically, Stellarium did all the rendering in nonlinear sRGB color space. This means that all the operations like brightening and blending were done not quite correctly, sometimes leading to serious overshooting of colors, like in bug #3067.

This PR is an attempt to switch the rendering to linear-sRGB color space, i.e. the color space where the primaries and the white point are set to sRGB, but the nonlinear transfer function AKA gamma has not been applied. To achieve this, the following steps are done:

1. Have a separate high-color-depth FBO for linear-color scene rendering
2. When the linear-color scene is ready, blit this FBO to the target framebuffer, applying the sRGB transfer function and dithering
3. To avoid the need for explicit conversion of texture data from sRGB to linear-sRGB inside the shaders, the internal format of the textures is set to GL_SRGB8 or GL_SRGB8_ALPHA8, which makes the hardware perform the conversion when sampling (and additionally, do minification filtering in linear colors).

There's a problem though: in my tests on Intel UHD Graphics 620 with Mesa 21.2.6 in OpenGL ES 2 mode the GL_SRGB8* formats appeared to be not color renderable, which precludes the use of glGenerateMipmap() for them. This in particular makes anisotropic filtering impossible even if we generate the mipmaps manually. The particular objects affected are the Moon, Jupiter, bottom of the old-style landscape (dunno why the sides are not): they become black in the current state of this branch.

The question is whether it's actually a problem in real-life OpenGL ES use cases. Does this problem happen on Windows/ANGLE? What about the small Linux systems where OpenGL ES is the only 3D API? I don't have any hardware to test this, so please try on yours.

[github-actions]

Great PR! Please pay attention to the following items before merging:

Files matching src/**/*.cpp:

• Are possibly unused includes removed?

This is an automatically generated QA checklist based on modified files.

[Atque]

Hm, stars and DSO's look a bit weird (too obvious compared to the master-branch), and the cardinals are no longer red.

Built with Qt 6.4.0, Windows 10 64-bit, RX 5700 XT.

It seems all grids and lines are too bright in color compared to the master.

[10110111]

This is not the final state, some items haven't been fully transformed. I just stumbled upon the problem with GLES2, which may be a blocker for the current approach.

[10110111]

OK, it appears that only GL_SRGB8 format is not color renderable in the problematic GLES2 mode. GL_SRGB8_ALPHA8 gets mipmaps as expected, which explains why only the bottom of the old-style landscape was black.

Moreover, manual specification of isotropically-filtered mipmap levels appears to be sufficient to let even anisotropic filtering work. Looks like the GL implementation does the necessary actions to automagically generate the additional anisotropically-filtered levels from what we specify manually (or maybe this just happens on the fly during texture sampling?).

So, even if the manual specification introduced quality problems, we still can resort to converting our RGB textures to RGBA ones to make things work.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[10110111]

If we ignore the text gamma issue discussed in #3213, I think this PR is ready. Please check that there are no modules left with gamma-incorrect colors, and that this version works on both desktop OpenGL and GLES.

[alex-w]

macOS 13.3.1 / M1

23.1:

this branch:

[10110111]

Even though this isn't going into the soon-to-happen release, I need to know how this PR behaves on Raspberries or any other low-end systems (and see logs from stellarium run with -d option) — to know how to develop this further.

I suspect that we may have to split rendering modes (and visual results) between modernish (GL3.3-capable) systems and these poor ones.

Also, I think we need to drop support for any desktop GPUs that don't support OpenGL 3.3. It's been lots of time since GL3.3 support appeared, and Stellarium has already had a precedent of dropping support for some old GPUs (e.g. Intel Atom's GMA950, which used to work with Stellarium 0.12.4 on Ubuntu 14.04). Extra-small machines as Raspberries we might continue to support, but at least desktops should be required not to be ancient.

[gzotti]

I was away from my device zoo for a good week, and have also other tasks and not enough time for my own PRs....
If we drop non-3.3 systems, we can as well drop Qt5. However, this is a very bad idea IMHO, as many people run low-spec or old PCs for their observatories. The GMA950/3150 was dropped eons ago, with introduction of Qt5 in V0.13 in mid-2014. Many people however still run first-gen Intel-only Core-i (or not even Core-i!) which are blacklisted by Qt w.r.t. OpenGL and use ANGLE or even Mesa. Running non-SMS is less dramatic than not running Stellarium. At earliest drop-out date I would propose October 2025 when Win10 has EOL and a few more functionally critical bugs have been solved. We can however really update the packed versions of Mesa and ANGLE. I have two 1st-gen Core-i systems with build environment (ANGLE), access to one 2008 tri-core AMD Phenom X3 with Geforce 210 (?; runs OpenGL sufficiently; installers only) but nothing still inferior. However, I will again be off my device zoo mid-next week.

Other testers more than welcome!!

[alex-w]

32-bit applications can be produce with Qt5 only, so, we cannot drop support Qt5 at the moment IMHO, but we may planned EOL for 32-bit Stellarium packages

[10110111]

32-bit applications can be produce with Qt5 only

Depends on your will :) I successfully use Stellarium+Qt6 on a Linux-based OS with 32-bit userspace.

we may planned EOL for 32-bit Stellarium packages

Should this maybe be created as a separate issue, so that we could plan there what exactly and when would be dropped?

[alex-w]

32-bit applications can be produce with Qt5 only

Depends on your will :) I successfully use Stellarium+Qt6 on a Linux-based OS with 32-bit userspace.

I don't want self-build Qt6 from source code in cross-platform environment :)

[gzotti]

Please stay reasonable. Building Qt6-32bit just because it's possible is not on our agenda. Again: There are users of older PCs with basic graphics capabilities from the early years of Qt5. Not everybody can afford to just buy a new €600 PC (and €400 PCs are usually really no fun). For those, and all telescope users with equipment for which only older 32-bit ASCOM drivers exist we need 32-bit, Win7-compatible, no-OpenGL3.3 requirement delivered by Qt5. The 0.12 (Qt4) or also the "Stellarium classic" packages (WinXP/32bit) were dropped when download count went into the low thousands. But it is not a problem on Windows only. I know some old-MacOS user who can sadly no longer upgrade. And a few SBCs also are EOL and "final" with Ubuntu 18LTS, but still somewhat useful.

[alex-w]

I know some old-MacOS user who can sadly no longer upgrade. And a few SBCs also are EOL and "final" with Ubuntu 18LTS, but still somewhat useful.

I have many old macs - m68k, ppc and x86 - but I need reinstall macOS onto my old iMac (here was produces packages for MacOS X since 0.10.6) and in theory I can produce a "classic" 32-bit packages for macOS :)

[10110111]

all telescope users with equipment for which only older 32-bit ASCOM drivers exist we need 32-bit, Win7-compatible

OK, no big deal. Though the real reason I see for Qt5 here is Windows 7, not 32-bitness.

no-OpenGL3.3 requirement
Not everybody can afford to just buy a new €600 PC (and €400 PCs are usually really no fun)

Speaking of desktop PCs, one can buy a PCIE OpenGL4-level video card for less than 100$, especially if looking for a used one. And then even a Pentium4-based PC will work with modern Stellarium (provided it has enough RAM). I actually have an experience that a simple PCIE card turned such a PC from junk to an enjoyable machine.

when download count went into the low thousands

Well, we cannot rely on this currently until all Telescope plugin issues with Qt6 are fixed, and the default download link on the main site is replaced with Qt6 version.

Running non-SMS is less dramatic than not running Stellarium

The problem here is that these super-old GPUs hold me back from doing more graphic improvements than just ShowMySky for Stellarium. I'd really not like having to split the graphic engine to legacy+modern.

[Atque]

The problem here is that these super-old GPUs hold me back from doing more graphic improvements than just ShowMySky for Stellarium. I'd really not like having to split the graphic engine to legacy+modern.

Maybe this is the only way if we need to keep support for older systems. A lot of programs have graphics settings such as "low", "high" and "ultra".

[gzotti]

The reason for 32-bit are legacy ASCOM drivers for legacy hardware. This implies Qt5 for all practical purposes, and must such users may not use SMS for efficiency.
The reason for Win7/non-OpenGL3.3 are old computers (desktop+laptops) for many observers and users who don't want or cannot afford upgrades for various reasons. I know, a desktop PC can be revived with cheap GPU and SSD. An old laptop can usually also be revived with an SSD, but is usually limited to its original GPU (or even worse if, like on my otherwise OK-ish little 2010 Core i7-(1stGen) VAIO, the switchable Geforce lost driver support one version upgrade after the Win10 upgrade). I can run 23.1/Qt5/ANGLE on this. The system is faster than my 2015 OpenGL4.2 1GHz AMD netbook of the same size which can run Qt6 with SMS (but non-SMS is way faster here).

Seriously, we should try to identify and fix existing bugs this year before advancing in other areas which finally need to shed off older systems. We have two issues, the location fixes and ObsLists, which should reach completion in 23.2. I hope to have the location fixes done this weekend and try my Raspberries with -d for you while also preparing for a symposium, and hope Alexander can work on ObsList to complete what he sees required. When there is a version without severe bugs/crashes under regular use conditions, we can raise the hardware requirements.

[gzotti]

Here is a log and even screenshot from RPi3. It works, but there are some errors (invalid GL values, and some malloc error at shutdown). There is also now a seam where the texture wraps near the South point.
log.txt

Uh... switched to Guereins landscape (old_style): out of memory. Do you create some extra buffers for this linear CS?
log:Pi3-crashWithOldstyle.txt

[10110111]

There is also now a seam where the texture wraps near the South point

This should also be present in master.

Do you create some extra buffers for this linear CS?

Not sure what CS is, but yes I certainly create a framebuffer that keeps linear-color image. But no, this crappy GPU doesn't succeed in creating it, so effectively no, there's no extra memory use. Maybe the same error would happen on master.

The ugliest part of this RPi3 is this:

No support for sRGB textures found, expect rendering problems!

Can we maybe require RPi4 at least and drop support for RPi3? Though, I still need to make sure that RPi4 actually works, for which I need a log from you.

[gzotti]

Linear CS = Linear ColorSpace

Here is the log of RPi4/UbuntuMate of pr/3156. It also shows errors.
log.txt

It seems the Milky Way is missing. Ah no, it is super dim. Exaggerating 10x and zooming in makes it appear. This needs remix. DSO textures seem OK.

With this linear CS, it appears the extra gamma term in the tonemapper may become unneeded. Now it's too colorful.

[gzotti]

Do you have a Qt5-based build to test on an Core-i5-1stGen with ANGLE? I have no build environment on this one (yet).

[10110111]

It seems the Milky Way is missing. Ah no, it is super dim.

We get QOpenGLFramebufferObject: Unsupported framebuffer format. here, so actually the render is gamma-incorrect. This is also the reason for your super-colorful second screenshot.

But, the list of extensions contains GL_ARB_color_buffer_float. What if you replace the GL_RGBA16 here with GL_FLOAT32F or GL_FLOAT16F? Does anything change?

Do you have a Qt5-based build to test on an Core-i5-1stGen with ANGLE? I have no build environment on this one (yet).

I can push a temporary [publish] commit so that you could get a patch (don't forget to replace the shaders and textures from the source when using it).

[10110111]

You can find Qt5-based patches in this build artifacts after it finishes, if I didn't mess it up.

[gzotti]

Thanks. Here are logs from 23.1 and with this patch. The new version looks again darker/more colorful, and planets are black by shader error. Then, zooming around, nebua texture creation started, and it crashed without further notice.
log_23.1_Corei5-650_Win10_ANGLE.txt
log_23.1+_Corei5-650_Win10_ANGLE_PlanetShaderError_crashLoadingDSOtextures.txt

This is a 2010 PC (Lenovo ThinkCentre) which is otherwise fine (upgraded with SSD), and could perfectly well serve as office or observatory PC. Millions of those should exist. Of course, unsuited for Win11 by MS caprice. Will run Linux in 2025... No Intel OpenGL drivers installed, standard Stellarium fails with OpenGL1.1.

I have no Intel non-Core-i to test cheaper PCs of similar age.

If updating ANGLE and MESA to a later version helps for older PCs, we can do that after release of 23.2.

[10110111]

QOpenGLShader::compile(Fragment): ERROR: 0:170: 'srgbToLinear' : function already has a body 
ERROR: 0:178: 'linearToSRGB' : function already has a body

You seem to have ignored my

(don't forget to replace the shaders and textures from the source when using it)

The patch only contains the EXE. All the resources are still from 23.1 in your installation.

[10110111]

OpenGL ES 2.0 (ANGLE 2.1.99f075dade7c)

This is not going to work in any case. You need the modern ANGLE version I linked above.

[gzotti]

I don't have sources and dev tools on this PC. You mean I should use shaders and textures from sources of your branch? Which exactly? I really have not enough time for much of further testing until after next week, sorry.

Just installed the new ANGLE. Still reports OpenGL ES 2.0.
log.txt

If this means upgrading ANGLE does not help with this still widespread PC class, we have a problem with this.

[10110111]

Just installed the new ANGLE. Still reports OpenGL ES 2.0.

Oh well. OK, so I'll have to somehow split the engine to provide anything new or improving what's already there. This in particular means copy-pasting some files and doing diverging changes to them afterwards.

[10110111]

What if we stop supporting dithering on the machines where OpenGL Core Profile is not available? I.e. on Raspberries etc., in ANGLE mode, in --opengl-compat mode, and the likes. These systems would get the banded image like Stellarium used to have in 2018, but this will help me reduce the amount of code duplication for the further development of the high-graphics mode.