| Re: IDL graphics w/ no display [message #41351] |
Wed, 27 October 2004 01:25  |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Ken Mankoff writes:
> I use REBIN. But I can't get it working well anyway (even slowly)
> with maps. The continent and grid lines never scale down well.
>
> Maybe I need to play around with THICK= keywords some more and this
> solution will work?
I doubt it. Maps are particularly recalcitrant.
> I have 6.0, and I heard iMap is slow. So thats not an option. Also,
> without X, can I do object graphics? Not sure... I know I can create
> projections and all that stuff, but can I then display them in a Z
> buffer without accessing X/Win?
No, nothing of object graphics is ever going to be
displayed in the Z-graphics buffer. Object graphics
*is* a Z-graphics buffer. I think any method of display
is going to require connection to a computer with
software installed. :-)
Maybe you should go for that GnuIDL, or whatever it
is called. Those guys don't go in for any frills.
> I am leaning away from OG, even if
> it is possible because a) 6.1, b) speed, and c) mapping routine
> support
I've heard from people trying to get the OG mapping
routines to work that it, uh, needs some more work.
I've only had the barest cursory look myself. There is
something about the maps I don't trust, but I can't work
with the damn things well enough to test anything, so
I can't tell if I am imagining problems that aren't there.
But, anyway, this isn't a solution for you.
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http:/www.dfanning.com/
Phone: 970-221-0438, IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: IDL graphics w/ no display [message #41352 is a reply to message #41351] |
Wed, 27 October 2004 01:16  |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Jeff Guerber writes:
> Standard part of IDL, yes, but aren't they allocated from the windows
> server memory, and thus aren't available without one?
Oh, right, sorry. I think I mis-read the earlier message.
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http:/www.dfanning.com/
Phone: 970-221-0438, IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: IDL graphics w/ no display [message #41354 is a reply to message #41352] |
Tue, 26 October 2004 18:29 |
Ken Mankoff
Messages: 158
Registered: February 2000
|
Senior Member |
|
|
On Mon, 25 Oct 2004, David Fanning wrote:
> KM writes:
>
>> So I am producing images in IDL in Z buffer, writing PNGs to
>> disk, and then telling the frontend (via a socket) that the image
>> is ready. It reads it in and display it in a mac/win-like UI.
>>
>> But there are some limitations to this model.
>>
>> 1) Z buffer is limited to 256 colors. This is not a major
>> limitation, but it does exist
>
> You could use a pixmap rather than the Z-buffer. That would solve
> your color limitations, anyway.
The 256 isn't a major limitation. I can overcome it by a) splitting
the colorbar, or b) reading from the Z buffer, converting to RGB,
and then manipulating the RGB image directly (discussed at the
bottom of this post)
But I cannot use a pixmap, because I am running on machines without
X11. "Window, /pixmap" crashes if it can't access X.
FYI: As a side note, X11 isn't even _installed_ on some machines,
but IDL is linked to X11 libraries, so it crashes if X11 isn't
installed. I am compiling the required libraries from XFree86 (so I
can distributed them without Apple license issues) and running IDL
with the LD_FALLBACK_LIBRARY_PATH environment variable set to my
local library directory.
>> I cannot use the "blow up * 4" trick for Z buffer text
>> [http://dfanning.com/graphics_tips/zfonts.html] because it is too
>> slow. I am using a very fast machine, but doing all the map stuff
>> x4 introduces a 1 second lag.
>
> Could still be a problem. How are you resizing? Using REBIN and
> not CONGRID, I hope. :-)
I use REBIN. But I can't get it working well anyway (even slowly)
with maps. The continent and grid lines never scale down well.
Maybe I need to play around with THICK= keywords some more and this
solution will work?
>> I think I cannot use object graphics because I am working with
>> map projections, map_continents, etc. and these don't work with
>> object graphics, right?
>
> There is some controversy about this, but in any case, I think IDL
> 6.1 is required.
I have 6.0, and I heard iMap is slow. So thats not an option. Also,
without X, can I do object graphics? Not sure... I know I can create
projections and all that stuff, but can I then display them in a Z
buffer without accessing X/Win? I am leaning away from OG, even if
it is possible because a) 6.1, b) speed, and c) mapping routine
support
>> I don't think callable IDL would help. That could replace the
>> socket and file->disk part, but it wouldn't help with the
>> display. Plus, it sounds complex.
>
> I don't think it is anymore complex than what you are doing. A lot
> of people serve IDL images up from web page interfaces with
> reasonable speed and resolution. I think this should be possible
> to do.
But I realize now its not a useful option, because:
* Using callable IDL and direct graphics it is pixelated.
* Using callable IDL and object graphics, it won't work well
because it is map projection data, and I want it done fast.
-------
OK, new idea (same thread, sorry)
I know writing an anti-aliasing function isn't very hard. (But would
it be fast enough?) What if I:
1) do my data with map_set, then read it out, and convert it to RGB
2) erase the Z buffer, and do a map_grid, map_continents, xyouts
3) read this out and anti-alias it.
4) add the anti-aliased image from (3) to the image from (1)
5) write out to disk.
Has anyone done anything like this before? Any advice before I start
out? Sounds like it'll work to me. But again, its been a few years
since I coded IDL...
-k.
|
|
|
|
| Re: IDL graphics w/ no display [message #41355 is a reply to message #41354] |
Tue, 26 October 2004 15:57 |
Jeff Guerber
Messages: 41
Registered: July 2000
|
Member |
|
|
On Tue, 26 Oct 2004, David Fanning wrote:
> Jeff Guerber writes:
>
>> Errr, I'm not sure if anyone's mentioned this yet (our news server
>> seems to miss a lot of messages), but aren't pixmaps entirely creatures of
>> the X server?
>
> No, they are a standard part of IDL. I use them each
> and every day. Couldn't live without them. :-)
Standard part of IDL, yes, but aren't they allocated from the windows
server memory, and thus aren't available without one? I only find them
mentioned in the X device section of the manuals. Trying to create one
just now with my X-server shut down gives "X connection to ... broken
(explicit kill or server shutdown)". (IDL 6.0.3 (hp-ux hp_pa m64),
displaying on a PC running X-Win32 (which I shut down for this
experiment.)
(Maybe the WIN device provides them too, and has them always present?
I haven't tried it with other devices.)
>> P.S. David, did you get the email I sent you a few weeks ago about
>> fsc_field and fsc_color?
>
> I've had an overzealous spam filter lately, and I find
> quite a few messages I *should* have gotten in there. I
> don't believe I have seen this one, actually, sorry. :-(
>
> Could you send it again, and I'll keep my eye out for it.
Done. Subject is "str_sep in fsc_field, fsc_color (fwd)", sent to
david@dfanning.com. Thanks,
Jeff Guerber
|
|
|
|
| Re: IDL graphics w/ no display [message #41357 is a reply to message #41355] |
Tue, 26 October 2004 14:57 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Jeff Guerber writes:
> Errr, I'm not sure if anyone's mentioned this yet (our news server
> seems to miss a lot of messages), but aren't pixmaps entirely creatures of
> the X server?
No, they are a standard part of IDL. I use them each
and every day. Couldn't live without them. :-)
> P.S. David, did you get the email I sent you a few weeks ago about
> fsc_field and fsc_color?
I've had an overzealous spam filter lately, and I find
quite a few messages I *should* have gotten in there. I
don't believe I have seen this one, actually, sorry. :-(
Could you send it again, and I'll keep my eye out for it.
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http:/www.dfanning.com/
Phone: 970-221-0438, IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: IDL graphics w/ no display [message #41361 is a reply to message #41357] |
Tue, 26 October 2004 13:57 |
Jeff Guerber
Messages: 41
Registered: July 2000
|
Member |
|
|
On Mon, 25 Oct 2004, David Fanning wrote:
> KM writes:
>
>> 1) Z buffer is limited to 256 colors. This is not a major
>> limitation, but it does exist
>
> You could use a pixmap rather than the Z-buffer.
> That would solve your color limitations, anyway.
Errr, I'm not sure if anyone's mentioned this yet (our news server
seems to miss a lot of messages), but aren't pixmaps entirely creatures of
the X server? In which case, they won't help KM's problem.
(Unfortunately I don't know any good solutions either. Best I can
think of is an alternate device (PS? Images (as opposed to vector
graphics) written in PS are HUGE; I think there must be a command for each
pixel. CGM? I have no experience with it, but it seems to be 8-bit too.))
Jeff Guerber
P.S. David, did you get the email I sent you a few weeks ago about
fsc_field and fsc_color?
|
|
|
|
| Re: IDL graphics w/ no display [message #41405 is a reply to message #41361] |
Mon, 25 October 2004 07:06 |
K. Bowman
Messages: 330
Registered: May 2000
|
Senior Member |
|
|
In article <MPG.1be681784d4b47299896ae@news.frii.com>,
David Fanning <david@dfanning.com> wrote:
>> 2) Z buffer text looks terrible.
>
> I'm not sure the pixmap will be much better. Perhaps
> if you do the blow up * 4 trick here with true-type fonts,
> you might have better luck.
>
> But, really, you need to write a nice note to RSI and
> tell them a lot of us, nay, MOST of us, still use direct
> graphics and we could use some nice looking fonts over
> here, too. :-)
You can use TrueType fonts in the Z-buffer (if you consider TrueType
fonts to be nice looking), but it doesn't solve the 8-bit color
limitation.
It seems to me that RSI needs to update the Z-buffer to handle 24-bit
color. Perhaps instead of an 8-bit graphics buffer and a 16-bit depth
buffer, they could simply make both buffers 24 bits deep. That might
also reduce some artifacts that show up in the z-buffering.
Ken Bowman
|
|
|
|
| Re: IDL graphics w/ no display [message #41411 is a reply to message #41405] |
Mon, 25 October 2004 03:20 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
KM writes:
> So I am producing images in IDL in Z buffer, writing PNGs to disk,
> and then telling the frontend (via a socket) that the image is
> ready. It reads it in and display it in a mac/win-like UI.
>
> But there are some limitations to this model.
>
> 1) Z buffer is limited to 256 colors. This is not a major
> limitation, but it does exist
You could use a pixmap rather than the Z-buffer.
That would solve your color limitations, anyway.
> 2) Z buffer text looks terrible.
I'm not sure the pixmap will be much better. Perhaps
if you do the blow up * 4 trick here with true-type fonts,
you might have better luck.
But, really, you need to write a nice note to RSI and
tell them a lot of us, nay, MOST of us, still use direct
graphics and we could use some nice looking fonts over
here, too. :-)
> I cannot use the "blow up * 4" trick for Z buffer text
> [http://dfanning.com/graphics_tips/zfonts.html] because it is too
> slow. I am using a very fast machine, but doing all the map stuff x4
> introduces a 1 second lag.
Could still be a problem. How are you resizing? Using
REBIN and not CONGRID, I hope. :-)
> I think I cannot use object graphics because I am working with map
> projections, map_continents, etc. and these don't work with object
> graphics, right?
There is some controversy about this, but in any case,
I think IDL 6.1 is required.
> I don't think callable IDL would help. That could replace the socket
> and file->disk part, but it wouldn't help with the display. Plus, it
> sounds complex.
I don't think it is anymore complex than what you are doing.
A lot of people serve IDL images up from web page interfaces
with reasonable speed and resolution. I think this should
be possible to do.
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http:/www.dfanning.com/
Phone: 970-221-0438, IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: IDL graphics w/ no display [message #41496 is a reply to message #41354] |
Wed, 27 October 2004 05:48 |
btt
Messages: 345
Registered: December 2000
|
Senior Member |
|
|
Ken Mankoff wrote:
>
>>> I think I cannot use object graphics because I am working with map
>>> projections, map_continents, etc. and these don't work with object
>>> graphics, right?
>>
>>
Hi,
(1) About OG without a display device.
I think you canuse the IDLgrBuffer as the destination drawing device. The
following works without X11 (MacOSX).
x = findgen(361)*!dtor
y = sin(x)
oplot = obj_new('IDLgrPlot', x,y)
omodel = obj_new('idlgrModel')
omodel->Add, oplot
oview = obj_new('idlgrview', viewplane_rect = [0,-1,!pi*2,2])
oview->Add, omodel
obuffer = obj_new('idlgrbuffer')
obuffer->draw, oview
oimage = obuffer->Read()
oimage->GetProperty, data = img
write_png, 'bufferimage.png', img
(2) I think that the iMap might be disguising how easy it can be to transform
map polygons into the OG realm. I recall a thread on this newsgroup where
somebody tessalated the Polygons for Alaska and then threw them into an object
graphics destination. (I think it was Karl - but I haven't found that thread.)
With the advent of the MAP_PROJ_***** routines, it sure seems like RSI has
freed mapping from the DG world. So, somewhere in iMap, the CIA map data (or
the Shape file data) that comes with IDL is unpacked and then formed into OG
polygons. That said, I have no experience with OG mapping although I started
down that path once in an idle moment.
Cheers,
Ben
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
