From pierre@audiovu.com Wed Apr 26 02:32:56 2000 Return-Path: Received: from mgate.uni-hannover.de by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4) id CAA17336; Wed, 26 Apr 2000 02:32:55 +0100 Received: from postfix1.free.fr by mgate.uni-hannover.de (PP) with SMTP; Wed, 26 Apr 2000 02:38:14 +0200 Received: from saturne.audiovu.com (paris11-nas2-42-92.dial.proxad.net [212.27.42.92]) by postfix1.free.fr (Postfix) with ESMTP id A462D28078 for ; Wed, 26 Apr 2000 02:38:00 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by saturne.audiovu.com (8.9.3/8.8.7) id CAA12699 for neteler@geog.uni-hannover.de; Wed, 26 Apr 2000 02:37:13 +0200 From: Pierre de Mouveaux Reply-To: pmx@audiovu.com To: Markus Neteler Subject: color=Alpha:Red:Green:Blue Date: Wed, 26 Apr 2000 02:01:22 +0200 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <00042602370800.12679@saturne.audiovu.com> Content-Transfer-Encoding: quoted-printable Sender: pierre@audiovu.com Status: RO X-Status: A Content-Length: 2719 Lines: 81 Hello Markus As I told you, I did a little "improvement": now, it's possible to specify colors in the form R:G:B in lieu of "black"= or "green". Old names still works (indeed). The API remains unchanged. I also made provision for transparency (Alpha chanel, in OpenGL terminolo= gy. Note that transparency exists natively under X11 or Windows 95/98/NT's GD= I, but is slow). The big problem is the command line parser. Many programs gives the list = of the standard colors as the list of possible options. Unexpected options stiop= s the module. Obviously, a string like "127:185:224" is not in the list - nor is it a fixed string, as the numerical values will change. So I modified = the G_parser library, and added a new input type, TYPE_COLOR: then, color inp= ut parameters will not be declares as TYPE_STRING, but as TYPE_COLOR., and w= ill be parsed without problems.=20 Now, updating existing modules that initialy rely on the Grass standard c= olors requires only changing the type of the comand line parser option to TYPE_= COLOR. Easy... As I already told you, tcltkgrass is the "number one" candidate to exploi= t this new option. Beside the parser functions, the real work was to change some raster lib functions, and some display lib functions. Backward compatibility is stil= l 100%. The only "limitation" is that the effective range of the future alpha cha= nel -if any - will have a range of 1->255 and not of 0->255, that mean 0 and 1 wi= ll be equivalent. (1 needs to be converted to 0 before drawing, as 0 and 255 ar= e special values, specially with Mesa, as they disable completly the CPU intensive alpha chanel processing) It's not a visible difference, as a va= lue of 0 or 1 means: full invisibility!=20 Well, there is no transparency in Grass for now, anyway. You can then do a=20 =09d.vact map=3Dxxxxx color=3D25:125:160 and you get a smooth mineral blue. If you type only the first number followed by a colon, it's interpreted a= s a shade of gray:=20 =09d.vect color=3D125: and in the future, if you type=20 =09=09d.vact map=3Dxxxxx color=3D165:25:125:160 you will have a transparency level of 165 ;))) (transparency is only one part of the picture. With OpenGL, you get lighh= tness, emissivity and materials. Could help geting a vector map "out of the scre= en" over a complex raster map, or put labels on a gray semi-transparent backg= round, so they are always visible, this effect is often used in video titles)=20 This could be done without changing the already existing modules, only t= he driver, and a controller module: set the parmeters, then draw. Set some o= ther parameters, then draw the next layer. Etc... Really the typical Grass beh= aviour;) Cheers, Pierre.