| 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.
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
