Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
Hello! We have a problem with the postscript output...... First we produce a plot on the screen, e.g. a xy-plot. Than, with a button, we do this: 'GTest' : $ BEGIN TVLCT, r, g, b, /GET Pict = TVRD() WRITE_GIF, 'plottest.gif', Pict, r, g, b print, 'Bild wurde als plottest.gif abgespeichert.' SET_PLOT, 'ps' DEVICE, /COLOR TV, Pict DEVICE, /CLOSE SET_PLOT, 'x' print, 'PS auch' the gif-file is 'very' nice, but no good resolution for printing. therefor we store an additional ps-file. it has a nice resolution i think, but it shows not the xy-plot, only a orange rectangular instead..... :((((( can anyone help? regards, astrid kuhr
Joel D. Offenberg (offenbrg@fondue.gsfc.nasa.gov) offers some good advice when he writes: > davidf@dfanning.com (David Fanning) writes: > >>> - something goes wrong with the colormap. >>> on the screen I have colors from blue to red, on the ps only from >>> blue to yellow...?? >>> whats going wrong..? > >> Uh, probably you didn't do *exactly* what I suggested in my >> earlier message and reload those color vectors after you got >> into the PostScript device. :-) > > Actually, I've seen this before---when you draw things in a TV window and > use the color tables, the output is truncated to the number of colors > available (which is typically less than 256, since some will be taken up > by the system, unless you have a 24-bit graphics card). However, that isn't > the case when you are using PostScript, so things may end up non-linear. Exactly. This is certainly what was happening to Astrid Kuhr. That is why I advised him to get the color table vectors *before* he went into the PostScript device: TVLCT, r, g, b, /Get And to restore them *exactly* the way he found them once he got there: Set_Plot, "PS" TVLCT, r, g, b Combined with his TVRD(), this would result in PostScript colors EXACTLY like he saw on the display. > The test is to see if "Print, !d.N_colors" before you start your tvrd gives > you 256. If it doesn't, you have several options to get it right. The > easiest way is to pad out the R,G,B vectors to have 256 elements each, > then "tv, IMAGE < n_colors" > where n_colors = !d.N_Colors from before you started with the TVRD. I'm not sure this is the best way if you want to view your data correctly. I think the best way is usually to scale your data to the number of colors you have on the display and make sure you use *exactly* the same color table vectors (i.e., with same number of elements) both on the display and in your PostScript file. Cheers, David P.S. In any case, Astrid told me he got better results when he followed my directions more closely. :-) ----------------------------------------------------------- David Fanning, Ph.D. Fanning Software Consulting E-Mail: davidf@dfanning.com Phone: 970-221-0438 Coyote's Guide to IDL Programming: http://www.dfanning.com/
davidf@dfanning.com (David Fanning) writes: > A.Kuhr (rew032@isr141.isr.kfa-juelich.de) writes: >> Thank you very much, now not only an orange rectangle... :)))) >> >> But 2 other problems occured.... :((( >> >> - the resolution of the printed postscript is very :((( to, like gif..... >> how get a 'nicer' picture...? > Yes, it is a *screen dump* you are doing. Resolution is > VERY low compared to true PostScript output. To get a nicer > PostScript picture re-issue the exact same commands that got > you that nice picture on your display. It would help if those > commands were in a separate procedure. :-) > >> - something goes wrong with the colormap. >> on the screen I have colors from blue to red, on the ps only from >> blue to yellow...?? >> whats going wrong..? > Uh, probably you didn't do *exactly* what I suggested in my > earlier message and reload those color vectors after you got > into the PostScript device. :-) Actually, I've seen this before---when you draw things in a TV window and use the color tables, the output is truncated to the number of colors available (which is typically less than 256, since some will be taken up by the system, unless you have a 24-bit graphics card). However, that isn't the case when you are using PostScript, so things may end up non-linear. The test is to see if "Print, !d.N_colors" before you start your tvrd gives you 256. If it doesn't, you have several options to get it right. The easiest way is to pad out the R,G,B vectors to have 256 elements each, then "tv, IMAGE < n_colors" where n_colors = !d.N_Colors from before you started with the TVRD. Joel -- "...And I am unanimous in this" - Mrs. Slocumbe ------------------------------------------------------------ --------------- | Joel D Offenberg | Joel.D.Offenbrg.1@gsfc.nasa.gov | | Hughes STX, NASA/GSFC/LASP | UIT, COBE, NGST programmer & sysadmin |
Hi, In article <MPG.eda68b7328deb7f9896aa@news.frii.com>, davidf@dfanning.com (David Fanning) wrote: > > Exactly. This is certainly what was happening to Astrid Kuhr. That > is why I advised him to get the color table vectors *before* > he went into the PostScript device: > > TVLCT, r, g, b, /Get > > And to restore them *exactly* the way he found them once > he got there: > > Set_Plot, "PS" > TVLCT, r, g, b > just one question on this: Does these object orienented graphics stuff in IDL 5.0 change anything to this old printing device problem ? Servus, Helge -- Adjust e-mail address for reply
Astrid Kuhr (rew032@isr141.isr.kfa-juelich.de) writes: > What I heard, not still now tried by myself, if you use > the object orientated things, it is easier. Not exactly true. If you use object-oriented graphics routines you can use the PRINTER device directly. But you can also take advantage of the PRINTER device with the normal, direct graphics routines. > but next problem: no vector postscript is generated. > instead of this pixel....!! No, the PRINTER device will draw vectors. It is just that object graphics are in a true 3D environment, so that even something simple like a line in a plane has a 3D component that must be passed around with it. This, necessarily, slows things down a bit and makes the file larger. > and than you get some 20mb or more postscript files.... > good luck for you spooling filesystem and yor printer.... I don't think direct graphics commands sent to the PRINTER device will generate anything like this. I don't usually find myself complaining about the speed of PRINTER output, only about the implementation. I wish the PRINTER device was more like the PS device for PostScript output. In particular, I have found it impossible to display any graphics output that has an image on it in addition to other graphics commands. This is due to a lack of control with respect to how graphics are positioned and sized in the PRINTER device. Cheers, David ----------------------------------------------------------- David Fanning, Ph.D. Fanning Software Consulting E-Mail: davidf@dfanning.com Phone: 970-221-0438 Coyote's Guide to IDL Programming: http://www.dfanning.com/
Hello! What I heard, not still now tried by myself, if you use the object orientated things, it is easier. but next problem: no vector postscript is generated. instead of this pixel....!! and than you get some 20mb or more postscript files.... good luck for you spooling filesystem and yor printer.... regards, astrid
A.Kuhr wrote: > Hello! > > What I heard, not still now tried by myself, if you use > the object orientated things, it is easier. > but next problem: no vector postscript is generated. > instead of this pixel....!! > and than you get some 20mb or more postscript files.... > good luck for you spooling filesystem and yor printer.... > > regards, astrid As far as I can remember: this was also one of the complaints on the oo graphics at the ADASS conference this September. David (Stern) told us (the users) that this "feature" will probably changed in the future - we'll see -- Michael Werger ESA ESTEC & Praesepe B.V. Astrophysics Division mwerger@estec.esa.nl Postbus 299 http://astro.estec.esa.nl 2200 AG Noordwijk +31 71 565 3783 (Voice) The Netherlands +31 71 565 4690 (FAX)