From pierre@audiovu.com Wed Apr 26 17:05:57 2000 Return-Path: Received: from mgate.uni-hannover.de by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4) id RAA22180; Wed, 26 Apr 2000 17:05:56 +0100 Received: from postfix2.free.fr by mgate.uni-hannover.de (PP) with SMTP; Wed, 26 Apr 2000 17:10:41 +0200 Received: from saturne.audiovu.com (dijon-43-1.dial.proxad.net [213.228.43.1]) by postfix2.free.fr (Postfix) with ESMTP id A7C0C745BC for ; Wed, 26 Apr 2000 17:10:09 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by saturne.audiovu.com (8.9.3/8.8.7) id RAA16499 for neteler@geog.uni-hannover.de; Wed, 26 Apr 2000 17:10:28 +0200 From: Pierre de Mouveaux Reply-To: pmx@audiovu.com To: Markus Neteler Subject: Re: color=Alpha:Red:Green:Blue Date: Wed, 26 Apr 2000 15:53:06 +0200 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: <00042602370800.12679@saturne.audiovu.com> <20000426132040.D20658@hgeo02.geog.uni-hannover.de> In-Reply-To: <20000426132040.D20658@hgeo02.geog.uni-hannover.de> MIME-Version: 1.0 Message-Id: <00042617102501.13555@saturne.audiovu.com> Content-Transfer-Encoding: quoted-printable Sender: pierre@audiovu.com Status: RO X-Status: A Content-Length: 5991 Lines: 154 Le mer, 26 avr 2000, vous avez =E9crit : On mer, 26 avr 2000 you wrote: > On Wed, Apr 26, 2000 at 02:01:22AM +0200, Pierre de Mouveaux wrote: > > Hello Markus > > > The only "limitation" is that the effective range of the future alpha= chanel -if > > any - will have a range of 1->255 and not of 0->255, that mean 0 and = 1 will be > > equivalent. (1 needs to be converted to 0 before drawing, as 0 and 25= 5 are > > special values, specially with Mesa, as they disable completly the CP= U > > intensive alpha chanel processing) It's not a visible difference, as = a value of > > 0 or 1 means: full invisibility!=20 > Mhh, why that? Is O used to indicate transparency? (sorry, I am not > familiar with alpha channels). If so, it should not be a problem if > used just for visualization. As the data will be inchanged, nobody > should complain. I was not clear: the 0 anf 1 are the alpha (aka blend factor, or opacity) values. It doesn't relate directly to the values on a map. The "standard colors" are mostly used for attributes of vector lines, labels or backgro= und. >=20 > Pierre, I think it would be nice to include your new > "devices" attribute and the "color" feature!! Well, there is no real need for updated manpages, at the moment. We could= just say, in front of the top (parent) "display" man page that all modules can= be redirected to a device, if required. Idem for the new color naming. Other= wise, corrections jus need some patience... Idem regarding the modification of the tcltkgrass modules, it's straightf= orward: cut'n paste. A little long, maybe... I will do it a litlle later - I must finish the "color" enhancement of all modules. It must be done very carrefully.=20 - Add a color picker, or at least an extended color list in tcltkgrass. For instance, you could use "dark night blue" backgrounds. This kind of color ("dark night" 0:0:100) entry could be added into tcltkgrass in a ve= ry straightforward way into the existing color list. Pastel colors and ultra-bright one are both useful, I think The d.3d curses interface don't left enough room for color like "rrr:ggg:= bbb", that is 11 chars long. Needs a little more work, then.=20 The next thing I work on is related to the colortables. For instance, Gra= ss doesn't have (built-in) the usual geographic colors: blue for sea, then = green -> brown on mountains, with white mountains top. I do it with the "rules" option, and a text file containing my color steps.=20 It could be possible to enhance the default colortable handling, in a sim= ilar way, allowing two things: - a named colormap search like for finding a raster file (a little differ= ent, though) for "system wide" supplementary colormaps, stored in the "rules" format, and that will be stored into $GISBASE./etc/colortables, for insta= nce. The names could be "geo1", "arctic", "highcontrast", whatever experienced users could contribute and that is of general interest. =20 - some local colormaps, that are to be used through tcltkgrass, and that = are stored in the user's $HOME directory. Not in the $LOCATION. There is a difference between the "user's" colormap template and the "map's" colorma= p itself. Then, we need a colortable editor (indeed!). This is different fr= om the color editing of categories in a map, as we edit a template of colors, n= ot the map itself. This is complementary. Beside the tcltkgrass version, the= re could be an "on-screen" version, with the "graphics" mouse interface of G= rass. Compatibility could maybe force us to do it for people that don't use X,= but=20 some proprietary graphics device. Don't know if there are some of them st= ill in use today.=20 Finally, I need to check how colormaps are related to vector drawings, in= order to have a "true color" attributes related vector map drawing. The idea is= to stick to the colormap concepts, and it's probably already working like th= is. I must admit I only used d.vect for vector drawings, so I'm not realy knowl= egable of the Grass vector tools. While I ported d.display (not finished yet -> many scripts and sub-progra= ms to fix), I found it was not far (in the spirit) of what I finally want to do= : each graphics window holds it's graphics display menus and toolbars, that affe= cts only it's window content: for instance, an erase buton "naturally" erases= the currently active window. You see why I added a "device=3Dxxx" option...=20 Again, this is not done at this time, and there are some subtelties that = need more thinking (do we need a "local-to-this-window" sub-command shell popu= p, for instance?) The idea is to integrate this gracefully into tcltkgrass, if a= t all possible. An to have this "tcltk window" be a new driver. So x0 behaves l= ike usually, and we have an l0 or l1(for local) that's part of the tcltk meca= nism. This could, one day, even support OpenGL, as the driver could (one day ;)= ) ) differenciate between "xN" and "lN" drivers, and optimize things in the l= ater case... There is also a graphics history concept, and a layers concept. B= ut later on this... This will be done with small steps, that all give immedi= ate and usefull improvements. Not a "big picture" that nobody never get to it= s end. Once it will be well engaged, other volunteers could jump in this (The Ca= thedral and the Bazaar...) Before sending such multi-directory patches, I need to verify that my loc= al CVS is compatible with the current CVS repository. There should have been= some updates by many other developers since I got the whole tree, 3 weeks ago = ;) I also really want to be sure that everything works without breaking the previously existing features. I really don't have time to track bugs that= could apear in the "outside word", and answer personnaly to everybody that have= gone into troubles, as I just did with the INFINITY problem. This is a good le= sson. (Hopefully, I corrected it quickely). Free work doesn't mean unresponsible work, we both know it... Bye, Pierre.