| Re: Postscript dump to a Laserwriter [message #634 is a reply to message #632] |
Fri, 18 December 1992 07:00   |
thompson
Messages: 584
Registered: August 1991
|
Senior Member |
|
|
In article <1992Dec17.210303.18636@ennews.eas.asu.edu>, scowen@wfpc3.la.asu.edu (Paul A. Scowen) writes...
> Hi,
>
> OK this seems the simplest thing in the universe right? Wrong.
>
> Let me explain what I've been going through the last few days, and maybe
> someone out there with a little more experience than I can help me.
>
> Given that I currently have an image displayed into a window with a given
> color table loaded (other than b/w linear) and that I have modified the
> stretch to reveal more detail, this is what I'd like to do. I would like to
> dump the window contents to a Postscript environment (set_plot, 'ps') with
> the stretch being preserved.
(stuff deleted)
> Now, after all these rantings there is a way to make this work, but it causes
> something else to stop working. The above methodology allows you to annotate
> the display, like add contours to an image, or somesuch. Then you ca just
> dump the window contents using tvrd() and you can print the output. This
> however breaks the color common block, with the r_curr, etc. being reset so
> that a tvlct reloads the original colormap and not the strectched one.
>
> The briefly mentioned solution to the Laserwriter PS problem is to actually
> use tvscl and not use tvrd at all. This way, when you tvscl inside PS the
> same colormap is used, and you can switch to bits_per_pixel=4 and get a
> decent b/w rendition of your color stretch. BUT, again, if you have used
> contour in a noerase mode, then the colormap is erased and a tvscl renders
> the default map again.
I don't understand this part. I have trouble seeing how the internal commands
like CONTOUR, TVRD, TVLCT, etc. can affect the values stored in the COLORS
common block.
> So, after this lengthy explanation I have several request/questions:
>
> 1. Given a color strectched image with contours overlaid, how can I produce
> *either* color or laserwriter PS from a tvrd() call (ignoring the screen-
> dump bugaboo)?
You can do a dump of a window with exactly the same colors that appear on the
screen by using TVLCT,/GET to get the current (stretched) color table. For
example,
IMAGE = TVRD(0,0,!D.X_SIZE,!D.Y_SIZE)
TVLCT,RED,GREEN,BLUE,/GET
SET_PLOT,'PS'
TV, IMAGE !Note: Not TVSCL
TVLCT,RED,GREEN,BLUE
SET_PLOT,'X'
> 2. Alternatively, using the tvscl method, is there anyway to stop the
> colormap in colors (common) from being erased by the contour call, so we
> could reload the strectched version of the colortable before tvscl is
> called. And then (long winded I know) redo the contours inside the PS
> setup?
This shouldn't happen. I suspect that your using some software to do the
contour plot that also makes calls to some routines that manipulate the COLORS
common block (e.g. LOADCT, STRETCH, etc.). Either that, or the values in the
common block no longer represent what you're seeing on the screen, but you're
assuming that it does.
> 3. Does RSI plan to fix this rather annoying feature in tvrd() since it
> doesn't appear to be a terribly uncommon feature for such a function, to
> grab the data that is off screen instead of dumping the actual screen
> buffer itself?
Another related problem is that TVRD can be messed up if the window being read
is partially obscured by another window. It would be nice if that could be
changed too.
Hope this helps,
Bill Thompson
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
