Adjusting the Color of Stars in DMNS Star Module
Is it possible to adjust the color of individual stars in the DMNS stars module? I have had several people say that they like the DMNS stars better than the AMNH, but stars like Betelgeuse are too red and they would like to change it.
Service d'assistance aux clients par UserEcho
The only way to do this would be to adjust the colormap file to assign different values for the b-v colors.
May I suggest CAS stars as an alternative, which has a well researched color-map? SLUM and polysize can be adjusted to match DMNS_Stars, or the cmap could be replaced (but I would not be able to guarantee the accuracy).
There is a separate module for red stars that was part of the zipped package that includes the Denver stars. You can therefore have separate controls over the slum and polysize for just the reddish stars in Uniview.
I do remember Betelgeuse looking a little too red. The original module was based on the Charity colors (http://www.vendian.org/mncharity/dir3/starcolor/), and the way I extracted just the red stars when I originally created the module was to search for certain RGB values associated with spectral classes from the HIPPARCOS-based Denver stars, e.g.,
"255 187 123" M6 (V)
"255 190 127" M4 (V)
"255 198 144" M2 (V)
"255 215 174" K7 (V)
"255 235 209" K4 (V)
"255 210 161" K stars
"255 204 111" M stars
"255 198 118" Scheat
"255 193 104" Betelgeuse
"255 221 175" Arcturus
"255 204 138" Aldebaran
"255 204 111" Proxima Centauri
"255 206 127" Gacrux
Even the reddest of these is just a deep orange, so I'm not sure how they got so red in the final module. I won't have any time for awhile to really debug this, but for anyone who is interested, you play around with the colorbv.cmap file in the module denver_redStars/.
And as usual, proven wrong from the people that created it. Thanks guys!
Hey, I was just looking at this because it seems like a good question to answer...
Both Ka Chun and I are using a Mitchell Charity derived color-map, so the stars should be very similar in color, and we use a similar range for the colormap. However, spotchecking in the speck files, in denver_stars, Betelgeuse has a B-V value of 2.32; in CAS_Stars it has 1.5. I built mine from XHIP, and this is consistent with that. I saw that you also built DMNS from Yale Bright star and Hipparcos--Yale gives 1.85 for Betelgeuse's B-V (consistent with Johnson 1966), and it's 1.5 in Hipparcos, Tycho and XHIP. 2.32 looks like just the B value. Is it possible some of the red stars in DMNS stars have the wrong B-V value? In cases like Betelgeuse a value of 2.32 would overrun the colormap and be drawn very red (much redder than the colormap suggests) creating this issue. Checking redstars, a lot of the red stars do seem to have B-V values greater than 2.0 (maximum in the colormap). Antares seems to be in the same situation--its B mag is given for B-V, so it's almost a value of 1 too high. Is it possible a chunk of the red stars were done incorrectly? Most other stars look fine, it seems like it might just be a selection of bright, red stars.
Dan:
Could you dumb that down for me?
I see the colorbv.cmap file and the denver_colorbv.cmap but there are four values in each entry. In the spec file the first value after the x, y, z position is the colorb_v, but it is only one value.
How do you go from four values to one and what is the range that the one value should stay within?
Paul
So, I think you shouldn't change anything in the .cmap file. The CMAP is literally
R G B Alpha as values/1.0 and sometimes with a comment. Uniview takes the cmap and the number of entries and creates a linear gradient between the values.
I mean, depending on how basic this should get:
B-V color is literally the magnitude of a star through a blue filter (B) minus the magnitude of a star through a visible/greenish filter (V). Negative values are bluer, positive values are redder, and this has a known relationship between temperature and color.
In the case of these star files, we compiled them from different sources--AMNH used XHIP (Extended Hipparcos), Ka Chun used Hipparcos and Yale Bright Star Catalogue, I used XHIP, Gliese-Jahreiss with some additional Aladin XMATCH to fill it out from various other catalogues.
I assume Ka Chun was doing the same thing I was doing: Hipparcos on its own has some missing b-v data for stars that is available in other surveys, which affects even some naked-eye stars. So if you can cross-reference it, you can fill in these values--this is why denver_stars and cas_stars are both larger than amnh_stars--AMNH appears to have just dropped stars that had missing values.
What I observed, however, is that for these troubled red stars in Ka Chun's catalogue, they seem to just have the B magnitude entered, not B-V. But other stars are correct. So for a star like Betelgeuse, it's b-v should be something like 2.3 Bmag - 0.8 V Mag = 1.5 B-V (since Ka Chun used Tycho, his value would actually be more like 1.8, I think). Instead, because 2.3 is the value entered for Betelgeuse in the speck file, it shows up as redder than it should be. Same for Arcturus, and presumably all the other troubled stars.
(b-v isn't missing from Hipparcos or Tycho from these stars, it looks like a transcription error in creating denver_stars)
denver_redstars fixes in a kind of brute-force way by changing the cmap for just these, but doesn't correct the innate problem in the speck file.
In summary you SHOULD NOT change the cmap for denver_stars as a whole, because it'll throw off many of the correct values for stars throughout, since you'll be expanding the range of the colormap--your yellow stars will redden, which would not look good!
Since they should have similar accuracy, unless Ka Chun is looking to update denver_stars, I think you could get the same look by using the same slum, polysize, pointsize etc, settings from denver_stars in CAS_stars, editing the .mod file. I think a few of us are also working on a Gaia/Tycho/Hipparcos merge, which will increase the number of stars by 20x and should replace the existing star modules anyway.
Dan: I think you've tracked down the problem!
I dimly recall running into an issue with some of the B-V's. I meant to fix them, but somehow got distracted and left them in the denver_stars modules. I'll see if I can make some time in the next couple weeks or so to correct these values.
I have made changes to some of the b-v values in the speck files for my version of the DMNS stars. I combined the separate modules (All Stars, Red Stars, and Bright Stars) and found that several stars were being rendered more than once, some as many as three times.
Attached is the module I created from the original and a list of the stars that have adjusted b-v values. I got the values from Wikipedia and I know there are many more that need to be changed, but it is a start.
DMNSStars_ByMagnitude.zip