Celestia Forums

I have written a little program to convert asteroid reflectance data from the SMASS survey into RGB values for Celestia. To test the output I compared the generated color of Eros with the value already in the asteroids.ssc file. The hue and saturation were very close.

The default color values for the asteroids in Celestia have a luminosity of about 0.5, regardless of albedo, while the moons and planets are much higher. Asteroids which do not have color information instead use the default color of [ 1.0 1.0 1.0 ], which has a luminosity of 1.0. So my first question is, should asteroids which have colors be darker than those without? My inclination is to max out the luminosity as much as possible without losing too much saturation. Also, should the asteroid color depend on the albedo in some way?

I can generate colors for almost all the asteroids in the default SSC file, plus about a thousand more. I am not sure how to distribute something like this. Can I create a new SSC file with just color info and let Celestia merge the properties with the other SSC files? Do I have to create a replacement asteroids.ssc file? Should I create a new SSC file with complete data for the asteroids not in the default install, and then have people manually patch in the colors for the standard installed asteroids?

Matt

wronkiew wrote:I have written a little program to convert asteroid reflectance data from the SMASS survey into RGB values for Celestia. To test the output I compared the generated color of Eros with the value already in the asteroids.ssc file. The hue and saturation were very close.

The default color values for the asteroids in Celestia have a luminosity of about 0.5, regardless of albedo, while the moons and planets are much higher. Asteroids which do not have color information instead use the default color of [ 1.0 1.0 1.0 ], which has a luminosity of 1.0. So my first question is, should asteroids which have colors be darker than those without? My inclination is to max out the luminosity as much as possible without losing too much saturation. Also, should the asteroid color depend on the albedo in some way?

I can generate colors for almost all the asteroids in the default SSC file, plus about a thousand more. I am not sure how to distribute something like this. Can I create a new SSC file with just color info and let Celestia merge the properties with the other SSC files? Do I have to create a replacement asteroids.ssc file? Should I create a new SSC file with complete data for the asteroids not in the default install, and then have people manually patch in the colors for the standard installed asteroids?

Matt

While I do not understand how you have generated the asteroid colors, the problem of merging two text files with arbitrary editing inbetween is trivially solved by means of PERL. If you don't know PERL you can learn enough quickly, to do that easy job.

Why didn't you explain what physics is behind your coloration code? There are a number of people here who are perfectly able to understand and give you feedback.

Bye Fridger

I'd be interested in knowing the conversion scheme.

I agree with you that luminosity should be as high as possible without losing saturation. With star RGB values, the brightness is set so that at least one of the color channels has a value of 1.0. The important thing is that the relative values of the color channels are correct.

Given the small number of asteroids in that file, hand editing to add the color information (and documenting the edits with comments) would be ok. If you can find a programmatic way of generating asteroids.ssc, that would be ideal. There is some hand editing that will be required, however. Data such as the orbit of Dactyl around Ida, shape models, and InfoURLs aren't in any standard catalog.

--Chris

I do understand how to merge SSC files. I am a little confused about how to distribute my changes. Should I create a script that merges the changes in to the asteroids.ssc file, and post that on the Motherlode? Or should I merge the changes myself and post the new asteroids.ssc?

My coloration code generates RGB values from the spectral analysis done by SMASS. For each asteroid, they give a list of wavelengths of light and a reflectance value for that wavelength. So, for example, at the exact wavelength of 467.9 nm, the space rock reflectance is 0.895/1.000. The numbers are all normalized so a particular wavelength has a value of 1.000/1.000, but that doesn't make any difference in my calculations. It does eliminate the effect of overall albedo. I am using just the reflectance values for now, but I plan to convert them to emissive values. To do this, I would multiply each reflectance value by the relative emission strength of the Sun at that wavelength. Then, my program takes the asteroid spectrum and integrates it across the color perception table. The perception table goes from 360 nm (violet limit) to 860 nm (red limit) and specifies a color in XYZ space for each wavelength. Then I take the resulting XYZ color and convert it into an RGB value. This would all be terribly complicated to implement if I hadn't done it already in an earlier project to colorize Mars rover images. Here's an example from Mars:

