Orbits and Labels colors

[t00fri]

Before going farther, I'll wait Chris (L) opinion, which to my eyes is quite important...

I agree, it's just about time that he comments, otherwise I'll get involved with something else...

Let me repeat my previous request:

It would be good to have some comments soon from Chris L. also about my above fading label code additions for nebulae and clusters. Then the whole stuff could be commited soon to CVS and we all have an easier life as to working with further modifications in render.cpp!

Else this thread is getting so long that noone will be able to retrieve the crucial mails...

Bye Fridger

[selden]

It might be appropriate to consider using outlined fonts,
with the outline of the letters set to a complementary color. That would guarantee that the letters would be readable.

Could this be implemented by overwriting a large font by a smaller one?

[Cham]

There is also uranus :

My palette :


ElChristou's palette :


Actually, I've checked that my color matches with ALL bodies. It works, even if in some few cases, it's a bit borderline. But in the case of ElChristou's color, it's washed out in several cases, like Uranus and Neptune.

Notice also the galaxies labels. Harder to read with ElChristou's palette.

And again the moon labels are too close in color to the planet itself.

[Cham]

Earth and Venus are also giving troubles to ElChristou's palette. See :


Case of Earth :

My palette :


ElCristou's palette :


Case of Venus :

My palette :


ElChristou's palette :


Is that enough ?

[ElChristou]

...Actually, I've checked that my color matches with ALL bodies...

Cham, as already said, it's not a question of palette (choice of color) it's a question of vivid colors versus smooth ones.

IMO, EVEN with those problems you are pointing at (and you can point much more using asteroids if you want to lose time), after a few hours using the smooth palette from a general point of view it gives you a REAL comfort. To be frank I tried again the default palette and really I cannot stand it anymore.

The solution is an adaptive label. Just like a PS filter but in real time. Not a negative, much a multiply or overlay...

I recall asking for this a few months after my coming here...

[t00fri]

...Actually, I've checked that my color matches with ALL bodies...

Cham, as already said, it's not a question of palette (choice of color) it's a question of vivid colors versus smooth ones.

IMO, EVEN with those problems you are pointing at (and you can point much more using asteroids if you want to lose time), after a few hours using the smooth palette from a general point of view it gives you a REAL comfort. To be frank I tried again the default palette and really I cannot stand it anymore.

The solution is an adaptive label. Just like a PS filter but in real time. Not a negative, much a multiply or overlay...

I recall asking for this a few months after my coming here...

I don't think coding adaptive labels would be very hard. I'll think about how I could do this. One might just compare some suitable contrast measure built both with the background and the label color and then increases the label luminosity (V=value) until the criterion is satisfied. This would not change the color palette, but only the respective contrast.over the background.

Is this about what you have in mind?

Bye Fridger

[Cham]

ElChristou,

I can say the same about my palette : comfort of use, and functionality.

Actually, more and more I use your palette, more I find it confusing and boring : it's "flat". Especially for the nebulas and the clusters. It's hard to say which one is which. And in many cases (like for the planets), the labels are unreadable.

[ANDREA]

So, Chris, Fridger, Christophe and all the developers, why don't you eliminate all this empty chattering and working, where each of the developers will use his own product : My little cent. Bye Andrea

Andrea, sorry, but honestly I think your critique does not do justice to the hard amount of creative work that has been done and discussed during the last couple of days in this thread. Finding the right palette of label colors and the right parameters in my label fading code is a quite complex task!

I'm absolutely aware of this, so beg your and Cham and Chris pardon, I had no intention to minimize your valuable search for the best default colours palette.

Throughout, there are compromises to make between (objective) rules of color matching, artistic feelings and functionality. It is quite admissible and CERTAINLY not empty talking, if some personal preferences are underligned by the people concerned. Bye Fridger

This is a bit (scientifically) egoistic view of the realty.
Let me make an example: if one needs to show ONLY planets and moons using a script, why should he see the colours chosen by someone else, thinking that his own view (even if scientifically motivated) is what is needed by all?
Just for an example, IMO (sorry for acronym ) the bright blue colour of planets orbits is ugly and attention catching, so I would like a much softer hue, less obtusely evident.
But I cannot change it, alas!
I?€™m not trying to criticize, and sorry if you misunderstood me, but instead I?€™m trying to persuade developers to ?€?fork?€

[Cham]

