RE:Color coding WAS:InSight IML Content Description
- From: <jens persson btj se>
- To: <gnome-list gnome org>
- Subject: RE:Color coding WAS:InSight IML Content Description
- Date: Fri, 13 Feb 1998 13:03:03 +0100
A comment:
I like the idea to use color to code information, but we should let the
user configure what dimension of the color space to move along. To me
and everybody else that have normal color vision it is ok to move along
H but to the 5% of the male population that are color blind V would be a
better dimension to move along.
/jp (in a politically correct mode :-)
>
>
>I'm answering both posts with this one.
>
>Bowie Poag <bjp@primenet.com> writes:
>
>> Easy is the operative word here, I agree. Although I dont know how to
>> code it, I know that performing hue-shifts of reigons of data as small as
>> the one's we're dealing with can be done in realtime with little effort.
>> That was the whole crux of color-reactiveness in InSight's (proposed)
>> desktop.. That we -would- have that computational horsepower available to
>> us to perform a dozen hue shifts on a dozen tiles in realtime.
>
>Right. Almost anything will work on images 64x64 or smaller. Although
>when you have *many* icons to colorize (such as files in a large
>directory), it may become significant.
>
>> > Remember - just because it's in the GIMP does not mean it's practical
>> > for a GUI in general.. some things GIMP does are great for art - but
>> > fairly expensive computationally - and not he thing you want to do on a
>> > regular basis.
>
>The problem here is that you can't do correct hueshift just by
>changing each RGB channel separately - hueshift involves interactions
>between channels. Actually HSV hueshift remapped into RGB space looks
>like one of these:
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]