New DSO marker colour problems

[Menno5]

Expected Behaviour

Clear distinctive color differences in default DSO marker colours like in V 23.1.

Actual Behaviour

Washed out, harder to see difference in default DSO marker colours in V 23.2.

In the DSO colour settings of V 23.2, the colour of galaxies is set to the same Red as in V 23.1. But onscreen in V 23.2 this is now a kind of soft red with what looks like a white overlay or background line.
The same goes for example for the blue of interacting galaxies: in V 23.1 a distinctive blue, in V 23.2 a washed out blue that is very hard to see. Setting this to "hard blue" gives a kind of purple colour.
So it's very hard to set colours in V 23.2 because the colour settings do not result in the same colours onscreen for the DSO markers.

See screenshot.
On top are the default colours of DSO markers of a clean install of V 23.1.
Below that the default colours of DSO markers of a clean install of V 23.2.

System

• Stellarium version: stellarium-23.2-qt6-win64.exe
• Operating system: Windows 11, latest up to date version
• Graphics Card: MSI RTX 2080 TI Gaming X Trio / NVidia driver, version 536.40

[alex-w]

Please check color settings for DSO markers - you should have something like this:

[10110111]

I don't reproduce. The second screenshot looks as if the red markers are duplicated with white color.

[gzotti]

Yes, I also see that. But how can this happen? Any driver settings you can think of?

[alex-w]

Yes, I also see that. But how can this happen? Any driver settings you can think of?

I can't see the issue on macOS. Would you share DSO color settings?

[Menno5]

As extra info: I first thought it was because I did update from 23.1 to 23.2. But like mentioned, with fresh installs the difference between 23.1 and 23.2 is there also.
I also did check driver settings just in case but everything is fine there. I use my system for a lot of graphical things, and programs like Photoshop for sure would be effected when something was wrong.
To be sure, I also tried a fresh install of the qt5 version, but here also "washed out" colors.

Here a comparison between the 2 versions. They are both the same in the settings as you can see, but not on screen somehow.

[Menno5]

