I never really thought about it in the sense that we'd extrapolate the exact brightness trough lab colorspace X/Z cordinates or something like that...mostly because I am an artist and I've never been able to stand coding..so I dont have that thought set...I think your skillset gives you the capability to understand it with better metaphores in color theory and coding, but you tend to understimate the usefullness of just letting the end user customize things 
s/extrapolate/interpolate
Basically it's because not every ramp is going to end and start on the same brightnesses, we need to know how each destination ramp maps onto the base ramp. Your idea of what would need duplication is slightly different from mine.
Yeah, as a programmer who cares about UI, I try pretty hard to minimize the requirement for customization.
Every additional customization increases the amount of confusion around a program geometrically
Ideally, I think it should just be a way of handling palletes that is ramp-oriented. That is so that when as you said there are ramps of diferent length than the "baserampsize" it is the user that decides how exactly they match up...because no matter how accurate LAB or whatever is it just doesnt know what you're going for.
Say you have the sprite's clothes, then you have his metal armor...and his hair or whatever.
You know that his hair has two extra shadow tones, while the armor has two extra highlight tones...you just scroll the two ramps so they overlap in the way you know they should (excuse the hideous pallete....:p)
So just to be clear, this is your 'more complicated idea'? Explicitly-known ramp ends so you can visually offset them so they line up appropriately?
Actually, that is complicated. And surprising -- apparently I misunderstood your original, simpler idea, because what you describe above is in my understanding not compatible with the above
(because in order for the simpler idea to work (single master ramp mapped to multiple maybe shorter ramps), you basically have to have the equivalent of that offset information anyway
In practice I guess the program would handle the tones from ramps with greater length as duplicate pallete entries (anything past the brightest red color will still be handled as the brightest red) but the idea would be that the program would only do it in a internal file format which would 'know' which are the duplicate entries, and you'd be able to export the file with clean single entries.
Oh I see, you're aiming for just a drawing tool, not also to be able to do strongly controlled colorswaps like I guessed you meant SF3 did. Maybe they didn't have such a thing.
Anyway there's some real benefit to exporting it with duplicate entries, and I would count the result as clean..
What I was thinking is like this:
1. Measure the brightness of the first and last color in the 'base' ramp
2. Normalize the destination ramps according to this (measure their endpoints in order to do this)
3. Allow the user to override the brightness that the end colors of destination ramps are considered as.
4. Nearest-neighbor 'interpolate' and extrapolate each destination ramp so each ramp maps in a fairly reliable way to the original ramp.
(it's trivial to recover the without-duplicates version, providing you store the 'endpoint brightnesses' information with the ramps. duplication is just so ramp-swapping is just a quick matter of copying a tiny chunk of data.)
Now, with this scheme, you could always make sure that all of the colors in your ramps were accounted for, there might be duplicates before or after the original ramp contents (or even during, since the ramp might be stretched.),
and you would always be able to do ramp swapping in a snap. (normally, palette swapping is a snap but not ramp swapping. This is just because the ramps differ in length.)
Let me demonstrate:
It's nothing mind-blowing, but it does make sure a) you only have to do a single lot of shading and b) every ramp can be used in place of any other ramp for that sprite.
Now, suppose you wanted to add the extra shadow tones to the metal as well, but you dont want to add any extra tones
you just tell the program to use the two hair shadow tones for that, we already do that but we've no way of recording that those two entries in the ramp although the same tone as the ones in the hair one, are from the metal ramp. The idea would be to fix that...so that if suddenly it turns out that your game is going to a new platform that allows 2 more shades (or more likely you just decide to feck the limitations) it isnt a mess to recolor.
Oh right. yes, that's kind of problematic. I've been working on that too, it's fairly involved though, I have
'Master palette', 'Resource Ramps', 'Rendering Ramps', 'Rendering palettes'
we're talking about 'Resource Ramps' here (ordered lists of indices into the master palette, basically).
'Rendering ramps' are, roughly, formulae for combining and resampling ramps; 'rendering palettes' are just ordered lists of references to rendering ramps (with possible uneven spacing, but that's only of interest for CGing), which render into normal palettes (among other things.)
I've suggested a simplified version for OHRRPGCE over here:
http://gilgamesh.hamsterrepublic.com/wiki/ohrrpgce/index.php?title=Talk:Plan_for_256_color_sprites&curid=5027&diff=18503&oldid=18502[/quote]
The whole third dimension view to it when adding multiple light sources ( I wonder if light sources is correct..more like chromatic filters..heh) sounds very smart.
[/quote]
It sounded better originally.. but basically, you had just described a new 3-dimensional colorspace..
Not very like RGB, LAB, HSL, Yiq, etc but nevertheless, same basic idea. Lightness Ramp Palette -- LRP colorspace.
Two colors is good.
