| Re: Pixmap Problems [message #7126 is a reply to message #6988] |
Mon, 30 September 1996 00:00   |
steinhh
Messages: 260
Registered: June 1994
|
Senior Member |
|
|
Path: medusa.uio.no!steinhh
Newsgroups: comp.lang.idl-pvwave
Sender: steinhh@amon (Stein Vidar Hagfors Haugan)
From: steinhh@amon.uio.no (Stein Vidar Hagfors Haugan)
Distribution: world
References: <322EDB2A.167EB0E7@scr.siemens.com>
Reply-To: steinhh@amon.uio.no (Stein Vidar Hagfors Haugan)
Organization: Institute for Theoretical Astrophysics
Subject: Re: Pixmap Problems
In article <322EDB2A.167EB0E7@scr.siemens.com>, Kenneth Kump <kkump@scr.siemens.com> writes:
|> 1) I have created a "mask" pixmap. It consists of 0's and
|> 255's. The intention is to display an image, then do
|> device,set_graphics=1 (this is an AND) then do
|> device,copy=[...]. What happens is strange. The values which
|> are to be masked to Zero get a displayed color which is
|> very odd and random (looks like from private color table).
|> Non masked values are fine. When I do a tvrd() it has the
|> correct values, and I can re-tv this captured image and
|> it is perfect.
|>
|>
|> 2) I create pixmap and tv a value of !d.n_colors-1 (RED).
|> Now I do a device,copy=[] (regular graphics mode)
|> and what I get is white instead of red.
|>
|>
|> What's going on? I need the speed of a pixmap, but results are
|> unsatisfactory.
Whenever IDL doesn't grab it's own private colormap, the byte values
actually stored in video memory are not necessarily in the range
(0, !D.N_colors-1), since IDL may not have control over those
"physical" colors. Instead, IDL tries to hide this from the user,
translating between "IDL colors" and "video colors" (also when reading
back with tvrd()).
This sometimes gives odd results when using the graphics functions
the way they apparently should work. E.g., color zero could correspond
to a non-zero value, so doing an XOR with color 0 does not necessarily
leave values untouched (the graphics functions seem to be applied *after*
the translation to physical color numbers).
I seem to remember reading some stuff about this in the reference guide.
From your example #2, it seems IDL doesn't cope well with that translation
with regard to pixmaps. If you can fool IDL into translating the values
correctly (or doing it yourself) when they are put into the pixmap,
you should be OK as to this problem.
Stein Vidar
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