In that project I was synthesizing an entire spectrum from five different black and white images taken through color filters.

If you want to take a look at the results, here are some examples:
Juno:
Color [ 1.000 0.846 0.867 ]
BlendTexture true
Ida:
Color [ 1.000 0.841 0.848 ]
BlendTexture true
Eros:
#Color [ 0.52 0.47 0.42 ]
Color [ 1.000 0.818 0.804 ]
BlendTexture true

Thanks for the suggestion, Chris.

The datasets for SMASS can be found here:
http://smass.mit.edu/
I'm probably going to just use set 2.

wronkiew wrote:I can generate colors for almost all the asteroids in the default SSC file, plus about a thousand more. I am not sure how to distribute something like this. Can I create a new SSC file with just color info and let Celestia merge the properties with the other SSC files? Do I have to create a replacement asteroids.ssc file? Should I create a new SSC file with complete data for the asteroids not in the default install, and then have people manually patch in the colors for the standard installed asteroids?
Matt

Hi Matt,

I may be mis-understanding what you're trying to do, but I would have thought the best way to distribute this is in the standard way as an addon.
ie. In a new SSC file with just color info (eg. asteroidcolors.ssc) and let Celestia do the merging.
You would need to use the Modify command to add the color info to existing asteroids, but new asteroids would just have full details (possibly in a second SSC without the Modify command. (eg. asteroidSMASS.ssc)

Advantages to this method:
1. it doesn't overwrite the original asteroids.ssc, and the color could be enabled/disabled easily by users at any time because it lives in the extras directory.
2. You wouldn't have to do any file-merging.

Minor disadvantage:
Has to be loaded as well as asteroids.ssc at startup, but should be relatively insignificant overhead.

If this was to become part of the standard distribution (at Chris' discretion) then I suppose it could be merged into a new asteroids.ssc. In the meantime, I think the addon approach with the Modify command is the best.

JM2CW

Regards
CC

Thanks. That's exactly what I was looking for. I added in the effect of sunlight and created an addon file for the default asteroids. Here's the URL of the SSC file:
http://www.wronkiewicz.net/asteroidcolors.ssc
I think this would have to go in the extras directory.

Matt

Thanks Matt. I downloaded the add-on and enjoyed seeing the subtle colors instead of the plain old dull grays. I think that this is a good candidate for inclusion in the main Celestia package--integrated with asteroids.ssc instead of as a separate file. Is the program you used to generate the RGB colors something that you'd be willing to GPL and include check in to the Celestia CVS repository? It's not essential that you do this, but it would be useful both as a means for people to produce colors for additional asteroids and as documentation of the procedure used to generate the colors.

--Chris

I can do that. The program is just a C file, and it needs one extra data file. Are you using a particular version of the GPL? How do I check it in?

wronkiew wrote:I can do that. The program is just a C file, and it needs one extra data file. Are you using a particular version of the GPL? How do I check it in?

Matt,

I would be interested seeing your C program to understand better the assumptions that went into the conversion of the SMASS spectral reflectivities into RGB colors. Since I am planning to convert the official full dataset of ~110 000 asteroids

ftp://ftp.lowell.edu/pub/elgb/astorb.html

with a PERL program to Celestia format, it might be simplest to do your conversion for the large set directly in PERL.

Another good point of PERL is documentation. Any assumptions made and modifications of published data can be added to the Celestia distribution as a /human readable/ PERL script, together with the very simple asteroid.ssc formatting code, of course. In addition, my respective extraction/conversion scripts of Celestia's 10000+ galaxies and many binary orbits are also attached to the distribution in PERL.
You may send your C program to Chris or any of us developers for commiting it to the distribution.

I assume the data file you mentioned just contains the (unmodified?) SMSS spectral data? If so this does not have to be included into the distribution, since a citation of the published reference would be sufficient.

Before Celestia can handle such large amounts of asteroid data efficiently, a clever (octree) culling mechanism has to be found and implemented. I am thinking about this problem since quite a while. It's difficult, since asteroids are moving with time and simple octrees won't work of course

Bye Fridger

Could they be broken down into families prior to your culling program Fridger? I do not know a ton about the asteroids but I believe many are grouped by similar orbital elements...

I found this site which descibes the groupings in pretty good detail based on semi major axis, eccentricity and inclination.

http://www.astrosurf.com/aude/map/us/As ... -05-20.htm

buggs_moran wrote:Could they be broken down into families prior to your culling program Fridger? I do not know a ton about the asteroids but I believe many are grouped by similar orbital elements...

I found this site which descibes the groupings in pretty good detail based on semi major axis, eccentricity and inclination.

http://www.astrosurf.com/aude/map/us/As ... -05-20.htm

That's pretty much one part of what I am exploring.
Incidentally given the 110000 asteroid data one may easily display the relevant number distributions wrto grouping properties with standard tools like Maple...

Another aspect is this: Suppose asteroid movements were only in simple spherical orbits. Clearly then, the radius coordinate in their polar coordinate description becomes a stationary quantity and may be used for octree subdivisions.

Now, of course asteroids don't move in spherical orbits. But grouping them into families and exploiting clever coordinate transformations may significantly help to isolate quantities that are suitably "quasi stationary".

Bye Fridger

t00fri wrote:Another aspect is this: Suppose asteroid movements were only in simple spherical orbits. Clearly then, the radius coordinate in their polar coordinate description becomes a stationary quantity and may be used for octree subdivisions.

Now, of course asteroids don't move in spherical orbits. But grouping them into families and exploiting clever coordinate transformations may significantly help to isolate quantities that are suitably "quasi stationary".

Bye Fridger

Can't you use the semimajor axis as a "stationary quantity"? That's not changing is it?

Or a range of SMA's? Or for that matter, couldn't the combination of an SMA range with eccentricity and/or inclination be used as your stationary quantity? Is it possible to have the culler loop through two or three qualifiers?

Here's the source code for the asteroid color generator:
http://www.wronkiewicz.net/spectrum2rgb.c
and the data file, which contains the solar emissive spectra:
http://www.wronkiewicz.net/solar_spectrum.txt

Matt

wronkiew wrote:Here's the source code for the asteroid color generator:
http://www.wronkiewicz.net/spectrum2rgb.c
and the data file, which contains the solar emissive spectra:
http://www.wronkiewicz.net/solar_spectrum.txt

Matt

Thanks! I'll check these into CVS and include your asteroid colors in the default asteroids.ssc. You'll be appropriately credited as a contributor.

--Chris

You're very welcome.

Fridger, something I don't understand about adding a hundred thousand asteroids to Celestia is, how will you see the new asteroids? Will you be able to see them as points of light when you move into the main belt? If they're only visible when entered by name, there are only a couple hundred that could be depicted realistically in any way.

Matt

I found a bug in my color generator program which was making all the asteroid colors extra blue. Also there are some additional problems with the asteroid Eros in particular. Here's how it looked before I started messing with it, compared to a colorized NEAR image on the right.

It's very dark and a little too red. Here's the new asteroid with my original color modification.

It's lighter, but the hue is now way off. While trying to figure this out, I noticed that the texture for Eros is already tinted with sort of the right color. So the original asteroids.ssc file has a bug in that it's multiplying the texture color by the same color again and producing the very dark brown. I made the texture grayscale and got this instead.

It's closer than before, but now it's too blue. I tracked this down to a typo in my tristumulus XYZ to RGB conversion matrix. Here's the fixed color.

Very nice, I think. The fixed source code is here:
http://www.wronkiewicz.net/spectrum2rgb.c
I also fixed some problems I came across while trying to get it to build on Windows. The fixed asteroid color file is here:
http://www.wronkiewicz.net/asteroidcolors.ssc
I am not sure what to do about Eros. Either the texture should be gray instead of brown, or the SSC file should drop the extra color property.

Matt

Wow, the results look great. The Eros texture ought to be made gray IMHO - right now without the spectrumrgb colorization it looks too brown.

Nice! Tx for your work!