Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
Re: 16-bit colors in Linux (Re: 24 bit colors in IDL)
"G. Hugh SONG" <ghsong@\"Spamspoiler\"kjist.ac.kr> writes: > I really don't understand why this must be this much > complicated. It's more fun this way. > Originally whose fault is this for this complication > on different machines? I vote for Bill Gates, but I really don't know who else is running. > On my Linux, it appears that different XFree86 servers > have different color devices or whatever. > Admittedly, I don't know what is going on. As I understand it, XFree86 servers only support 8 and 16 bit color. You *don't* want to use 16-bit color because it is NOT supported at all by IDL. I'd shell out the $25 or whatever and get a Linux driver from someone who has written a driver for your particular graphics card. You probably really want 24-bit color. > I simply want the color resources should not be > exhausted and be correctly displayed if I use more than > 8-bit colors. Yet, IDL does not fire up without doing something > special at 16-bit colors. Yes. See above. :-) > Is this because there are variations such as > TrueColor and DirectColor on different Unix/X11 > machines? No. It is because IDL does not support 16-bit color on ANY platform, except accidentally on Windows. > There must be a FAQ on this topic. > Can someone direct me to FAQ? Mike? Where are you when we need you? Here is the IDL FAQ: http://www.ivsoftware.com/idl_faq.html Mike has been busy writing reviews for my book on Amazon.com, so he may not have had time to get to this color thing yet. :-) Cheers, David P.S. For those interested, the book has moved up to 85,022th most popular book on the site. (Up from 172,345th.} Perhaps soon they will actually take notice of me and place an order with me. I've heard that several people have tried to order from them, so far all without success. :-( -- David Fanning, Ph.D. Fanning Software Consulting Phone: 970-221-0438 E-Mail: davidf@dfanning.com Coyote's Guide to IDL Progamming: http://www.dfanning.com/
16-bit colors in Linux (Re: 24 bit colors in IDL)
David Fanning wrote: > Andy Bristow (ajbristow@dera.gov.uk) writes: > >> I was just getting my head round 24-bit, having been prompted by this >> thread. So, at Philip's suggestion I went to >> >> http://www.dfanning.com/tips/colors24.html >> >> All well and good. Sounds relatively straightforward. >> >> So on my SGI (IRIX 6.5.1, IDL 5.1) I tried some of the >> suggested code (immediatley after starting IDL up): >> >> device,decomposed=0 >> tvlct,[[255],[255],[0]],100 >> plot,randomu(10,10),color=100 >> >> expecting the plot to be yellow, as advertised. Except no, _I_ >> get a medium-light shade of grey! >> >> Any suggestions? > > Oh, dear. I think this is one of those TrueColor/DirectColor > tricks that SGI engineers like to play on people. This is > a complication that I don't *even* want to know about. > > Try this. Type this: > > Device, Get_Visual_Name=thisName > Print, thisName > > If thisName is "TrueColor" change it to "DirectColor": > > Device, DirectColor=24 > > If thisName is "DirectColor" change it to "TrueColor": > > Device, TrueColor=24 > > Do this *before* you open any graphics windows in IDL. > Try the code above again. Different? The same? > > Please let us know. :-( > > Cheers, > > David > > Note: A copy of this article was e-mailed to the original poster. Wow! I really don't understand why this must be this much complicated. Originally whose fault is this for this complication on different machines? On my Linux, it appears that different XFree86 servers have different color devices or whatever. Admittedly, I don't know what is going on. I simply want the color resources should not be exhausted and be correctly displayed if I use more than 8-bit colors. Yet, IDL does not fire up without doing something special at 16-bit colors. Is this because there are variations such as TrueColor and DirectColor on different Unix/X11 machines? There must be a FAQ on this topic. Can someone direct me to FAQ? THanks -- G. Hugh Song PS: Please remove "Spamspoiler" when replying
In article <7316c4$n6r$1@news.kjist.ac.kr>, "G. Hugh SONG" <ghsong@\"Spamspoiler\"kjist.ac.kr> writes: > > BTW, using IDL /pv~Wave for scientific plotting works does not make > much sense. But, I want full programmability. I don't need image > manipulation. Is there any share-ware thing close to IDL/PV~Wave for > this purpose? I have been thinking of getting out of the commercial > program. Gnuplot cannot do 3-D(such as a sphere) as well as > IDL/PV-wave. Can SCILAB do such a thing? If it does I am > going to switch to SCILAB. > You might try yorick - it's an interpreted language, and in some ways is quite like IDL. For example, the following commands are valid yorick commands: x = indgen(10) print, x There are significant differences too, though. For example, yorick arrays are 1 indexed, like fortran :-( ftp://icf.llnl.gov/pub/Yorick/yorick-ad.html -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~ Robert S. Mallozzi 256-544-0887 Mail Code ES 84 Work: http://www.batse.msfc.nasa.gov/ Marshall Space Flight Center Play: http://cspar.uah.edu/~mallozzir/ Huntsville, AL 35812 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~
Unless you are using IDL 5.5 16 bit displays are not supported. AFAIK, only 8 and 24 bit displays are supported on IDL 5.4 and below. My guess is that your previous workstation sported a 24 bpp display? Does your display adapter support 24 bpp? Maybe you can add a few lines to your XFree config file to include a 24bpp mode. 5.5 has improved support for "other" bit depths like 16 and 32. -Rick "James Kuyper" <kuyper@gscmail.gsfc.nasa.gov> wrote in message news:3BF00F3F.831BD164@gscmail.gsfc.nasa.gov... > I would like to display RGB images, with, for instance higher values for > the Red component causing redder colors, and higher values of the blue > component making them bluer. I used to be able to do that pretty easily, > using the > > tv,image,/true > > However, since I've been moved to a Linux workstation, it doesn't work. > I could provide detailed symptoms if you want, but it's obviously a > configuration problem, so maybe the easiest way is to ask how I need to > configure my IDL session to display these things properly. Attached is a > copy of the xdpyinfo output for my system. What device commands should I > use? > > -- > James Kuyper > MODIS Level 1 Lead > Science Data Support Team > (301) 352-2150 ------------------------------------------------------------ ---------------- ---- > name of display: :0.0 > version number: 11.0 > vendor string: The XFree86 Project, Inc > vendor release number: 3360 > maximum request size: 4194300 bytes > motion buffer size: 256 > bitmap unit, bit order, padding: 32, LSBFirst, 32 > image byte order: LSBFirst > number of supported pixmap formats: 2 > supported pixmap formats: > depth 1, bits_per_pixel 1, scanline_pad 32 > depth 16, bits_per_pixel 16, scanline_pad 32 > keycode range: minimum 8, maximum 134 > focus: window 0x340000e, revert to PointerRoot > number of extensions: 19 > BIG-REQUESTS > DOUBLE-BUFFER > DPMS > LBX > MIT-SCREEN-SAVER > MIT-SHM > MIT-SUNDRY-NONSTANDARD > RECORD > SECURITY > SHAPE > SYNC > XC-APPGROUP > XC-MISC > XFree86-DGA > XFree86-Misc > XFree86-VidModeExtension > XInputExtension > XKEYBOARD > XTEST > default screen number: 0 > number of screens: 1 > > screen #0: > dimensions: 1152x864 pixels (390x293 millimeters) > resolution: 75x75 dots per inch > depths (1): 16 > root window id: 0x26 > depth of root window: 16 planes > number of colormaps: minimum 1, maximum 1 > default colormap: 0x23 > default number of colormap cells: 64 > preallocated pixels: black 0, white 65535 > options: backing-store YES, save-unders YES > largest cursor: 64x64 > current input event mask: 0xf8603f > KeyPressMask KeyReleaseMask ButtonPressMask > ButtonReleaseMask EnterWindowMask LeaveWindowMask > ButtonMotionMask KeymapStateMask SubstructureNotifyMask > SubstructureRedirectMask FocusChangeMask PropertyChangeMask > ColormapChangeMask > number of visuals: 1 > default visual id: 0x22 > visual: > visual id: 0x22 > class: TrueColor > depth: 16 planes > available colormap entries: 64 per subfield > red, green, blue masks: 0xf800, 0x7e0, 0x1f > significant bits in color specification: 6 bits >
Rick Towler wrote: > > Unless you are using IDL 5.5 16 bit displays are not supported. AFAIK, only > 8 and 24 bit displays are supported on IDL 5.4 and below. My guess is that > your previous workstation sported a 24 bpp display? Does your display > adapter support 24 bpp? Maybe you can add a few lines to your XFree config > file to include a 24bpp mode. I'm using IDL 5.4.1. My previous display was a 24 bpp one. I think my system can be configured to run in 24bpp mode, but that configuration seems to be controlled by the sysadmins, and they've been slow to respond to my requests. -- James Kuyper MODIS Level 1 Lead Science Data Support Team (301) 352-2150
James Kuyper (kuyper@gscmail.gsfc.nasa.gov) writes: > I'm using IDL 5.4.1. My previous display was a 24 bpp one. I think my > system can be configured to run in 24bpp mode, but that configuration > seems to be controlled by the sysadmins, and they've been slow to > respond to my requests. Have you offered your first-born child? That sometimes works. Cheers, David -- David W. Fanning, Ph.D. Fanning Software Consulting Phone: 970-221-0438, E-mail: david@dfanning.com Coyote's Guide to IDL Programming: http://www.dfanning.com/ Toll-Free IDL Book Orders: 1-888-461-0155
David Fanning wrote: > > James Kuyper (kuyper@gscmail.gsfc.nasa.gov) writes: > >> I'm using IDL 5.4.1. My previous display was a 24 bpp one. I think my >> system can be configured to run in 24bpp mode, but that configuration >> seems to be controlled by the sysadmins, and they've been slow to >> respond to my requests. > > Have you offered your first-born child? That > sometimes works. Unfortunately, I don't have one to offer. ;-) Luckily, it wasn't necessary; they've promised to switch it to 24-bit mode sometime this week. However, I've also asked for the ability to switch configurations myself, without their intervention - they didn't respond to that part of the request. -- James Kuyper MODIS Level 1 Lead Science Data Support Team (301) 352-2150
James Kuyper wrote: > > David Fanning wrote: >> >> Have you offered your first-born child? That >> sometimes works. > > Unfortunately, I don't have one to offer. ;-) You're welcome to borrow mine. I guarantee the sysadmin will do what you need today, in 2-20 min. They will also pay you to take him back. The only problem is, the UN may disapprove, since the method is inhumane :) Cheers, Pavel
You should be able to do this easily.... If you are content with booting to the terminal and launching X manually you can specify what your desktop bit depth is. It has been a while since a linux box sat on my desk (ahhh, those were the days....) but last time I knew "startx -- -bpp 16" would get your 16bpp and as you can guess "startx -- -bpp 24" would get you 24. If you are logged in and you need to change it, you would have to quit your desktop manager, then restart X at the appropriate bit depth. If your admin doesn't know how to change this boot behavior, let me know. I may be able to dredge the name of the file where you change the "boot to run level" setting out of my feeble brain. If you boot to XDM (or GDM or whatever your desktop flavor calls it) which is the graphical login manager, I don't think you can change the desktop bit depth easily. But then again like I said, it has been a while since I have had a linux box on my desk. Chek www.freshmeat.net for a tool that might do this. -Rick "James Kuyper" <kuyper@gscmail.gsfc.nasa.gov> wrote in message news:3BF1411E.59DB9CEA@gscmail.gsfc.nasa.gov... > David Fanning wrote: >> >> James Kuyper (kuyper@gscmail.gsfc.nasa.gov) writes: >> >>> I'm using IDL 5.4.1. My previous display was a 24 bpp one. I think my >>> system can be configured to run in 24bpp mode, but that configuration >>> seems to be controlled by the sysadmins, and they've been slow to >>> respond to my requests. >> >> Have you offered your first-born child? That >> sometimes works. > > Unfortunately, I don't have one to offer. ;-) > > Luckily, it wasn't necessary; they've promised to switch it to 24-bit > mode sometime this week. However, I've also asked for the ability to > switch configurations myself, without their intervention - they didn't > respond to that part of the request. > > -- > James Kuyper > MODIS Level 1 Lead > Science Data Support Team > (301) 352-2150
Rick Towler wrote: > > You should be able to do this easily.... > > If you are content with booting to the terminal some places (usually ones with lotsa big computey-type machines) don't allow you to do that (here for example) so... > and launching X manually you > can specify what your desktop bit depth is. thusly, can't do it. Wouldn't surprise me if GSFC was a place where the sysadmins rule this option out. (I was talking to a sysadmin the other day that had a PC hacked into *while* she was building linux on it! Man.) paulv -- Paul van Delst Religious and cultural CIMSS @ NOAA/NCEP purity is a fundamentalist Ph: (301)763-8000 x7274 fantasy Fax:(301)763-8545 V.S.Naipaul
Rick Towler wrote: > > You should be able to do this easily.... > > If you are content with booting to the terminal and launching X manually you > can specify what your desktop bit depth is. It has been a while since a > linux box sat on my desk (ahhh, those were the days....) but last time I > knew "startx -- -bpp 16" would get your 16bpp and as you can guess > "startx -- -bpp 24" would get you 24. If you are logged in and you need to On my home machine, "startx -- -depth 24" is the appropriate command. The man page identifies "-bpp" as obsolete. > change it, you would have to quit your desktop manager, then restart X at > the appropriate bit depth. If your admin doesn't know how to change this > boot behavior, let me know. I may be able to dredge the name of the file > where you change the "boot to run level" setting out of my feeble brain. I've asked about this, but the sysadmins are unwilling to allow manual launching of X. > If you boot to XDM (or GDM or whatever your desktop flavor calls it) which > is the graphical login manager, I don't think you can change the desktop bit That's precisely my situation (with gdm). -- James Kuyper MODIS Level 1 Lead Science Data Support Team (301) 352-2150
James Kuyper wrote: > Rick Towler wrote: >> >> You should be able to do this easily.... >> >> If you are content with booting to the terminal and launching X manually >> you >> can specify what your desktop bit depth is. It has been a while since a >> linux box sat on my desk (ahhh, those were the days....) but last time I >> knew "startx -- -bpp 16" would get your 16bpp and as you can guess >> "startx -- -bpp 24" would get you 24. If you are logged in and you need >> to > > On my home machine, "startx -- -depth 24" is the appropriate command. > The man page identifies "-bpp" as obsolete. > >> change it, you would have to quit your desktop manager, then restart X at >> the appropriate bit depth. If your admin doesn't know how to change this >> boot behavior, let me know. I may be able to dredge the name of the file >> where you change the "boot to run level" setting out of my feeble brain. > > I've asked about this, but the sysadmins are unwilling to allow manual > launching of X. > It's pretty hard to prevent. Linux supports multiple displays on the same monitor in the same way that it supports multiple consoles by using the virtual consoles. You can start a second X server, running on display :1. You switch between :0 and :1 with ctrl-alt-F7 and ctrl-alt-F8 (the second display uses the next available virtual console by default). I'm not sure if you can have more as I've only ever used :0 for 24bit and :1 for 8bit. If does require that an XF86Config file is set up to handle multiple depths. Unfortunately I've just upgraded to RedHat 7.2 and the XF86Config file I had for multiple depths no longer works. I'll need to fiddle for a while to get my IDL 8 bit display back again :-(. -- ----------------------------------------------------------- Nigel Wade, System Administrator, Space Plasma Physics Group, University of Leicester, Leicester, LE1 7RH, UK E-mail : nmw@ion.le.ac.uk Phone : +44 (0)116 2523568, Fax : +44 (0)116 2523555
Nigel Wade wrote: > > James Kuyper wrote: > >> Rick Towler wrote: ... >> I've asked about this, but the sysadmins are unwilling to allow manual >> launching of X. >> > > It's pretty hard to prevent. > > Linux supports multiple displays on the same monitor in the same way that > it supports multiple consoles by using the virtual consoles. > > You can start a second X server, running on display :1. You switch between > :0 and :1 with ctrl-alt-F7 and ctrl-alt-F8 (the second display uses the > next available virtual console by default). I'm not sure if you can have > more as I've only ever used :0 for 24bit and :1 for 8bit. > > If does require that an XF86Config file is set up to handle multiple depths. The one for my machine at work isn't set up for multiple depths. However, I'll try that on my home machine. I never really understood how :1 works, more precisely, I was unaware that you could get to it by switching virtual consoles. Thanks! -- James Kuyper MODIS Level 1 Lead Science Data Support Team (301) 352-2150
"David Fanning" <david@dfanning.com> wrote in message news:MPG.1659f5118186501f989767@news.frii.com... > James Kuyper (kuyper@gscmail.gsfc.nasa.gov) writes: Do they teach sysadmins to make the process of getting their help to be difficult as possible in order to keep the number of questions to a minimum? Maybe if they had a task sheet that everyone could see and sign up for help, we would be a lot less likely to think they are a bunch of power hungry lazy ass-holes. :)
James Kuyper wrote: > Nigel Wade wrote: >> >> James Kuyper wrote: >> >>> Rick Towler wrote: > ... >>> I've asked about this, but the sysadmins are unwilling to allow manual >>> launching of X. >>> >> >> It's pretty hard to prevent. >> >> Linux supports multiple displays on the same monitor in the same way that >> it supports multiple consoles by using the virtual consoles. >> >> You can start a second X server, running on display :1. You switch >> between >> :0 and :1 with ctrl-alt-F7 and ctrl-alt-F8 (the second display uses the >> next available virtual console by default). I'm not sure if you can have >> more as I've only ever used :0 for 24bit and :1 for 8bit. >> >> If does require that an XF86Config file is set up to handle multiple >> depths. > > The one for my machine at work isn't set up for multiple depths. > However, I'll try that on my home machine. I never really understood how > :1 works, more precisely, I was unaware that you could get to it by > switching virtual consoles. Thanks! > I've managed to get an secondary X server running with RH7.2. Unfortunately it refuses all connections, even from the window manager. Not very useful. The setup which used to work with vn. 4.0.1 of XFree86 no longer works with the 4.1 version supplied with RH7.2. Whether that's a new "feature" or a bug or a problem with the RH supplied rpms I don't know at the moment. I had thought that it was possible for a user to run a second X server and specify their own XF86onfig file, but it appears that the security of the X server won't allow that. So you will need to get the cooperation of your sys admin to have multiple screen depths. -- ----------------------------------------------------------- Nigel Wade, System Administrator, Space Plasma Physics Group, University of Leicester, Leicester, LE1 7RH, UK E-mail : nmw@ion.le.ac.uk Phone : +44 (0)116 2523568, Fax : +44 (0)116 2523555
Logan Lindquist wrote: > "David Fanning" <david@dfanning.com> wrote in message > news:MPG.1659f5118186501f989767@news.frii.com... >> James Kuyper (kuyper@gscmail.gsfc.nasa.gov) writes: > > > Do they teach sysadmins to make the process of getting their help to be > difficult as possible in order to keep the number of questions to a > minimum? No, we learn that through having to solve users self-inflicted problems. > Maybe if they had a task sheet that everyone could see and sign > up for help, we would be a lot less likely to think they are a bunch of > power hungry lazy ass-holes. > > :) I think your sysadmin needs to introduce a new policy of expiring passwords each week. That ought to help. ;-) -- ----------------------------------------------------------- Nigel Wade, System Administrator, Space Plasma Physics Group, University of Leicester, Leicester, LE1 7RH, UK E-mail : nmw@ion.le.ac.uk Phone : +44 (0)116 2523568, Fax : +44 (0)116 2523555
Logan Lindquist wrote: > > Do they teach sysadmins to make the process of getting their help to be > difficult as possible in order to keep the number of questions to a minimum? > Maybe if they had a task sheet that everyone could see and sign up for help, > we would be a lot less likely to think they are a bunch of power hungry lazy > ass-holes. My my. I think folks using computers with that sort of attitude get *special* attention from sysadmins ;o\ My approach has been to learn something about the system(s) I'm using so that when I do ask sysadmins a question, it's an intelligent one. And I'm not being flippant with the "intelligent" remark - a lot of times it's hard to pose the question so that it targets the problem rather than it's symptoms. If your above post is indicative of the relationship/opinions you have of your local sysadmin, I think you should supply them with tasty pastries every Friday morning for a month in apology. :o) paulv -- Paul van Delst Religious and cultural CIMSS @ NOAA/NCEP purity is a fundamentalist Ph: (301)763-8000 x7274 fantasy Fax:(301)763-8545 V.S.Naipaul