We can see examples of how to make a hexagon sticker.
The one with the cat on it is a good example of a hex sticker with an image.
i.e.
imgurl <- system.file("figures/cat.png", package="hexSticker")
sticker(imgurl, package="hexSticker", p_size=20, s_x=1, s_y=.75, s_width=.6,
filename="inst/figures/imgfile.png")
I have a high resolution png, which looks very nice on its own, but when I put it into the hexsticker, it looses resolution (badly).
I am not so experienced with hexsticker (nor with its graphics/ggplot internals), so am not sure how to force the resulting graphic to be of a higher resolution (or if it's possible to generate it in vector?)
Turns out it's easy, just use the dpi argument, like so
sticker(imgurl, package="hexSticker", p_size=20, s_x=1, s_y=.75, s_width=.6,
filename="inst/figures/imgfile.png",
dpi = 1000 # higher dpi means higher resolution
)
Related
I always resized images in CorelDraw from 1219,20 x 914,40mm to 78.36x51.00 to make photo boards. But now it turns out I have a lot of images in different folders and I needed to create an auto-lop to do this for me. If I were to do this in Corel like I used to do, it would take a lot of time.
I have used the the resize function from Magick package, but didn't have obtain sucess.
resize(Image, "78.36x51.00!")
Error in resize("78,36x51,00!") :
Not compatible with requested type: [type=character; target=integer].
So I also tried the image_scale function, in this case the dimensions changed, but the size and resolution of the image was much smaller than expected.
image_scale(Image, "78.36x51.00!")
Demonstration with the generated image after the resize (photo) and the expected size (white square)
Documentation indicates that magick's scaling functions are based on pixels. Scaling based on X and Y dimensions expressed as pixels is shown below.
I'm not sure if this directly addresses the issue because the units in the question seem to change and dots per inch (dpi) is not defined. 1219,20 x 914,40 is in mm, but the units for 78.36 x 51.00 are undefined. The first pair of numbers has an aspect ratio of 1.3 while the second is 1.5.
Scaling by X or Y in pixels will retain the original aspect ratio. Getting the right size involves knowing the desired dpi.
install.packages("magic")
library(magick)
Image <- image_read("https://i.stack.imgur.com/42fvN.png")
print(Image)
# Increase 300 in X dimension
Image_300x <- image_scale(Image, "300")
print(Image_300x)
# Increase 300 in y
Image_300y <- image_scale(Image, "x300")
print(Image_300y)
Some of the folks on my team, including myself, find it pretty disorienting that in a Bokeh scatter plot, say using the circle method, that for an initial autoscale fit of the data on the figure we can dial in a reasonable size for our data, using for example something like plot.circle( x , y , size=3 )
However when we interactively zoom into our data the glyph sizes as displayed are invariant to the zoom. Is there a way to have them scale proportionally to the zoom we've dialed into? Something akin to an vector graphics interaction (eg svg). If memory serves me right matlab figures and matplotlib figures should maintain zoom proportionality behavior. To demonstrate the behavior we're seeing consider the first image and the red box I approximately zoom into on the second image.
Just as a quick demo using Powerpoint to illustrate the sort of desired behavior...
For circles, set the radius kwarg instead of the size value. (There similar, glyph-specific values for the other glyph-types).
i.e.:
plot.circle(x=[1,2,3], y=[1,2,3], radius=0.5)
size is always rendered in screen coordinates (pixels), but radius and the related properties are computed in data coordinates and should change in magnitude with zooming.
Here's a good demo by Bryan Van de Ven showing the difference between pixel coordinates (size) and data coordinates (radius) given in this conference talk:
Intro to Data Visualization with Bokeh - Part 2 - Strata Hadoop San Jose 2016
... the point is all of these attributes can be vectorized. We could
for instance say size equals you know 2, 4, 6, 8, 10, and now the size
is modulated right. So we have one that has size 2 and one that has
size 4. Size is usually in pixels, radius is usually in data dimension
units. But all the other ones here as well all the colors, all the
visual attributes can be vectorized in this way. You can either give
them a single value as we've done for instance with the line fill
color, or you can give them a vector of values in which case all of
the things are different.
So next exercise here you go to this
notebook this is that second notebook "02 - plotting" it is to try to
create the same example but now set the radius instead of the size and
sort of see what's the difference if you set if you set radius instead
of size.
I am new to the field of medical imaging - and trying to solve this (potentially basic problem). For a machine learning purpose, I am trying to standardize and normalize a library of DICOM images, to ensure that all images have the same rotation and are at the same scale (e.g. in mm). I have been playing around with the Mango viewer, and understand that one can create transformation matrices that might be helpful in this regard. I have however the following basic questions:
I would have thought that a scaling of the image would have changed the pixel spacing in the image header. Does this tag not provide the distance between pixels, and should this not change as a result of scaling?
What is the easiest way to standardize a library of images (ideally in python)? Is it possible and should one extract a mean pixel spacing across all images, and then scaling all images to match that mean? or is there a smarter way to ensure consistency in scaling and rotation?
Many thanks in advance, W
Does this tag not provide the distance between pixels, and should this
not change as a result of scaling?
Think of the image voxels as fixed units of space, which are sampling your image. When you apply your transform, you are translating/rotating/scaling your image around within these fixed units of space. That is, the size and shape of the voxels doesn't change. They just sample different parts of your image.
You can resample your image by making your voxels bigger or smaller or changing their shape (pixel spacing), but this can be independent of the transform you are applying to the image.
What is the easiest way to standardize a library of images (ideally in
python)?
One option is FSL-FLIRT, although it only accepts data in NIFTI format, so you'd have to convert your DICOMs to NIFTI. There is also this Python interface to FSL.
Is it possible and should one extract a mean pixel spacing across all
images, and then scaling all images to match that mean? or is there a
smarter way to ensure consistency in scaling and rotation?
I think you'd just to have pick a reference image to register all your other images too. There's no right answer: picking the highest resolution image/voxel dimensions or an average or some resampling into some other set of dimensions all sound reasonable.
I am trying to use resolution passed into the StyleFunction to work out the size of my image Icons. Using tests, at a zoom where the scale line is 100m the resolution reported to the styling function is 2.3886.
I've take screenshots of the scale line and measured its length in pixels. A 100m scaleline is 68 pixels, or 1.4705 metres per pixel.
1.4705 !== 2.3886, so what is the resolution unit? The API documentation does not explain it and says it is just a number, but without an idea of units it is difficult to work out.
This is to accurately scale the icon to real world length BTW.
Using this jsfiddle.net/dz9gL0g0/ I find that 200m scaleline reports the 2.38, but 100m returns less (1.19). Is the resolution I'm getting from the previous zoomlevel? If I use the resolution passed in OR call the getResolution function directly, 100m scaleline always returns 2.83 for me, not the 1.19 I think it should, although 1.19 * 84 is mostly correct (scale line is bigger in example than my app, which gives me a 68 pixel scale line for 100m).
Moving the window alters the resolution - resize the jsfiddle and the resolution unit changes. My 100m scaleline still fits the geographical feature I use to test, but now reports 2.38.
The resolution is the size of 1 pixel in map units. Let's say your map projection is EPSG:3857 whose unit is meters. For example if the current resolution is 20000 m/px, this means that 1 px represents 20000m.
Maybe it also helps taking a look at this example.
After posting a bug request at github (https://github.com/openlayers/ol3/issues/3770) it was suggested that ol.proj.Projection.getPointResolution() be used to gather the correct resolution for the projection (which I assumed was being passed into the styling function at run-time - assumptions, eh?).
var view = map.getView();
var coords = view.getCenter();
var resolution = view.getResolution();
var projection = view.getProjection();
var resolutionAtCoords = projection.getPointResolution(resolution, coords);
This results in a much closer 1.50XXXX resolution being returned, which is dependant on the latitude. It remains to be seen if my tiled map source is scaled appropriately to the projection, but this means that my pixels per metre are now within a margin of error, correct.
AFAIK the resolution is in meters per pixel. Here is a feature from my application that is styled as ol.style.Circle with radius 3 / resolution:
Is your scale line working correctly? Using a non standard projection i had to use ol.proj.addProjection(...) and ol.proj.addCoordinateTransforms(...) in addition to just defining the projection via proj4.defs(...) to get it working.
I have a image with size of 5760 x 3840px with size of 1.14mb. But I would like to reduce its size to 200 kb by not changing the dimensions of the image. How Could I do this using photoshop? Please help me
This answer is based on a large format file size that has a resolution of 300 dpi. If the image is 5760 x 3840, your canvas size will be 19.2 x 12.8. in order to not "reduce" the dimension (printable area) you are going o have to reduce the image size [ALT + CTRL/CMD + I] and then reduce the resolution from there.
At 300 DPI:
At 72 DPI:
This reduction in resolution can decrease the file size dramatically, There is a chance of artifacts, but as you are starting at a high resolution the compression algorithms will smooth it out to almost non-existent.
NOW... If you are starting at 72dpi and you are looking for a good way to generate a lower file size for the web, your best bet may be to do a Safe for web option [ALT + CTRL/CMD + SHIFT + S] and generat a .jpg, .gif or a .png based on the final needs of the file. If it is an photograph with a lot of colors, I would go .jpg. If you have a lot of areas of solid color (logo perhaps) I would go with .png or .gif.
The Save for Web option allows you to see, side by side, the results of the export BEFORE going through the save process. it also allows you to alter the settings of the save process to dial in your results. best of all, it gives you a pretty good preview of the expected file size.
Either way this should help you save that larger file size for future use.