I was wondering if there is a way to save surface plots in IDL in a way that is convenient to reopen them. As far as I am aware there are only two ways of doing this:
The first way is to save your surface plot as an image e.g. png. The trouble with this is that the viewing angle is fixed and you can no longer drag with the mouse to rotate the surface plot.
The second way is to save the code which generates the plot. Trouble with this is the code often generates loads of plots which are usually just saved as images.
I would like something you can open easily and which opens the surface plot as though you had just run the code to generate it. So that you are free to rotate it by dragging the mouse.
Does this exist?
I only have IDL version 8.3.
If you 'Generate code/save data' (either via the toolbar at the bottom of the window or via the generateCode method with the SAVEDATA keyword), you get a .sav file that contains your plot. Either use the code generated to restore it, or use the generated code as an example to write your own.
Related
I have been using Grace (xmgrace) plotting for many years. I recently had an important idea for my work, and it involves rectangles on my plots. Grace supports rectangles (called "boxes"), but when I use a filled "box" it blocks my data curves. I want the curves to show over the filled rectangles. This is driving me nuts. Does anyone know how to put the filled rectangles in the background so they don't block data curves? Thanks.
Unfortunately there is no option in the xmgrace graphical interface that allows you to modify the z order of drawing objects such as boxes:
I also saved the graph as an .agr file and viewed it in a text editor. There doesn't seem to be any flag within the file format to modify z position, either.
Same story if you save a parameter file and check it in a text editor.
So it looks like it is really not possible in xmgrace.
One workaround would be to print to a postscript, EPS or SVG file and open it inside a vector graphics program such as Inkscape (results vary, you might need to experiment with filetypes to see which works best). Then you can easily alter the z order of objects.
I created an object that is viewed in the RStudio viewer, such as chart in plotly or highcharter or a map in leaflet. I would like to save that object as a png. There are a number of ways to do this. For example, there's this method that uses webshot. It's possible to use orca. There are several methods. The problem with all of these is that the output image is slightly different than the version seen in the viewer. This is a problem for me because I need both the interactive version of the chart as well as a static version and I don't want to have to create two versions and write all the code associated with producing both to make sure each one comes out just as I need.
However, RStudio has a built-in method that can be accessed by clicking "Export -> Save as Image" in the viewer pane. I would like to use this method because it preserves the layout exactly as seen in the viewer.
I tried using R's built-in plot saving method of png, plot and devoff, but that appears to only work for plot objects, not viewer objects.
There has to be a way to reproduce the physical steps of saving as an image in RStudio programmatically, right? Doing it manually would be really time-consuming.
Here's an sample chart in plotly that shows up in the viewer.
plot_ly(z = ~volcano, type = "surface")
I'm trying to build a .html file via RStudio in to have following function(simplified).
plot1:a simple time series plot of $y_t$, where user can manually pull/drag each dot to change it's values a each time point.
plot2:a time series dependent on $y_t$, such as $f(y_t)=2*y_t+1$, once the value in plot1 changed, the plot2 will also change accordingly.
I want the .html self contained, not cloud based. I'm thinking of plotly, shininy/knitr, but I'm not sure if I'm in the direction or how to connect the dots. Hope anyone can point me to the right direction.
A self-contained/client-side html report sounds well-suited for flexdashboard. It's based on R Markdown, and therefore can accommodate Shiny elements.
I don't know if you can modify values with a mouse, but you can certainly modify values with sliders and other inputs, as well as have a second plot react to a first plot.
You may see some more possibilities in the gallery.
I have a huge scatter plot matrix to generate and save into a zoom-able image. I takes a bunch of hours to draw and then I got some errors like:
"Server Error Unabe to establish connection with R session".
Any ideas? The problem is obviously memory, but there must be a way to get around this.
I've managed to save the file as a pdf format of 28.7 MB, it takes a lot of time to display and makes inkscape crash. I know that people who generate fractals are able to make images of infinite resolution without consuming a lot of memory since the image is generate as u zoom into it. Problem is fractals are self similar and scatterplots are not, so I'm not sure if there's a smart way to get around this issue.
A possible way to get around this "information overload" is to plot variables in pairs using qplot() and then save the file using ggsave(), for example in bmp on jpeg files.
I am making some graphs with R and I am coping them to Word. I was coping them as metafiles but Word doesn't seem to be able to cope with them. The other option in R to copy graphs is a bitmap, but when I use this the quality of the graphs in word is terrible.
I saw some answers about changing the resolution in this website but only if I saved the graphs which I would like to avoid. Is there a way of changing the resolution for copied graphs?
Thanks,
sbg
When the graphs are onscreen, they are drawn for a screen resolution (i.e. 72dpi). For print, you need to use at least 300dpi, or switch to a vector format. Word can import graphs in Windows Metafile (.wmf) format; but your other option is to save the plot using, e.g.,
png("my plot.png", res = 300)
plot(1:5)
dev.off()
This saves to disk, which you said you wanted to avoid, but you can always delete it again later (programatically even, with file.remove).
I'd also like to make the case that when you copy and paste, your work isn't as easily reproducible as when you use code. There is no trace of what you have done, and when your data changes, you need to go through the rigmarole of clicking again, rather than just executing your updated script.