I agree with Andrea that planet names should be bigger. What is the actual size ? 12 points ? I suggest 16 points (I don't think 14 points is big enough : too close to the default 12 points).

[chris]

I'll refrain from commenting on the actual color choices and just address a few issues . . .

I don't care for the idea of distance based fading of nebula, open cluster, or any other labels. I think that it should always be based on apparent magnitude. It's important to have a simple rule for interpreting the brightness of any label, and that rule should be that the brighter the label, the greater the apparent brightness of the object. Otherwise, there will be situations where an apparently bright object remains unlabeled.

I don't intend to add a config file option to set the colors. But, I do want to add script commands to set the color of labels, orbits, constellations lines, etc. I haven't added them yet because I haven't thought of the best way to specify them. Perhaps just simple command such as get/setlinecolor and get/setlabelcolor?

Examples:

Code: Select all

setlinecolor("planetorbit", 0.5, 0.5, 1.0)
setlinecolor("highlightorbit", 1.0, 0.0, 0.0)
setlinecolor("constellations", 1.0, 0.5, 1.0)
setlabelcolor("moon", 0.0, 1.0, 0.0)


It's still important to have a good default palette, but the ability to customize the colors is useful and not hard to implement.

Regarding the use of outlined fonts to ensure that labels are visible against any background . . . First, I don't want to invest time in this for the 1.5.0 release. I personally think that an outlined font would look rather ugly with the small fonts generally used for labels. Another approach would be to add a subtle shadow behind the text. This would have effect of slightly darkening the background so that the label would always stand out. We could accomplish it by setting the mipmap bias to render a blurry version of the text dark, then rendering normal text on top of that.

--Chris

[Cham]

Inspired by ElChristou's palette, I changed the colors used in my palette for the asteroids and comets. It's now more consistent with all the rest and less "vivid" :

Code: Select all

Asteroids Orbits :  0.49, 0.28, 0.27

Asteroids Labels :  0.79, 0.58, 0.46

Comets Orbits :  0.65, 0.40, 0.16

Comets Labels :  0.84, 0.62, 0.28


Here's a preview :

Asteroids orbits :


Asteroids labels


Comets orbits :


Comets labels

[t00fri]

I don't care for the idea of distance based fading of nebula, open cluster, or any other labels. I think that it should always be based on apparent magnitude.

--Chris

It would have been great if you had made that ingenious comment 2 days earlier. Then we all could have spent the weekend otherwise!

I'll go away now and spend my time on more useful things...

Bye Fridger

[ElChristou]

...Actually, I've checked that my color matches with ALL bodies...

Cham, as already said, it's not a question of palette (choice of color) it's a question of vivid colors versus smooth ones.

IMO, EVEN with those problems you are pointing at (and you can point much more using asteroids if you want to lose time), after a few hours using the smooth palette from a general point of view it gives you a REAL comfort. To be frank I tried again the default palette and really I cannot stand it anymore.

The solution is an adaptive label. Just like a PS filter but in real time. Not a negative, much a multiply or overlay...

I recall asking for this a few months after my coming here...

I don't think coding adaptive labels would be very hard. I'll think about how I could do this. One might just compare some suitable contrast measure built both with the background and the label color and then increases the label luminosity (V=value) until the criterion is satisfied. This would not change the color palette, but only the respective contrast.over the background.

Is this about what you have in mind?

Bye Fridger

Yes, but seems you've decide a few post above to go away from this task... too bad...

[ElChristou]

I'll refrain from commenting on the actual color choices and just address a few issues . . .

I'd like your point of view not on the choice of colors but on the smooth colors versus vivid ones topic; your personal taste here is important because in my case I would take this in account for more tuning...

I don't care for the idea of distance based fading of nebula, open cluster, or any other labels. I think that it should always be based on apparent magnitude. It's important to have a simple rule for interpreting the brightness of any label, and that rule should be that the brighter the label, the greater the apparent brightness of the object. Otherwise, there will be situations where an apparently bright object remains unlabeled.

What I like with distance based labels is that it gives you more informations than a magnitude based one. Let's take stars as example:

- you see a bright dot for a far high magnitude star near a darker dot for a near low magnitude star.

Two cases:

- If the labels are magnitude dependent, the bright dot will have a bright label, the dark dot a dark label.

-If the labels are distance dependent, the bright dot will have a dark label, the dark dot a bright one.

First case, we double an existing info, second case we add an info of distance: at first sight the bright dot is a high magnitude star and is further away than the low magnitude one...

This is a reason why I like distance dependent labels. Now, it also have the merit to give a 3D sense to the scene, bright= near, dark= far and this make really sense when you rotate a system or when you fly through it.

When I first emit the ideas of fading labels for galaxies, it was in this optic. In my view, rotating a system (like the whole galaxies catalogue) using a distance dependent labels or markers would really give a 3rd dimension on the screen.

The magnitude dependent label do not give this feeling.

Regarding the use of outlined fonts to ensure that labels are visible against any background . . . I personally think that an outlined font would look rather ugly with the small fonts generally used for labels. Another approach would be to add a subtle shadow behind the text. This would have effect of slightly darkening the background so that the label would always stand out. We could accomplish it by setting the mipmap bias to render a blurry version of the text dark, then rendering normal text on top of that.

I agree an outlined would not be really elegant. Now, it would be nice to have a solution to this working on all render path. Is the above not too complex? An adaptive label would not be more easy to implement?

[ElChristou]

Inspired by ElChristou's palette, I changed the colors used in my palette for the asteroids and comets. It's now more consistent with all the rest and less "vivid" :

asteroids=boring, comets=too flashy

[chris]

I don't care for the idea of distance based fading of nebula, open cluster, or any other labels. I think that it should always be based on apparent magnitude.

--Chris

It would have been great if you had made that ingenious comment 2 days earlier. Then we all could have spent the weekend otherwise!

I'll go away now and spend my time on more useful things...

I was unfortunately too busy with other things in my life to follow every forum thread this weekend. Anyhow, experiments with different labeling approaches are interesting and useful even if they don't end up ultimately being included in Celestia.

--Chris

[ElChristou]

ElChristou,

I can say the same about my palette : comfort of use, and functionality.

Actually, more and more I use your palette, more I find it confusing and boring : it's "flat". Especially for the nebulas and the clusters. It's hard to say which one is which. And in many cases (like for the planets), the labels are unreadable.

Your problem Cham, is that you always take things fer too personal. I've been clear in my post that there was room for tuning in my proposition. I haven't spend hours on this palette, and the idea was to propose an harmony.
By not comfortable I mean if too colors are "fighting" on screen, specially if I have to bare them during a long time. To me it's an aggression. I feel this aggression with some of your choice.

So instead of losing time on punctual problems that will be solve soon or later, the important thing here is to choose once for all between a vivid set or a smooth set of colors. Mixing both is not a solution to me.
If there is consensus on one or the other, perso even if it's not my taste I'll do a new proposal.

[chris]

What I like with distance based labels is that it gives you more informations than a magnitude based one. Let's take stars as example:

- you see a bright dot for a far high magnitude star near a darker dot for a near low magnitude star.

Two cases:

- If the labels are magnitude dependent, the bright dot will have a bright label, the dark dot a dark label.

-If the labels are distance dependent, the bright dot will have a dark label, the dark dot a bright one.

First case, we double an existing info, second case we add an info of distance: at first sight the bright dot is a high magnitude star and is further away than the low magnitude one...

This is a reason why I like distance dependent labels. Now, it also have the merit to give a 3D sense to the scene, bright= near, dark= far and this make really sense when you rotate a system or when you fly through it.

Indeed, you can use distance based label fading to give a better sense of where objects are located in three dimensions. The technique is called depth cueing. But, I think that the primary purpose of labeling is to tell the user what the objects in the view are. Depth cueing can compromise this. Consider Deneb: from Earth, it's prominently visible at magnitude 1.25, and should definitely get a label. However, it's also very distant: at over 3000 light years away, it's further away than the great majority of HIPPARCOS stars, so any reasonable depth cueing scheme would leave its label invisible. This to me is incompatible with the main point of labeling.

You could argue that there should be two labeling modes: brightness based and distance based. But is that extra complexity worthwhile?

--Chris

[tech2000]

This is a reason why I like distance dependent labels. Now, it also have the merit to give a 3D sense to the scene, bright= near, dark= far and this make really sense when you rotate a system or when you fly through it.

I agree on this one.. It makes more sense if the labeling is based on distance and not magnitude. It feels very awkward if you travel to a bright labeled star and passes a darker labeled star on the way, it really doesn't make any sense to me.

By the way, I really like this new colors and fading labels.

Bye, Anders

[ElChristou]

What I like with distance based labels is that it gives you more informations than a magnitude based one. Let's take stars as example:

- you see a bright dot for a far high magnitude star near a darker dot for a near low magnitude star.

Two cases:

- If the labels are magnitude dependent, the bright dot will have a bright label, the dark dot a dark label.

-If the labels are distance dependent, the bright dot will have a dark label, the dark dot a bright one.

First case, we double an existing info, second case we add an info of distance: at first sight the bright dot is a high magnitude star and is further away than the low magnitude one...

This is a reason why I like distance dependent labels. Now, it also have the merit to give a 3D sense to the scene, bright= near, dark= far and this make really sense when you rotate a system or when you fly through it.

Indeed, you can use distance based label fading to give a better sense of where objects are located in three dimensions. The technique is called depth cueing. But, I think that the primary purpose of labeling is to tell the user what the objects in the view are. Depth cueing can compromise this. Consider Deneb: from Earth, it's prominently visible at magnitude 1.25, and should definitely get a label. However, it's also very distant: at over 3000 light years away, it's further away than the great majority of HIPPARCOS stars, so any reasonable depth cueing scheme would leave its label invisible. This to me is incompatible with the main point of labeling.

You could argue that there should be two labeling modes: brightness based and distance based. But is that extra complexity worthwhile?

--Chris

Yes, you're right. I'm definitively centered on an eye candy effect; the labels should stay magnitude dependent.
Now any idea on a distance dependent rendering for manipulations at large scales of any system? via markers?