I wanted to get a scatter plot but the constraint is to plot these points over an image with same dimension as the range of points. Is is possible? If yes which library is good to start with? I tried using gnuplot but it is causing problems. For now I have a code which was stated here but didn't work. I tried using a bitmap image with the points to be plotted in data1.dat file and used the gnuplot script which is stated in the link
set terminal pngcairo transparent
set output 'Figure1.bmp'
plot "Co_ordinates0.dat"
set output
Related
Using gnuplot v5 patch 6 on windows 10 (wxt terminal)
I have a data file of 2D vectors arranged in six columns (x, y, v_x, v_y, v_mag, rho) that I'm trying to plot as a heatmap of v_mag against x and y. The plot generates fine, but it's always coming up with
"No dimension information for 80000 pixels total. Try 200 x 400"
But I have no idea where to specify this in the terminal.
I realise that I can use pm3d map for this, but this doesn't work without setting dgrid3d and that causes problems with plotting dots on top of the heatmap which I'm also doing. I also don't want to generate a matrix file just for the image plot since I need the vector data for analysis later.
In terms of an example, the plot will generate if I literally just write:
plot 'vectors.dat' using 1:2:5 with image, 'dots.dat' with dots
EDIT: added 'set pm3d' to example code
EDIT: example is now minimal code to produce desired plot
EDIT: example data file can be found here
Any help would be appreciated.
After updating my gnuplot to v5.2, this problem has disappeared.
I am displaying data using function imagesc(). If I set fltk as graphics_toolkit image is displayed correctly.
Can't post images directly(low reputation) http://i.stack.imgur.com/ARiwF.png
If I use gnuplot as plotting program image is rendered upside down.
fltk is unusable for me because its window isn't responding while function in octave is running. I also tried plot sine and it was correct plotted through fltk and gnuplot too.
There are at least two workarounds:
Use axis("xy") or axis("ij") to control the orientation of the y-axis, as decribed in the axis documentation
Use set(gca, "ydir", "normal") or set(gca, "ydir", "reverse"), as decribed in the axes properties doc
Using gnuplot 4.6 patchlevel 1, with the following commands,
set grid linewidth 1 linecolor rgb"#888888"
set datafile separator ","
plot for [n=2:100] "data.csv" using 1:(column(n)) with lines linewidth 2
and the following example data in the file "data.csv",
time,S1,S2
0,0.00015,0
0.1,0.0001357256127053939,1.427438729460607e-005
0.2,0.0001228096129616973,2.719038703830272e-005
0.3,0.0001111227331022577,3.887726689774233e-005
0.4,0.0001005480069053459,4.945199309465411e-005
0.5,9.097959895689501e-005,5.902040104310499e-005
0.6,8.232174541410396e-005,6.767825458589604e-005
0.7,7.448779556871142e-005,7.551220443128858e-005
0.8,6.739934461758323e-005,8.260065538241677e-005
0.9,6.098544896108986e-005,8.901455103891014e-005
1,5.518191617571635e-005,9.481808382428365e-005
the resulting plot looks this:
Question: why does the grid only extend partway from the bottom, and not cover the whole plot? I tried a considerable amount of experimentation with the set xtics and ytics commands, arguments to grid, and more, and have not been able to get the grid to cover the whole plot. What am I missing?
Great question! In fact, the answer is that the grid does cover the whole plot. The problem is that the key is taking over. Try it again, but with an unset key in there before your plot command.
What's happening is that gnuplot is reserving space in the key for all of the columns which have no data. Nothing gets put in the space that was reserved since no reasonable data was found. Ultimately, this pushes the 2 lines that were visible out of the viewable canvas area as well.
I've reproduced this using the x11, png, postscript and pngcairo terminals.
Note that this behavior seems to be version dependent:
With gnuplot 4.4.2 (OS-X, png terminal)
With gnuplot 4.6.0 (OS-X, png terminal)
For those using gnuplot 4.4.4, perhaps there was a bug fix which made it work for gnuplot 4.4.4 and then a regression. It seems to persist into gnuplot 4.7.0 as well. I might file a bug report.
I often plot graphs in gnuplot prompt shell, like this:
gunuplot> plot sin(x) with linespoints pointtype 3
and the figure showed up is great.
Today, I save the graph in a .png file, like this:
gnuplot> set term png
gnuplot> set output "output.png"
gunuplot> plot sin(x) with linespoints pointtype 3
Then, I open output.png with eog in Ubuntu, like this:
$ eog output.png
I found that, the output.png displayed in eog is not as good as the figure plotted in prompt shell.
Why is that? Do I need to adjust some settings before save the output.png?
PS
I found that a way around it, first,
set term postscript
set output "output.ps"
then in linux shell,
$ convert output.ps output.jpg
This way some sort of solve the my problem.
The source of your problems with the PNG quality is most likely the missing antialiasing in the png terminal of Gnuplot. Since you give no screenshots, I'm not sure what you mean when talking about bad linewidth, but here's how it looks for me (on MacOS). This screenshot shows the output of gnuplot's native aquaterm output:
If we create a png using set term png, the lines become "jumpy" and pixellated:
However, there is a version of the png terminal that uses the Cairo libs for rendering, and that makes the output far more smooth and nicer. set term pngcairo gives this result:
You can use set terminal to check whether this terminal version is available for you. If it is, this should save you conversion work and also give better image quality than a JPG (which is not an ideal format for line art).
The default size of the PNG image generated gnuplot with the PNG terminal is 640x480 pixels. This resolution in certain cases may result in "pixelated" graphs which are not as nice as those produced on screen with the default (wxt) terminal.
You can change the resolution of the output image using the size option:
set terminal png size <x,y>
where x and y are the desired numbers of pixels along the horizontal and vertical axis, respectively.
For example:
set terminal png size 1024,768
Please note that, images with larger resolution will result in proportionally larger files on disk. Alternatively you can try to use non-raster terminals like "post eps" or "pdf" if available on your machine, which may give you high quality scalable and (relatively) portable images without a large disk footprint.
Alternatively, if you want professional (publication-ready) quality images with gnuplot, you should have a look at the epslatex terminal. I have used it extensively for my thesis and my papers with very nice results, virtually no pixelation problems, portability when converting images to pdf, and almost all the capabilities of Latex.
I am generating mapped 3D plots using the following config file (XRANGE and YRANGE are set later)
#!/usr/bin/gnuplot
reset
set term postscript eps enhanced
set size square
set xlabel "X position"
set ylabel "Y position"
#Have a gradient of colors from blue (low) to red (high)
set pm3d map
set palette rgbformulae 22,13,-31
set xrange [0 : XRANGE]
set yrange [0 : YRANGE]
set style line 1 lw 1
unset key
set dgrid3d 45,45
set hidden3d
splot "data.data" u 1:2:3
The resulting image looks something like this
Note: I have converted to jpg so the quality is lower, and I have placed a border around the image.
A great deal of space is wasted above and below. This is not a problem until I embed the image into a LaTex document, at which point it will look like so (again, pdf document converted to jpg image)
The image on the right is also created with GnuPlot, but it is slightly larger (as is evident by looking at the border I have drawn around the top two images). The reason for this is because GnuPlot pads the 3D plot with top and bottom white space. How can I remove this without having to manually edit all 50+ plots I have?
There are two solutions to this, one is unreliable, the other is a hack.
Using GnuPlot, the margin settings can be used to specify distances from the appropriate margins. For example, setting lmargin 0 and bmargin 0 essentially pushes the axes off the page. Similar values can be assigned to the tmargin and rmargin to stretch the graph. Although this worked for 2D graphs, it did not work for 3D graphs (I suspect this has to do with the fact that I set the graph to be a square).
When graphs are set to be of square size, Gnuplot still calculates for the entire screen. The eps file can be manipulated directly to change this by looking for a line like so %%BoundingBox: 50 50 410 302 and changing 410 to something smaller. Alternatively, and this is what I did, you can run eps2eps in.eps out.eps and it will crop it for you. Just make sure in.eps is not the same file as out.eps or it won't work.
I also crop the Bounding Box afterwards, since I hate playing around with margins in gnuplot. I realized that somehow, eps2eps indeed does adjust the bounding box, but it also transforms text (labels etc) into pixel-graphic?!
I usually use "epstool" which conserves text as text when croping the bb, the command I use is:
epstool --copy --bbox in.eps out.eps
Use the <scale> argument in set view, this will magnify the plot without changing text size or title position.
In your case, because you use the map view, you need:
set view 180,0,1.5
where 180,0 is equivalent to map view and 1.5 is the scaling factor.