Did some more testing.
For the screenshot below, I changed the color for galaxies to a reddish color. This gives white DSO galaxy markers while in the settings it's clearly reddish.
I did also test the color settings of the Markings and gave the Equatorial Grid the same color as the default DSO galaxy color (#fe3333) and the grid is showing just fine in red like in V 23.1 there where galaxies with #fe3333 are showing the washed out red.
So it seems to be isolated to the DSO Marker colours?

[10110111]

tried a fresh install

Does "fresh install" mean that you wipe your settings on uninstalling, so the subsequent install is clean?

So it seems to be isolated to the DSO Marker colours.

Could you uncheck all irrelevant items in the View/DSO dialog, and filter out by type irrelevant objects? I still suspect that somehow you have duplicated data somewhere, maybe turning off some of these items would make it clearer which ones look white.

Also, please attach Stellarium log file.

[Menno5]

Does "fresh install" mean that you wipe your settings on uninstalling, so the subsequent install is clean?

Yes, wiped all. I only made a backup (saved in different location) of my Observing List but did not import that yet.

Could you uncheck all irrelevant items in the View/DSO dialog, and filter out by type irrelevant objects? I still suspect that somehow you have duplicated data somewhere, maybe turning off some of these items would make it clearer which ones look white.

I unchecked all and then only checked PGC. These are then in the washed out red and yellow colours.
Checked IC only and here too washed colours. But only for the oval indicators, the symbols for a planetary nebula and the Ha Regions though, are in normal bright green colour?

I also did a complete uninstall and then searched for any leftover data on my drives and also in the Registry but nothing showed up, there is no left over data.

Attached the log file.
log.txt

[Menno5]

Just in case, here also a log with OpenGL diagnostics.

OpenGL-log.txt

[alex-w]

@10110111 any news?

[10110111]

Until I can reproduce it, there won't be any news. Currently I can't.

[alex-w]

I can reproduce the issue partially in Windows

[10110111]

What do you mean by partially?

[alex-w]

What do you mean by partially?

See marker and color for active galaxy for example

[10110111]

From your JPEG I can't tell the exact color due to color ringing artifacts. Screenshots should use lossless compression to be most useful, e.g. PNG.

[alex-w]

[10110111]

So, the object you chose is #ff8033, which is the default color of active galaxies. The buttons as rendered in this GUI are quite misleading regarding the color they represent, so I can't match them with the actual marker. But if you didn't change the setting, the render seems correct. You can check in the actual color picker and compare with what PixelTool or other screen magnifier tells you.

[gzotti]

Is the slight color mismatch between color button and galaxy marker due to your translation of the latter to a linear color space?
Else this screen looks OK. The white galaxies are odd but we have no further information.

[10110111]

Is the slight color mismatch between color button and galaxy marker due to your translation of the latter to a linear color space?

Nothing is being translated to linear color space, we haven't merged any related change. The buttons are just rendered as tinted gradients instead of the exact flat colors that they should have. It's a UX problem that should be fixed, but it's unrelated to the current marker issue.

[alex-w]

Hmm... in this case the issue in StelDialog::connectColorButton()

[10110111]

Why? What exactly is the issue? In the screenshot everything looks OK.

[gzotti]

Maybe there are tweaks to how the color button can be rendered. Something without pseudo-3D effect or gradient. But this is indeed a different (and purely cosmetic) issue from this one.

[Menno5]

Why? What exactly is the issue? In the screenshot everything looks OK.

HI
The issue is still the same as my 2 screenshots with the first posting on top of this page. Those are PNG images.
With exactly the same pallets, most of the colors of DSO's in 23.2 are washed out in comparison to 23.1.

I did test some more including zooming in on screenshots in Photoshop and like mentioned before, it looks like there is some kind of white "ghost" over or under the DSO marker, giving it a washed out look.

[10110111]

The issue is still the same as my 2 screenshots with the first posting on top of this page.

Yes, the problem is that no one of the developers can reproduce it on their machines to be able to debug.

[Menno5]

If there is anything I can do other then the earlier provided log, just let me know? I'm no coder whatsoever but I can work with instructions.
For now I did just adjust the colors in the settings, so it looks fine. The only weird thing indeed is that the color in the settings/pallet looks different then the DSO colors showed.

[Menno5]

Thought I mentioned this but did see I didn't. Maybe it helps?

When un-checking the Labels and Markers checkbox, there is an animated effect where all the markers slowly disappear.
When that happens, the color goes from washed out to not washed out (so the right red is then there) to no markers and labels.
The other way around: check the checkbox, markers are slowly appearing to the not washed out red and then to to the washed out red.
This all in a fluid way, so it's not in an instant changing color.

[alex-w]

Hello @Menno5!

Please check the fresh version (development snapshot) of Stellarium:
https://github.com/Stellarium/stellarium-data/releases/tag/weekly-snapshot

[Menno5]

Hi Alex

Installed and all set to default settings.
The colors are washed out. The blue marker of an Interacting Galaxy for example is not clear if it's light blue or light green.
There is a difference now though when checking and un-checking the Labels and Markers checkbox: only the labels are now fading out or in. The colors of the markers are switched on or off,

Did check again if any other colors are effected as well but that's still not the case: grid lines, celestial sphere, cardinal points, etc. are the colors they are suppose to be, not washed out.
This is still the best way to check the difference: set for example the Meridian line to color #fe3333 (the default color for Galaxies) and the difference is there.

[alex-w]

Please show screenshots

[10110111]

OK I've been able to reproduce this, but apparently, it only happens on NVIDIA GPUs with multisampling disabled. Doesn't happen on Intel UHD Graphics 620 regardless of multisampling setting, and doesn't happen on NVIDIA with multisampling enabled.

Also, if I enable Proportional hints option, I can see an interesting structure in the enlarged ellipses: looks like the line segments that it's made of have pale-colored ends, while the bulk is correctly colored. See the screenshot below.

[10110111]

Also reproduces on Intel with --opengl-compat option. Apparently, the problem is that GL_LINE_SMOOTH works badly with line loops and strips due to the way each line is rendered: without computing sample coverage, instead using a simple single-line algorithm that simply blends the line into the framebuffer oblivious of the adjacent lines.

Not sure how exactly we should fix this. On the one hand, it's the first time we stumbled upon this problem, so disabling line smoothing (in the legacy, non-multisampling way) for strips and loops doesn't seem like a good idea. But OTOH, it seems too ad hoc to localize this logic in Nebula's renderers (ellipse is not the only primitive with this problem).

What do you think?

[github-actions]

Hello @Menno5!

OK, developers can reproduce the issue. Thanks for the report!

[alex-w]

Smooth via shaders?

[10110111]

Smooth via shaders?

No, it's not feasible in principle, the result would be similarly bad as GL_LINE_SMOOTH, for the same reasons. Only multisampling works well (or supersampling, but this is much costlier and not needed here).

[Menno5]

Good to see there is an idea now :)
But here there is no difference when I enable or disable multisampling. At least, not in the Nvidia Control panel.

Another thing I noticed just now: when the option Use outlines for big deep-sky objects is enabled, a bunch of galaxies are then suddenly the right red color. Looks to be random though: as soon as I move the FOV with my mouse, the red color jumps to another bunch of galaxies. When zooming in or out, also whole patches appear or disappear. See screenshots below.

