[subsurface] Prettier profile colors (#89)

[Henrik Brautaset Aronsen]

On 28.11.11 21:29, Dirk Hohndel wrote:
> On Mon, 28 Nov 2011 12:01:22 -0800, Linus Torvalds<torvalds at linux-foundation.org>  wrote:
>> First off, the new background color is some kind of very light beige,
>> which is neutral and fairly pleasing, but the new thin white gridlines
>> are really hard to see. I bet it depends on just how contrasty the
>> monitor settings are, but and for me it's kind of borderline usable,
>> but it's borderline enough that I worry. The yellow warning markers
>> are also much less visible.
> I tried this on three different systems with different monitors. Haven't
> found one where the gridlines work. The warning markers on the other
> hand are now a bit less obnoxious - that I'm fine with :-)

I guess the grid color should be more visible.  Not too much, though, it 
was really too verbose in the previous version.

>> I like the new water fill colorization, though.
> Me too, but if we do the 'darker blue as we go deeper' thing, then that
> should be on a fixed scale - i.e. the deepest blue that you get should
> be proportional to the deepest depth that is displayed ramble ramble ramble

Yikes, what have I started? :)

>> The depth printout changes are horrible, though, and totally unusable.
>> We used to have nice readable "black-on-white" depth markers, they
>> have now turned into these monstrous bold-black text on top of gray.
>> That's not just ugly, it's also totally unreadable on lots of
>> real-life printers that do gray with various dithering schemes (think
>> traditional laser printer), so now that text is just an unreadable
>> blob when actually printed out.
> Completely unreadable. That part gets a NAK from me, too.

 From me as well.  I completely overlooked the printout part.

>> Finally, in the code itself, I kind of like having things in one
>> place, but quite frankly, that one table is broken. It turns the
>> random "color indexes" into random RGB values, which makes it not very
>> readable at all.

Yeah, I thought of that as well, I just wanted to have the colors in one 
place first to see what you guys thought.   On the other hand, I read 
RGB fluently, so I don't think they look random at all :)

>> Yes. Also, you still do three lookup tables right now for no good
>> reason. Why don't you have one table that matches a color name into rgba
>> for screen and rgb for print. And then have one table with the color_t
>> enum as index into it that matches the different values to a color. And
>> then simply use the color_t values to index into that one table.

Well, I didn't remove the sac_color and velocity_color tables since they 
where dependent on calculated index numbers.  Wouldn't want to mess up 
more code in this commit.

>> Finally: maybe you should make the "rgb_t" a "rgba_t". Now you have
>> that odd "we have indexes to the color table, and then we have a
>> separate alpha channel value". But who knows. I don't have a very
>> strong opinion on this part.
> I think if we go this direction we really want just one table with rgba
> for screen and then rgb for print. After all the goal is to make things
> more simple, right?

Good thinking.

I was planning to work some more on the patch tonight, but I cannot get 
anything to build at home right now.   Worked like a charm at work.  
Bah.  Feel free to fix my mess if you want :)

Henrik