I want to make publication-quality plots with Matplotlib. The biggest problem I am having right now is to tune the image and font sizes.
When I create a figure with several panels, I usually set a bigger figsize. For example, these three panels are created with a figsize=(12, 6 / 1.618) (pasted from Jupyter Lab, I always save to PDF files).
The lines can be perfectly seen, there is a lot of space, the figure seems nice. The problem is that in my publication this has to be a column-wise figure, so it has to be scaled down. A colum has a width of around ~3.5 inches. When the image is resized, it still looks good, but the axes labels become very tiny and unreadable. Of course, I can just simply start increasing the font sizes until I find a good size, but I would like to have a workflow that allows me to work with the lengths and sizes I have to use.
When I set the image size to figsize=(columnw, 0.5*columnw / 1.618) (so the aspect ratio is the same) as before, and set the font size around 10 (the font size of my publication) this is what I get:
So now the fonts are exactly the size I want them to be, the figure does not have to be reescaled, but the contents of the graph seem to be compressed into a very very tiny space. It just look... ugly.
Then, my question is: why using a big figsize with extremely large fontsizes gives a beautiful, readable figure when scaled, but with the a priori correct figsize without rescaling seems to be ugly? How could I work with real figsizes from the very beginning to obtain something nice?
I read some questions regarding image size with Matplotlib on this site, as well as a pair of blog posts, but I haven't found any information regarding this problem.
Thank you in advance.
Related
I have a very large set of data, they are hourly measurements and I have to plot 6 years of recordings, so we have about 8760 * 6 ~ 50'000 data.
x-axes is in date-time format.
Up to now I plotted a single year data, so about 10'000 data.
In a single "screen" I want to see about 30-50 hours width, so I have setted a width of 60'000:
set terminal png size 60000,2000
In that way, gnuplot creates a ridiculously wide PNG image. Anyway it is possible to visualize it with a browser, zoom it to 100% and scroll left and right to easily analyze my data.
Now, if I have to monitor 6 years instead of 1, I need an output image 6 times greater. So I tried:
set terminal png size 360000,2000
output image is now very wide and my browser cannot open it. I think due to the big size. However I can open it with an image viewer like "gwenview".
Anyway browser would be better, because I have to send this graph to other people.
Which alternative output "terminal" could I use in gnuplot to obtain a more manageable image?
EDIT:
I tried SVG terminal. It seems better to produce images of this size:
set terminal svg size 360000,800
set output 'plot.svg'
The image plot.svg is about 11 MB, very big, but browser can open it without any problem.
I have to visualize this large amount of data just for a "quality quick check" and scroll from the left to the right within the browser is easy enough. If I has to open many split image files it would be more complicated and slow.
Any other idea is welcome, thanks!
<------This is an image I made in Photoshop...
It's basically a 160 x 160 box of white with a texture applied.
Below is what it looks like with "background-repeat" in the CSS. I was hoping it'd balance out. Is there a certain percentage the textile has to be at, or size of the original box? For it to be a perfect repeatable texture?
Im trying to do this myself, since I cant find grid patterns that fit the style.
Question: Whats the trick on making textures in Photoshop, that appear as balanced whole backgrounds when repeated?
If you look at the below image where it's in effect, on the very basic start of what Im working on, you can notice it doesnt quite fit together.
Any and all help greatly appreciated. Thanks in advance.
If you want that background for a webpage is better the use of repeating-linear-gradient. It is very easy of implement, less assets to download and it is supported by major browsers.
Look in the top left corner of your image. You'll note that the dark line starts at roughly 4-5 pixels from the top. Then look at the top right corner, and you'll note that the top line starts at just perhaps 2px from the top.
When this image is repeated twice side by side, there will be a disconnect. Just crop the image and shave off the two or three pixels until your lines connect. Repeat by cropping the bottom of the image for vertical alignment.
If you want to do this experimentally, increase the size of your canvas, and copy the pattern into a new 160x160 layer. Place them side by side, and then move the layers one pixel at a time so that they overlap. Where the overlap aligns is where you should crop the image.
I'd like to improve the magnification of images (*.png) when they are exported in gnuplot. I had tried to increase the pixels of these images but when they are zoomed too many times, the quality is so bad. So could you please help me for this case.
Here are my commands for exporting the images *.png in gnuplot:
set term pngcairo transparent enhanced lw 2.2 \
font "Century,20" fontscale 1.2 size 1642,1140"
The problem you are facing is not related to gnuplot but to the bitmap nature of png images. Since these images are not vectorial, when you "zoom in" you simply increase the bit size, but not the resolution. The only way to solve this problem is to export to eps instead of png. There are a few terminals in gnuplot that you might be interested in. In my opinion the most powerful is the epslatex terminal: have a look at the documentation with help epslatex.
As mentioned by Miguel, likely the source of your problem is that by exporting a PNG you are exporting an array of pixels. When you zoom in you will start to see the individual pixels of your image.
Probably the best way to solve your problem is to export to some form of vector graphics. Take a look at EPS (side note: most journals will prefer if you submit a vector graphic rather then a PNG).
If you are certain you want to use PNG you should take a look at https://stackoverflow.com/a/9118990/2372604 which mentions changing your terminal to pngcairo to produce smoother results.
Another note to make, if your function is particularly noisy, you may need to increase the number of sample points, consider the command set samples 1000.
Besides the other answers, here are two other options:
increase terminal size (say 4000x3000), until you got something that looks good enough. PNG format is compressed so if most of the plot is white, it won"t add much bytes.
As already said, use a vector graphics format as terminal. The others suggest EPS, but is less common today than svg. The SVG terminal produces .svg files that can be easily post-processed with a tool such as Inkscape.
i am trying to read an image with ITK and display with VTK.
But there is a problem that has been haunting me for quite some time.
I read the images using the classes itkGDCMImageIO and itkImageSeriesReader.
After reading, i can do two different things:
1.
I can convert the ITK image to vtkImageData using itkImageToVTKImageFilter and the use vtkImageReslicer to get all three axes. Then, i use the classes vtkImageMapper, vtkActor2D, vtkRenderer and QVTKWidget to display the image.
In this case, when i display the images, there are several problems with colors. Some of them are shown very bright, others are so dark you can barely see them.
2.
The second scenario is the registration pipeline. Here, i read the image as before, then use the classes shown in the ITK Software Guide chapter about registration. Then i resample the image and use the itkImageSeriesWriter.
And that's when the problem appears. After writing the image to a file, i compare this new image with the image i used as input in the XMedcon software. If the image i wrote ahs been shown too bright in my software, there no changes when i compare both of them in XMedcon. Otherwise, if the image was too dark in my software, it appears all messed up in XMedcon.
I noticed, when comparing both images (the original and the new one) that, in both cases, there are changes in modality, pixel dimensions and glmax.
I suppose the problem is with the glmax, as the major changes occur with the darker images.
I really don't know what to do. Does this have something to do with color level/window? The most strange thing is that all the images are very similar, with identical tags and only some of them display errors when shown/written.
I'm not familiar with the particulars of VTK/ITK specifically, but it sounds to me like the problem is more general than that. Medical images have a high dynamic range and often the images will appear very dark or very bright if the window isn't set to some appropriate range. The DICOM tags Window Center (0028, 1050) and Window Width (0028, 1051) will include some default window settings that were selected by the modality. Usually these values are reasonable, but not always. See part 3 of the DICOM standard (11_03pu.pdf is the filename) section C.11.2.1.2 for details on how raw image pixels are scaled for display. The general idea is that you'll need to apply a linear scaling to the images to get appropriate pixel values for display.
What pixel types do you use? In most cases, it's simpler to use a floating point type while using ITK, but raw medical images are often in short, so that could be your problem.
You should also write the image to the disk after each step (in MHD format, for example), and inspect it with a viewer that's known to work properly, such as vv (http://www.creatis.insa-lyon.fr/rio/vv). You could also post them here as well as your code for further review.
Good luck!
For what you describe as your first issue:
I can convert the ITK image to vtkImageData using itkImageToVTKImageFilter and the use vtkImageReslicer to get all three axes. Then, i use the classes vtkImageMapper, vtkActor2D, vtkRenderer and QVTKWidget to display the image.
In this case, when i display the images, there are several problems with colors. Some of them are shown very bright, others are so dark you can barely see them.
I suggest the following: Check your window/level in VTK, they probably aren't adequate to your images. If they are abdominal tomographies window = 350 level 50 should be a nice color level.
I am making game for mobile phone and i have little knowledge of creating graphics for games. I am making graphics using CorelDraw & Photoshop.
I made flash.png using above 2 software's & could squeeze the size to 47Kb only.....
But I came across one game which has file size just 2kb for its background (bg0 & bg1.png)
I want to know how do I make such beautiful graphics without increasing the size of my file...
I assume the gamer must have hand sketched, scanned & used one of the above software's to fill the colors.....but i am not sure about it...
plz help
There are several ways to reduce the size of a PNG:
Reduce the colour depth. Don't use RGB true/24 bit colour, use an indexed colour image. You need to add a palette to the image, but each pixel is one byte, not two.
Once you have an indexed colour image, reduce the number of colours in the palette. There is a limit to how many colours you can reduce it by - the fewer colours, the lower the image quality.
Remove unnecessary PNG chunks. Art packages may add additional data to the PNG that isn't image data (creation date, author info, resolution, comments, etc.)
Check http://pmt.sourceforge.net/pngcrush/ to get rid of unneeded PNG chunks and compress the IDAT chunk even further. This might help a lot or not at all depending on the PNG that came out of the art packages. If it doesn't help, consider index PNGs. And if you go for paletized PNGs be sure to check out http://en.wikipedia.org/wiki/Color_cycling for cool effects you might be able to use.
Use a paletted png with few colors and then pass the png through a png optimizer like the free exe PngOptimizer
If your png still is too big reduce the number of colors used and reoptimize. Rince and repeat ^^.
I have used this technique on quite a lot of mobile games where size was of the essence.