Night mode still has non-red pixels lighting up

Bug #682033 reported by Matthew Gates
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Stellarium
Fix Released
Medium
Alexander Wolf

Bug Description

The purpose of night mode is to preserve the user's dark adapted vision as much as possible. The reason we use red is that longer wavelength light doesn't cause the more sensitive rod cells in the eye to trigger as much. Thus any non-red pixels are not desirable.

As of trunk revision 4823 we still have the following non-red things in night mode:

- Stars (render with normal color, G & B channels should be 0)
- Star labels (RGB is [0.8, 0.2. 0.1]. should be [0.8, 0, 0]).
- Star info text (off red)
- Star selection marker (off red)
- Planets (render with normal color, G & B channels should be 0)
- Planet labels (off red)
- Planets info text (off red)
- Sun halo (has day color)
- Planet object selection marker (off red)
- Nebula hints (blue)
- Nebula labels (blue)
- Landscape colors are too bright in the day (they are red, but should probably be dimmed or nor illuminated at all)
- Nebula selection marker (blue)
- Cardinal marks (similar to star labels)
- Constellation lines (off red)
- Constellation names (off red)
- Constellation art (original color)
- Equator line (original color)
- Meridian line (original color)
- Ecliptic line (original color)
- GUI elements:
  - GUI focus highlight
  - Close X icon
  - Other icons
  - Disabled button text
  - Hyperlink text style in some plugins
- Compass marks plugin (when color is not set to red in day mode)
- Oculars plugin message text
- Oculars plugin info text (top right)
- Satellite plugin selection marker
- Angle measure plugin info text
- Angle measure plugin lines

Related branches

Changed in stellarium:
status: New → Confirmed
importance: Undecided → Medium
assignee: nobody → Matthew Gates (matthew-porpoisehead)
description: updated
description: updated
Changed in stellarium:
milestone: none → 1.0.0
Changed in stellarium:
status: Confirmed → In Progress
Revision history for this message
Bogdan Marinov (daggerstab) wrote :

A possible way of dealing with this: the "X" icon of the close button in each window is set via style sheet.

Changed in stellarium:
assignee: Matthew Gates (matthew-porpoisehead) → nobody
Revision history for this message
RossMitchell (rossmitchell) wrote :

The issue with incorrect Night Vision text in the oculars plugin is easily fixed

In file plugins/Oculars/src/Oculars.cpp in function Oculars::paintText near line 1424 is
 painter.setColor(0.8, 0.48, 0.0, 1);

replace it with:
 if (StelApp::getInstance().getVisionModeNight())
  painter.setColor(0.8, 0.0, 0.0, 1); //red only
 else
  painter.setColor(0.8, 0.48, 0.0, 1);

Maybe you want to use a function to map the orange text to the suitabel red tone instead of the way I have hard coded it.
With this change I think all of the NightVision issues with the Oculars plugin have been addressed in ver 0.11.4a

Revision history for this message
Alexander Wolf (alexwolf) wrote :

Thanks for patch.

Revision history for this message
RossMitchell (rossmitchell) wrote :

Further fixes for the various sky lines which do not respond to Night Vision setting (such as equator)
My solution is to calculate a local color for lines, and also labels, the calculation is lifted from SkyGrid::draw
source code was 0.11.4a

in /src/core/modules/GridLinesMgr.cpp function SkyLine::draw replace these lines:

 // Initialize a painter and set openGL state
 StelPainter sPainter(prj);
 sPainter.setColor(color[0], color[1], color[2], fader.getInterstate());
 glEnable(GL_BLEND);
 glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA); // Normal transparency mode

 Vec4f textColor(color[0], color[1], color[2], 0);

with these, where a new local variable lcolor is conditionally set redish:
 // Initialize a painter and set openGL state
 StelPainter sPainter(prj);
 Vec3f lcolor;
 lcolor = color;
 if(StelApp::getInstance().getVisionModeNight()) { //code lifted fron SkyGrid::draw
  lcolor[0] = (color[0] + color[1] + color[2]) / 3.0;
  lcolor[1] = lcolor[2] = 0.;
 }
 sPainter.setColor(lcolor[0], lcolor[1], lcolor[2], fader.getInterstate());
 glEnable(GL_BLEND);
 glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA); // Normal transparency mode

 Vec4f textColor(lcolor[0], lcolor[1], lcolor[2], 0);

Not sure if this is the most elegant solution, but it works.

Revision history for this message
Alexander Wolf (alexwolf) wrote :

Thanks for latest patch but I think this is already implemented on trunk.

Revision history for this message
Alexander Wolf (alexwolf) wrote :

No, you are right, this part of code has been wrong :-/

Diff: http://bazaar.launchpad.net/~stellarium/stellarium/trunk/revision/5736

Changed in stellarium:
milestone: 1.0.0 → 0.12.0
status: In Progress → Fix Committed
assignee: nobody → Alexander Wolf (alexwolf)
Changed in stellarium:
status: Fix Committed → Fix Released
Revision history for this message
henrysky (henry-leung-2010) wrote :

Fix released??
Hyperlink text in plugin still in blue color in night mode

Revision history for this message
Alexander Wolf (alexwolf) wrote :

Oops... It's my mistake, I'll fix it.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.