| Re: Color question (answer is not device,decomposed=0) [message #19799] |
Tue, 25 April 2000 00:00 |
Liam E. Gumley
Messages: 378
Registered: January 2000
|
Senior Member |
|
|
Troy Carter <tcarter@pppl.gov> wrote in message
news:Pine.LNX.4.21.0004242329340.29603-100000@russell.pppl.g ov...
>
> On Mon, 24 Apr 2000, Liam Gumley wrote:
>
>> upgrade to XFree86 version 4 is in order). In addition, I believe that
IDL
>> does *not* support X displays in 16 bpp mode; it only supports 8-bit or
>> 24-bit bpp.
>
> IDL runs fine on a 16 bit display. I do it every day -- in 5.2, it took a
> little trickery (I had to set device,pseudo=8,decomposed=0). But in 5.3
> it starts right up. Yes I am sure the terminal is 16 bit. Perhaps IDL
> effectively runs in 8 bit mode, so perhaps I don't use the 16 bit
> capability, but the point is that I don't have to run in lower color depth
> to get idl to work.
The distinction here is that although IDL will *run* in 16-bit mode, it does
not explicitly support 16-bit mode for Direct Graphics on UNIX platforms (as
it does on Windows platforms for example). See my previous reference to IDL
Tech Tips for the RSI position on this issue.
>> The bottom line:
>> (1) If you want to get IDL running and do some work, then re-configure
your
>> Linux X-server to start in 8 bpp.
>> (2) If you want to tinker with the X-server, try an upgrade to XFree86
4.0
>
> I don't think it is necessary to run in 8bpp mode. 24bit mode works
> great, I have been using it for 1.5 years (linux workstation running idl
> session on solaris box). I have just run into one issue when trying to
> migrate to Object graphics. I think that instead of giving up on 24-bit
> mode I should try to solve the problem and perhaps uncover a bug in IDL or
> XFree86... Who the heck works with 8bit displays anymore anyway!? ;)
If 24-bit mode seems to work fine, then by all means go with it. However I
think you would be surprised by the number of people who work in 8-bit mode
exclusively (I'm not one of them).
> About my particular problem, after some very helpful comments from several
> people (by e-mail mostly), it seems that the problem is due to byte-order
> swapping as the solaris box sends graphics to my x-server. It only
> effects the IDLgrView object -- other objects (plots, axes, text,
> polygons) all render with the correct colors. For this reason, it is
> possible that it is a bug in IDL (problems with dithering or with the
> Mesa libs have been suggested). Thanks to everyone who commented on the
> problem (Randall, Rick, kschultz). When it is completely resolved, I will
> write again to the news group.
The byte-swapping theory sounds interesting. If you can reproduce this
behavior and RSI verifies the bug report, by all means let us know. You
might want to see if you can reproduce the behavior on another Linux host
which is running a different X-server.
I suppose it's time for me to get back in the game and upgrade my trusty
Thinkpad from Redhat 5.0 and IDL 5.1.
Cheers,
Liam.
|
|
|
|
| Re: Color question (answer is not device,decomposed=0) [message #19801 is a reply to message #19799] |
Mon, 24 April 2000 00:00  |
Troy Carter
Messages: 5
Registered: April 2000
|
Junior Member |
|
|
On Mon, 24 Apr 2000, Liam Gumley wrote:
> upgrade to XFree86 version 4 is in order). In addition, I believe that IDL
> does *not* support X displays in 16 bpp mode; it only supports 8-bit or
> 24-bit bpp.
IDL runs fine on a 16 bit display. I do it every day -- in 5.2, it took a
little trickery (I had to set device,pseudo=8,decomposed=0). But in 5.3
it starts right up. Yes I am sure the terminal is 16 bit. Perhaps IDL
effectively runs in 8 bit mode, so perhaps I don't use the 16 bit
capability, but the point is that I don't have to run in lower color depth
to get idl to work.
> The bottom line:
> (1) If you want to get IDL running and do some work, then re-configure your
> Linux X-server to start in 8 bpp.
> (2) If you want to tinker with the X-server, try an upgrade to XFree86 4.0
I don't think it is necessary to run in 8bpp mode. 24bit mode works
great, I have been using it for 1.5 years (linux workstation running idl
session on solaris box). I have just run into one issue when trying to
migrate to Object graphics. I think that instead of giving up on 24-bit
mode I should try to solve the problem and perhaps uncover a bug in IDL or
XFree86... Who the heck works with 8bit displays anymore anyway!? ;)
About XFree86 4.0, I will certainly be trying that as soon as it is a
little more stable. I probably will not be adventurous and I will wait
until RedHat packages it (maybe when the rawhide packages stabilize).
About my particular problem, after some very helpful comments from several
people (by e-mail mostly), it seems that the problem is due to byte-order
swapping as the solaris box sends graphics to my x-server. It only
effects the IDLgrView object -- other objects (plots, axes, text,
polygons) all render with the correct colors. For this reason, it is
possible that it is a bug in IDL (problems with dithering or with the
Mesa libs have been suggested). Thanks to everyone who commented on the
problem (Randall, Rick, kschultz). When it is completely resolved, I will
write again to the news group.
-Troy
--
Troy Carter
tcarter@pppl.gov
(609) 243-3145
|
|
|
|
| Re: Color question (answer is not device,decomposed=0) [message #19802 is a reply to message #19801] |
Mon, 24 April 2000 00:00 |
Liam E. Gumley
Messages: 378
Registered: January 2000
|
Senior Member |
|
|
Rick Towler <rtowler@u.washington.edu> wrote in message
news:3904E168.317ACDB1@u.washington.edu...
> This is really an X windows issue. I am no expert but I lived with this
> same problem for a long while.
>
>> I tried using hardware and software rendering (by using
>> obj_new('IDLgrWindow',renderer= )), but both came up yellow (and perhaps
>> I can't use hardware rendering, although I have Mesa installed, and I
>> have an NVidia TNT card).
>
> This will have no effect since all images are *rendered* on your solaris
> X client and then displayed on your local linux X server. So for every
> "frame" sent to you, every pixel in that frame is sent too.
>
> Your problem lies in the fact that your solaris display is running at 16
> bit and your linux display is at 24 bits. Solaris sends over an 16 bit
> pixel with a that maps incorrectly in you linux X server's 24 bit color
> table. This is why it works on the 16 bit solaris display and not your
> 24 bit linux display.
>
> Easiest solution is to run your linux desktop at 16bbp. If I understood
> you correctly, your Solaris hardware is running at 16bpp and running
> both client and server at the same depth should solve your problem.
>
> You may be able to run your solaris box at 24bpp. This should solve
> your problem too.
>
> Lastly, if your output is static, send it to a .jpg or .gif file and
> view it with a local image viewer (like ee or xv). This is a minor pain
> but it works.
>
> If none of these solutions work for you take a look at the many X
> Windows How-To's (http://www.linuxdoc.org/) I'm sure there you'll find
> a better explanation of your problem and will surely find a better
> solution.
I'm not a Linux expert by any means, but this advice goes against my
understanding of how X-windows works. I think the display configuration of
the remote Sun Solaris box has very little to do with the problem. The
display characteristics detected by IDL on the local Linux box are purely
determined by the X-server running on the Linux box. Therefore I would
suspect the X-server on the Linux box before anything else (perhaps an
upgrade to XFree86 version 4 is in order). In addition, I believe that IDL
does *not* support X displays in 16 bpp mode; it only supports 8-bit or
24-bit bpp.
The bottom line:
(1) If you want to get IDL running and do some work, then re-configure your
Linux X-server to start in 8 bpp.
(2) If you want to tinker with the X-server, try an upgrade to XFree86 4.0
Cheers,
Liam.
PS Linux experts are welcome to enlighten me on this subject.
|
|
|
|
| Re: Color question (answer is not device,decomposed=0) [message #19804 is a reply to message #19801] |
Mon, 24 April 2000 00:00 |
Rick Towler
Messages: 821
Registered: August 1998
|
Senior Member |
|
|
This is really an X windows issue. I am no expert but I lived with this
same problem for a long while.
> I tried using hardware and software rendering (by using
> obj_new('IDLgrWindow',renderer= )), but both came up yellow (and perhaps
> I can't use hardware rendering, although I have Mesa installed, and I
> have an NVidia TNT card).
This will have no effect since all images are *rendered* on your solaris
X client and then displayed on your local linux X server. So for every
"frame" sent to you, every pixel in that frame is sent too.
Your problem lies in the fact that your solaris display is running at 16
bit and your linux display is at 24 bits. Solaris sends over an 16 bit
pixel with a that maps incorrectly in you linux X server's 24 bit color
table. This is why it works on the 16 bit solaris display and not your
24 bit linux display.
Easiest solution is to run your linux desktop at 16bbp. If I understood
you correctly, your Solaris hardware is running at 16bpp and running
both client and server at the same depth should solve your problem.
You may be able to run your solaris box at 24bpp. This should solve
your problem too.
Lastly, if your output is static, send it to a .jpg or .gif file and
view it with a local image viewer (like ee or xv). This is a minor pain
but it works.
If none of these solutions work for you take a look at the many X
Windows How-To's (http://www.linuxdoc.org/) I'm sure there you'll find
a better explanation of your problem and will surely find a better
solution.
Good Luck!
-Rick Towler
David Fanning wrote:
>
> Troy Carter (tcarter@princeton.edu) writes:
>
>> I also tried it on a 16bit x-terminal (running an xsession from the
>> solaris machine) -- this time I get white on black. So, it seems it is
>> my linux box causing the problem...
>
> Sorry, we have rapidly gotten beyond my depth. I'll turn
> you over to the Linux experts in the newsgroup. But from
> the evidence you present, I suspect IDL per se isn't at
> fault, which is pretty much what I expected. :-)
>
> Cheers,
>
> David
>
> --
> David Fanning, Ph.D.
> Fanning Software Consulting
> Phone: 970-221-0438 E-Mail: davidf@dfanning.com
> Coyote's Guide to IDL Programming: http://www.dfanning.com/
> Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: Color question (answer is not device,decomposed=0) [message #19808 is a reply to message #19801] |
Sun, 23 April 2000 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Troy Carter (tcarter@princeton.edu) writes:
> I also tried it on a 16bit x-terminal (running an xsession from the
> solaris machine) -- this time I get white on black. So, it seems it is
> my linux box causing the problem...
Sorry, we have rapidly gotten beyond my depth. I'll turn
you over to the Linux experts in the newsgroup. But from
the evidence you present, I suspect IDL per se isn't at
fault, which is pretty much what I expected. :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: Color question (answer is not device,decomposed=0) [message #19809 is a reply to message #19808] |
Sun, 23 April 2000 00:00 |
Troy Carter
Messages: 5
Registered: April 2000
|
Junior Member |
|
|
Here's the result of the help,/device:
IDL> help,/device
Available Graphics Devices: CGM HP LJ NULL PCL PRINTER PS REGIS TEK X Z
Current graphics device: X
Server: X11.0, The XFree86 Project, Inc, Release 3360
Display Depth, Size: 24 bits, (1600,1200)
Visual Class: TrueColor (4)
Bits Per RGB: 8
Physical Color Map Entries (Used / Total): 256 / 256
Colormap: Private, 16777216 colors. Translation table: Enabled
Graphics pixels: Combined, Dither Method: Ordered
Write Mask: 16777215 (decimal) ffffff (hex)
Graphics Function: 3 (copy)
Current Font: <default>, Current TrueType Font: <default>
Default Backing Store: Req from Server.
and the specific commands you requested:
IDL> Device, Get_Visual_Depth=theDepth, Get_Visual_Name=theName
IDL> Print, theDepth, theName
24TrueColor
I also tried it on a 16bit x-terminal (running an xsession from the
solaris machine) -- this time I get white on black. So, it seems it is
my linux box causing the problem...
I tried using hardware and software rendering (by using
obj_new('IDLgrWindow',renderer= )), but both came up yellow (and perhaps
I can't use hardware rendering, although I have Mesa installed, and I
have an NVidia TNT card).
Any more suggestions? Thanks for responding so quickly!
More info:
xdpyinfo:
[tcarter@russell tcarter]$ xdpyinfo
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 24, bits_per_pixel 32, scanline_pad 32
keycode range: minimum 8, maximum 134
focus: window 0x2c00094, revert to Parent
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: 1600x1200 pixels (406x305 millimeters)
resolution: 100x100 dots per inch
depths (1): 24
root window id: 0x26
depth of root window: 24 planes
number of colormaps: minimum 1, maximum 1
default colormap: 0x23
default number of colormap cells: 256
preallocated pixels: black 0, white 16777215
options: backing-store YES, save-unders YES
largest cursor: 32x32
current input event mask: 0x5a20bd
KeyPressMask ButtonPressMask
ButtonReleaseMask
EnterWindowMask LeaveWindowMask
PointerMotionHintMask
ButtonMotionMask StructureNotifyMask
SubstructureNotifyMask
SubstructureRedirectMask PropertyChangeMask
number of visuals: 1
default visual id: 0x22
visual:
visual id: 0x22
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
David Fanning wrote:
>
> Troy Carter (tcarter@princeton.edu) writes:
>>
>> I am trying to learn to use Object graphics, now that idl 5.3 allows me
>> to create vector eps files using object methods. My problem is that
>> when I draw to a window, and try to get black on white, I end up with
>> black on yellow. White on black works fine, but when I try to set up my
>> IDLgrView object with color=[255,255,255], I get yellow instead of
>> white. The device procedure applies only to direct graphics, so
>> device,decomposed=0 is not the answer (although I tried it anyway :) ).
>> I am running idl on a solaris machine, using the 24-bit display of a PC
>> running linux. Any clues would be much appreciated. Thanks!
>
> Humm. This notion of running on a Solaris machine with
> a Linux display concerns me a bit. It would help, I think,
> to know the results of a HELP, /DEVICE command.
>
> Also, do you have a color table loaded in your IDL session?
> Try loading color table 0 before you run your program.
> Does that do anything?
>
> I'm thinking that you may actually be in an 8-bit
> environment (where object graphics colors don't work
> as well as you would hope) and that IDL is having
> difficulty choosing a white color from the destination
> palette. Yellow may be as close as it can get. Anyway,
> the above command will offer more clues. Please
> also included your visual depth and class:
>
> IDL> Device, Get_Visual_Depth=theDepth, Get_Visual_Name=theName
> IDL> Print, theDepth, theName
>
> Cheers,
>
> David
>
> --
> David Fanning, Ph.D.
> Fanning Software Consulting
> Phone: 970-221-0438 E-Mail: davidf@dfanning.com
> Coyote's Guide to IDL Programming: http://www.dfanning.com/
> Toll-Free IDL Book Orders: 1-888-461-0155
--
Troy Carter
tcarter@princeton.edu
|
|
|
|
| Re: Color question (answer is not device,decomposed=0) [message #19810 is a reply to message #19808] |
Sun, 23 April 2000 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Troy Carter (tcarter@princeton.edu) writes:
>
> I am trying to learn to use Object graphics, now that idl 5.3 allows me
> to create vector eps files using object methods. My problem is that
> when I draw to a window, and try to get black on white, I end up with
> black on yellow. White on black works fine, but when I try to set up my
> IDLgrView object with color=[255,255,255], I get yellow instead of
> white. The device procedure applies only to direct graphics, so
> device,decomposed=0 is not the answer (although I tried it anyway :) ).
> I am running idl on a solaris machine, using the 24-bit display of a PC
> running linux. Any clues would be much appreciated. Thanks!
Humm. This notion of running on a Solaris machine with
a Linux display concerns me a bit. It would help, I think,
to know the results of a HELP, /DEVICE command.
Also, do you have a color table loaded in your IDL session?
Try loading color table 0 before you run your program.
Does that do anything?
I'm thinking that you may actually be in an 8-bit
environment (where object graphics colors don't work
as well as you would hope) and that IDL is having
difficulty choosing a white color from the destination
palette. Yellow may be as close as it can get. Anyway,
the above command will offer more clues. Please
also included your visual depth and class:
IDL> Device, Get_Visual_Depth=theDepth, Get_Visual_Name=theName
IDL> Print, theDepth, theName
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