[10110111]

But here there is no difference when I enable or disable multisampling. At least, not in the Nvidia Control panel.

NVIDIA Control Panel is not something expected by Stellarium. Whether multisampling is enabled in Stellarium's settings influences the logic to enable or disable legacy line smoothing. The setting is in config.ini under video/multisampling. Set it to the number of samples, say, 8 to properly enable.

[Menno5]

I see. Is it correct that multisampling isn't there by default? I had to add it manually and give it the 8 value.
After that, the colors are indeed as they should be.

[10110111]

OK, my analysis appears to have been incomplete. The actual culprit is not the legacy rendering itself, since it would create only a minor ripple. The problem is that blending mode appears to be src+dst instead of the normal alpha blending src*alpha+dst*(1-alpha). I suppose the source of this is the sPainter.setBlending(true, GL_ONE, GL_ONE); line inside NebulaMgr::draw(), which is never reset in this function, so this state propagates into the DrawNebulaFuncObject methods. This becomes obvious from the following screenshot, made with multisampling enabled:

Now, can anyone explain why this blending mode is needed there?

[10110111]

Is it correct that multisampling isn't there by default?

Yes, I wouldn't be surprised.

[Menno5]

Just in case, here my results.
Did a reset of all settings, including colors.
Added the line multisampling = 8 to config.ini under video.
All the markers are in correct colors now and the overall effect is clearer.
The option Use outlines for big deep-sky objects is now also showing correctly, all markers stay the same colors.

[10110111]

Apparently, the problematic part that sets blending mode is not in NebulaMgr. Still, I don't understand why that line there is needed. Anyway, below a patch that fixes this for me. If it doesn't break anything for you, I can push it. Needs to get into a new RC I think.

