| Re: IDL for windows :-{ [message #15389] |
Sun, 16 May 1999 00:00 |
Mike Klein
Messages: 2
Registered: May 1999
|
Junior Member |
|
|
David Fanning wrote:
> Here, as a public service, is a Read_Pixel for Windows!
Thanks for writing this routine for those who, like me, are
widget-challenged. It's very nice. In defense of what probably appears
to be my laziness, let me say that I've tried -- ok, not very hard -- to
come up with an app for my research group that required, or would be
significantly helped by, a graphical interface. Widget apps look nice,
but I've been able to get the job done w/o them -- at least until using
the Windows version of IDL.
> Uh, RDPIX was written in 1987! I think Microsoft was still
> located in Albuquerque.
And I think we'd all be better off if they had stayed there...
Regards,
Mike Klein
|
|
|
|
| Re: IDL for windows :-{ [message #15391 is a reply to message #15389] |
Sat, 15 May 1999 00:00  |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
I wrote yesterday:
> Uh, RDPIX was written in 1987! I think Microsoft was still
> located in Albuquerque. And Windows IDL was not even a
> twinkle in David Stern's eye. I suggest you learn how to
> write your own nifty RDPIX as a widget program. It would work
> better and you would learn something in the process. Take about
> 10 minutes, I think. Course, you could modify the RDPIX code.
> That would take about 30 seconds, probably. After you figured
> out all those abbreviated keyword names. :-)
Here, as a public service, is a Read_Pixel for Windows!
It took 15 minutes, but I documented it. Something the
original was lacking. :-)
ftp://www.dfanning.com/pub/dfanning/outgoing/misc/read_pixel .pro
Cheers,
David
P.S. Should even work on UNIX and VMS machines. :-)
--
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: IDL for windows :-{ [message #15401 is a reply to message #15391] |
Fri, 14 May 1999 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Stein Vidar Hagfors Haugan (steinhh@ulrik.uio.no) writes:
> Sure, Dave, from my original post:
>
>> As an extra bonus, it would be *very* nice if one could specify
>> more than one such "interactive colormap" - i.e. along the lines
>> of:
>> newmap = obj_new('pseudomap') ;; Create a new (interactive)
>> ;; colormap
>> window,2,pseudo=newmap ;; Both windows share this new map
Ah, yes. I remember this now, Stein Vidar. Good ideas. But
I see it involves objects (as it almost has to). I fooled
around with a color "lurker" object some time ago. It would
lurk in the background paying attention to when color tables
were loaded and if a window it was "managing" was open it
would redisplay the graphics command in that window by
calling the Draw method of a graphics object.
I recall it working great (I accidentally deleted the
code in a disk cleaning frenzy) with the graphics objects
I was working with at the time (plot and contour objects
that used direct graphics calls). But I remember thinking
that it wouldn't be too hard to write an XWindow-like
object wrapper around *any* graphics command, so that
windows could be automatically updated.
I recall that I needed (or *thought* I needed a singleton
object). I've just re-read JD's thoughts on that and have
some ideas on how it could be implemented to serve this
need.
But...it will have to wait. My mother arrives for a visit
tomorrow and if she sees my house in this state it will
go badly for me. :-(
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: IDL for windows :-{ [message #15402 is a reply to message #15401] |
Fri, 14 May 1999 00:00 |
steinhh
Messages: 260
Registered: June 1994
|
Senior Member |
|
|
In article <MPG.11a5ce9f12a213179897a2@news.frii.com>
davidf@dfanning.com (David Fanning) writes:
> P.S. Tell me again how IDL is going to know I want
> the colors in *this* window updated, but not the
> colors in *that* window over there? Because one of
> the best features of 24-bit color is that colors
> *don't* change. Which means, of course, that I can
> have 10 images, each displayed with a different color
> table, on the display at the same time and change only
> the one I want to change.
Sure, Dave, from my original post:
> As an extra bonus, it would be *very* nice if one could specify
> more than one such "interactive colormap" - i.e. along the lines
> of:
> window,0 ;; Default window creation, means "use the
> ;; current colormap (let's call it "map1"),
> ;; in interactive mode ("value" backing store)
> tvscl,image1 ;; Display image1 with this color map
> window,1 ;; Create new window, still using map1
> tvscl,image2
> xloadct ;; Manipulate current map, with instant
> ;; update of window 0 and 1 (since they're
> ;; both using the map that's manipulated).
> newmap = obj_new('pseudomap') ;; Create a new (interactive)
> ;; colormap
> window,2,pseudo=newmap ;; Both windows share this new map
> window,3,pseudo=newmap ;;
> :
> xloadct ;; Manipulates current (i.e. "newmap") color table,
> ;; updating window 2 & 3, no effect on 0 and 1.
> wset,0 ;; Now we're switching to a window using map1
> xloadct ;; Manipulate map1 again.. no effect on window
> ;; 2 and 3, but instant update of 0 and 1.
> In the case of an 8-bit display, all the color tables would
> probably be identical, with changes to one reflected in all
> windows. Or maybe one could still have different color tables
> internally, and the effective one (the one that's actually
> communicated to the screen hardware) would depend on which window
> was selected/active (wset)?
Simple and efficient, aint it? I've had responses by email
ranging from
"You've pretty much expressed what I want for next Christmas"
to
"One word...ditto!"
I cannot see that this will involve such a great deal of
hassle compared to the ability to have RETAIN=2 for graphics
windows....
Regards,
Stein Vidar
|
|
|
|
| Re: IDL for windows :-{ [message #15403 is a reply to message #15401] |
Fri, 14 May 1999 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Stein Vidar Hagfors Haugan (steinhh@ulrik.uio.no) writes:
> I have a better suggestion: Join the protest group against this
> un-IDL-like behaviour and demand that RSI does something to
> amend this...:-)
My check and application are in the mail. :-)
Cheers,
David
P.S. Tell me again how IDL is going to know I want
the colors in *this* window updated, but not the
colors in *that* window over there? Because one of
the best features of 24-bit color is that colors
*don't* change. Which means, of course, that I can
have 10 images, each displayed with a different color
table, on the display at the same time and change only
the one I want to change.
Could it be most of us learned IDL from the same
One-Color-Table-EVER!!! perspective favored by RSI?
--
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: IDL for windows :-{ [message #15406 is a reply to message #15401] |
Fri, 14 May 1999 00:00 |
steinhh
Messages: 260
Registered: June 1994
|
Senior Member |
|
|
In article <MPG.11a5183cefa6d02c98979e@news.frii.com>
davidf@dfanning.com (David Fanning) writes:
Mike Klein (mgk@pogo.ab.umd.edu) writes:
>> After having used IDL for years on UNIX systems, I am struggling with
>> the user interface of the version for Windows. Can anyone tell me how
>> to do any of the following:
>>
>> 1. Eliminate the command input window, and enter commands directly in
>> the output log window - just like an xterm.
>
> I'm afraid you will have to get used to disappointment, here. :-(
What! You mean the only way to get IDL to behave non-windozily
on windows is to use callable IDL to write a tty-like input
front-end??
>> 4. For a displayed image, how can I change its colors without having to
>> re-load the image after changing the color table? For example, clicking
>> through the entries in XLOADCT immediately changes the colors in all
>> windows on my UNIX machine. I've turned off decomposed color
>> (device,decomposed=0), which doesn't seem to affect this behavior.
>
> Set your graphics card to 256 colors.
I have a better suggestion: Join the protest group against this
un-IDL-like behaviour and demand that RSI does something to
amend this...:-) Without interactive rescaling of the color table
(with automatic effect on displayed images), the "I" in IDL
is no longer.
Se my posting "Re: 24-bit/8-bit color (Re: read_tiff - simple question)"
from about the end of April for a good (IMO) start on what
they should offer....
Stein Vidar
|
|
|
|
| Re: IDL for windows :-{ [message #15413 is a reply to message #15401] |
Thu, 13 May 1999 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Mike Klein (mgk@pogo.ab.umd.edu) writes:
> After having used IDL for years on UNIX systems, I am struggling with
> the user interface of the version for Windows. Can anyone tell me how
> to do any of the following:
>
> 1. Eliminate the command input window, and enter commands directly in
> the output log window - just like an xterm.
I'm afraid you will have to get used to disappointment, here. :-(
> 2. Clear the output log window programmatically, rather than by doing a
> right-click -> Clear Log mouse operation.
Same with this, sorry.
> 3. Running the RDPIX routine in an xterm results in a stationary
> display of: x, y, value - nice and simple. This, umm, doesn't quite
> work same way in the windows version. In fact, it sometimes crashes IDL
> on my system as the horizontal scroll bar in the output log window gets
> smaller and smaller...
Uh, RDPIX was written in 1987! I think Microsoft was still
located in Albuquerque. And Windows IDL was not even a
twinkle in David Stern's eye. I suggest you learn how to
write your own nifty RDPIX as a widget program. It would work
better and you would learn something in the process. Take about
10 minutes, I think. Course, you could modify the RDPIX code.
That would take about 30 seconds, probably. After you figured
out all those abbreviated keyword names. :-)
> 4. For a displayed image, how can I change its colors without having to
> re-load the image after changing the color table? For example, clicking
> through the entries in XLOADCT immediately changes the colors in all
> windows on my UNIX machine. I've turned off decomposed color
> (device,decomposed=0), which doesn't seem to affect this behavior.
Set your graphics card to 256 colors.
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
