| Re: Postscript dump to a Laserwriter [message #631] |
Sun, 20 December 1992 13:55 |
scowen
Messages: 11
Registered: December 1992
|
Junior Member |
|
|
In article <18DEC199217302565@stars.gsfc.nasa.gov>, thompson@stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) writes:
|> >|> 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'
|> >
|> >Unfortunately, Bill, this does *not* work. I've just tried it several times,
|> >with several different stretches, and the resulting PS file looks execatly
|> >the same for all versions. It uses the default setting of b/w linear in the
|> >4bit mode, which is of no use to me. This is my whole point.
|>
|> This may be because I left out the following command:
|>
|> DEVICE,/COLOR,BITS_PER_PIXEL=8
|>
|> which is crucial. Sorry about that. (I also forgot the DEVICE,/CLOSE at the
|> end.)
yes, well, this was the original problem, too. Laserwriters cannot read PS
that has the COLORTAB entry added by /color, I was trying to do this using
8bit with color turned off. Anyway, it's academic now, since if you use the
conversion I put in my previous post you can get a decent b/w version of a
rolled colortable from r,g,b and that does what I need.
Since the problems I was having have been essentially solved, I'm dropping
this line of discussion, since there will probably be other more complex
issues that i will run into over the next 2-3 weeks. Thanks again to all
who contributed, particularly Bill.
--
------------------------------------------------------------ -------------------
Paul A. Scowen INTERNET: scowen@wfpc3.la.asu.edu
Department of Physics & Astronomy uk1@spacsun.rice.edu
Arizona State University Tel: (602) 965-0938
Tempe, AZ 85287-1504 FAX: (602) 965-7954
------------------------------------------------------------ -------------------
|
|
|
|
| Re: Postscript dump to a Laserwriter [message #632 is a reply to message #631] |
Fri, 18 December 1992 09:46  |
scowen
Messages: 11
Registered: December 1992
|
Junior Member |
|
|
In article <18DEC199211000500@stars.gsfc.nasa.gov>, thompson@stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) writes:
|> 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.
Well, so do I - but try it. It does exactly that - completely forgetting the
stretch you've set.
|> >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'
Unfortunately, Bill, this does *not* work. I've just tried it several times,
with several different stretches, and the resulting PS file looks execatly
the same for all versions. It uses the default setting of b/w linear in the
4bit mode, which is of no use to me. This is my whole point.
|> >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.
Well, I'm using CONTOUR in NOERASE mode to produce the overlay contours. If
what you're saying is true then I guess I'll have to lobotomise the .pro file
for my own purposes.
|> >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.
Well, yes, that's the problem I'm having with a display widget that has
scollbars and so has part of the image obscured by the widget frame.
Thanks for your response Bill.
--
------------------------------------------------------------ -------------------
Paul A. Scowen INTERNET: scowen@wfpc3.la.asu.edu
Department of Physics & Astronomy uk1@spacsun.rice.edu
Arizona State University Tel: (602) 965-0938
Tempe, AZ 85287-1504 FAX: (602) 965-7954
------------------------------------------------------------ -------------------
|
|
|
|
| Re: Postscript dump to a Laserwriter [message #633 is a reply to message #632] |
Fri, 18 December 1992 13:30 |
thompson
Messages: 584
Registered: August 1991
|
Senior Member |
|
|
In article <1992Dec18.174615.4416@ennews.eas.asu.edu>, scowen@wfpc3.la.asu.edu (Paul A. Scowen) writes...
> In article <18DEC199211000500@stars.gsfc.nasa.gov>, thompson@stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) writes:
>
> |> 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.
>
> Well, so do I - but try it. It does exactly that - completely forgetting the
> stretch you've set.
I guess I still don't know what you mean exactly. Does it change the arrays
stored in the common block, or does it just change the color tables on the
display? Could you give me a concrete example?
>
> |> >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'
>
> Unfortunately, Bill, this does *not* work. I've just tried it several times,
> with several different stretches, and the resulting PS file looks execatly
> the same for all versions. It uses the default setting of b/w linear in the
> 4bit mode, which is of no use to me. This is my whole point.
This may be because I left out the following command:
DEVICE,/COLOR,BITS_PER_PIXEL=8
which is crucial. Sorry about that. (I also forgot the DEVICE,/CLOSE at the
end.)
(remainder of previous message deleted).
Bill Thompson
|
|
|
|
| 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
|
|
|
|
| Re: Postscript dump to a Laserwriter [message #635 is a reply to message #634] |
Fri, 18 December 1992 12:16 |
scowen
Messages: 11
Registered: December 1992
|
Junior Member |
|
|
Hello all,
well this is a summary of the solution provided by Alan Youngblood at RSI to
the problems I pointed out in my original post. Many thanks go to the
numerous individuals who replied.
1. The problem of tvrd() not grabbing the entire window when the window was
scrollbarred, or off-screen. This can be solved by setting the keyword
RETAIN to 2 in the widget_draw call. It appears to work quite nicely.
2. Producing b/w output in the PS environment from either a rolled color or
b/w window image. Use bits_per_pixel=8, and use the following translation
from tvlct:
bwtable=bytscl(.3*r + .59*g + .11*b)
and then:
tv, bwtable(image)
this does produce a convincing b/w output that a Laserwriter can handle, from
either rolled b/w or color.
3. The use of both of these solutions appears to circumvent the CONTOUR
color problem before, since we don't need to use tvscl anymore.
This does appear to solve all the issues that were plaguing me. Thanks to
all who contributed. I have been told by Youngblood (for all RSI-IDL users
out there) that RSI does NOT receive a newsfeed, and so all questions should
be emailed directly to them as well as being posted here. Summaries of
solutions, such as this, would appear logical.
--
------------------------------------------------------------ -------------------
Paul A. Scowen INTERNET: scowen@wfpc3.la.asu.edu
Department of Physics & Astronomy uk1@spacsun.rice.edu
Arizona State University Tel: (602) 965-0938
Tempe, AZ 85287-1504 FAX: (602) 965-7954
------------------------------------------------------------ -------------------
|
|
|
|
| Re: Postscript dump to a Laserwriter [message #636 is a reply to message #634] |
Fri, 18 December 1992 10:00 |
thompson
Messages: 584
Registered: August 1991
|
Senior Member |
|
|
In article <18DEC199211000500@stars.gsfc.nasa.gov>, I accidently left an
important command out of an example. It should have read
IMAGE = TVRD(0,0,!D.X_SIZE,!D.Y_SIZE)
TVLCT,RED,GREEN,BLUE,/GET
SET_PLOT,'PS'
DEVICE, /COLOR, BITS_PER_PIXEL=8 ;<--- Line left out.
TV, IMAGE ;Note: Not TVSCL
TVLCT,RED,GREEN,BLUE
SET_PLOT,'X'
Bill Thompson
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