diff --git a/src/core/modules/Nebula.cpp b/src/core/modules/Nebula.cpp
index 1611b15030..6397b5c138 100644
--- a/src/core/modules/Nebula.cpp
+++ b/src/core/modules/Nebula.cpp
@@ -750,6 +750,7 @@ void Nebula::renderDarkNebulaMarker(StelPainter& sPainter, const float x, const
     const float gap = 0.15*size;
     const float*const cossin = StelUtils::ComputeCosSinRhoZone((M_PIf/2)/(numPointsInArc-1),
                                    numPointsInArc-1, 0);
+    sPainter.setBlending(false);
     sPainter.setLineSmooth(true);
     sPainter.setLineWidth(scale * std::clamp(2*size/35, 1.f, 2.5f));
     sPainter.setColor(color, hintsBrightness);
@@ -861,6 +862,7 @@ void Nebula::renderMarkerRoundedRect(StelPainter& sPainter, const float x, const
         vertexData.push_back(bottomInnerY - roundRadius*sina);
     }
     const auto vertCount = vertexData.size() / 2;
+    sPainter.setBlending(false);
     sPainter.setLineSmooth(true);
     sPainter.setLineWidth(scale * std::clamp(2*size/35, 1.f, 2.5f));
     sPainter.setColor(color, hintsBrightness);
@@ -878,6 +880,7 @@ void Nebula::renderRoundMarker(StelPainter& sPainter, const float x, const float
     const auto scale = pixelRatio * StelApp::getInstance().getGlobalScalingRatio();
     size *= scale;
 
+    sPainter.setBlending(false);
     sPainter.setLineSmooth(true);
     sPainter.setLineWidth(scale * std::clamp(size/7, 1.f, 2.5f));
     sPainter.setColor(color, hintsBrightness);
@@ -921,6 +924,7 @@ void Nebula::renderEllipticMarker(StelPainter& sPainter, const float x, const fl
         vertexData.push_back(y + pointY*cosa + pointX*sina);
     }
     const auto vertCount = vertexData.size() / 2;
+    sPainter.setBlending(false);
     sPainter.setLineSmooth(true);
     sPainter.setLineWidth(scale * std::clamp(size/40, 1.f, 2.f));
     sPainter.setColor(color, hintsBrightness);
@@ -940,7 +944,7 @@ void Nebula::renderMarkerPointedCircle(StelPainter& sPainter, const float x, con
 
     texPointElement->bind();
     sPainter.setColor(color, hintsBrightness);
-    sPainter.setBlending(true, GL_ONE, GL_ONE);
+    sPainter.setBlending(false);
     const auto numPoints = StelUtils::getSmallerPowerOfTwo(std::clamp(int(0.4f*size), 8, 4096));
     const auto spriteSize = std::min(0.25f * 2*M_PIf*size / numPoints, 5.f);
     if(insideRect)

[gzotti]

What happens during toggling nebulae now? Is the blending smooth?
I agree, the sPainter.setBlending(true, GL_ONE, GL_ONE); looks strange. Would sPainter.setBlending(true) (with defaults GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA) work?

[10110111]

Yes, should work too. Didn't think of toggling animation.

[10110111]

I'd also remove the call in NebulaMgr. So, the patch:

diff --git a/src/core/modules/Nebula.cpp b/src/core/modules/Nebula.cpp
index 1611b15030..661f14b1ef 100644
--- a/src/core/modules/Nebula.cpp
+++ b/src/core/modules/Nebula.cpp
@@ -750,6 +750,7 @@ void Nebula::renderDarkNebulaMarker(StelPainter& sPainter, const float x, const
     const float gap = 0.15*size;
     const float*const cossin = StelUtils::ComputeCosSinRhoZone((M_PIf/2)/(numPointsInArc-1),
                                    numPointsInArc-1, 0);
+    sPainter.setBlending(true);
     sPainter.setLineSmooth(true);
     sPainter.setLineWidth(scale * std::clamp(2*size/35, 1.f, 2.5f));
     sPainter.setColor(color, hintsBrightness);
@@ -861,6 +862,7 @@ void Nebula::renderMarkerRoundedRect(StelPainter& sPainter, const float x, const
         vertexData.push_back(bottomInnerY - roundRadius*sina);
     }
     const auto vertCount = vertexData.size() / 2;
+    sPainter.setBlending(true);
     sPainter.setLineSmooth(true);
     sPainter.setLineWidth(scale * std::clamp(2*size/35, 1.f, 2.5f));
     sPainter.setColor(color, hintsBrightness);
@@ -878,6 +880,7 @@ void Nebula::renderRoundMarker(StelPainter& sPainter, const float x, const float
     const auto scale = pixelRatio * StelApp::getInstance().getGlobalScalingRatio();
     size *= scale;
 
+    sPainter.setBlending(true);
     sPainter.setLineSmooth(true);
     sPainter.setLineWidth(scale * std::clamp(size/7, 1.f, 2.5f));
     sPainter.setColor(color, hintsBrightness);
@@ -921,6 +924,7 @@ void Nebula::renderEllipticMarker(StelPainter& sPainter, const float x, const fl
         vertexData.push_back(y + pointY*cosa + pointX*sina);
     }
     const auto vertCount = vertexData.size() / 2;
+    sPainter.setBlending(true);
     sPainter.setLineSmooth(true);
     sPainter.setLineWidth(scale * std::clamp(size/40, 1.f, 2.f));
     sPainter.setColor(color, hintsBrightness);
@@ -940,7 +944,7 @@ void Nebula::renderMarkerPointedCircle(StelPainter& sPainter, const float x, con
 
     texPointElement->bind();
     sPainter.setColor(color, hintsBrightness);
-    sPainter.setBlending(true, GL_ONE, GL_ONE);
+    sPainter.setBlending(true);
     const auto numPoints = StelUtils::getSmallerPowerOfTwo(std::clamp(int(0.4f*size), 8, 4096));
     const auto spriteSize = std::min(0.25f * 2*M_PIf*size / numPoints, 5.f);
     if(insideRect)
diff --git a/src/core/modules/NebulaMgr.cpp b/src/core/modules/NebulaMgr.cpp
index 508f7b1303..28eeab810c 100644
--- a/src/core/modules/NebulaMgr.cpp
+++ b/src/core/modules/NebulaMgr.cpp
@@ -698,8 +698,6 @@ void NebulaMgr::draw(StelCore* core)
 
     Nebula::hintsBrightness = hintsFader.getInterstate()*flagShow.getInterstate();
 
-    sPainter.setBlending(true, GL_ONE, GL_ONE);
-
     // Use a 4 degree margin (esp. for wide outlines)
     const float margin = 4.f*M_PI_180f*prj->getPixelPerRadAtCenter();
     const SphericalRegionP& p = prj->getViewportConvexPolygon(margin, margin);

[alex-w]

I fear the current properties for blending are existing by historical reasons :-/

P.S. No problem for make the RC4 tonight or tomorrow, but need fix in master

[alex-w]

@10110111 @gzotti any news?

[github-actions]

Hello @Menno5!

Please check the fresh version (development snapshot) of Stellarium:
https://github.com/Stellarium/stellarium-data/releases/tag/weekly-snapshot

[Menno5]

You all are the best! Working great!

[github-actions]

Hello @Menno5!

Please check the latest stable version of Stellarium:
https://github.com/Stellarium/stellarium/releases/latest