The core of my problem:
I'm attempting to convert npc units to native units using the grid package's convertUnit, convertX and convertY functions. (npc=normalized parent coordinates, possibly known as ndc units, normalized device coordinates to some in base graphics R. I'm trying to get to native units, those in which the plot is graphed, so in terms of the xlim and ylim units.) However when I attempt to do this as such:
> xyplot(1:10~1:10)
> convertX(unit(.9, "npc"), "native")
[1] 484.2native
when I'm expecting a number close to 9 as the native x coordinate. It appears convertX is returning units in device coordinates/pixels instead.
Reasoning:
I'm trying to use a base locator type device to return npc coordinates, and from those npc coordinates convert to the native coordinates in which the graph was plotted. While I can use base graphics' locator or grid.locator, I'm trying to extend the functionality of this new, non blocking locator to grid/lattice graphics by converting from npc back to native. convertUnit and convertY don't work either.
Question
Is it possible for grid to convert from npc back to the active plotting window's native coordinates? Why is convertX returning pixels rather than native coordinates?
Thanks much in advance.
Edited for tags and sloppy mistake leaving out xyplot before. My apologies, but it holds with xyplot.
‘"native"’ Locations and dimensions are relative to the viewport's ‘xscale’ and ‘yscale’.
The conversions occur within the current viewport.
> plot(1:10)
> convertX(unit(.9,"npc"),"native")
[1] 453.6native
> pushViewport(viewport())
> convertX(unit(.9,"npc"),"native")
[1] 0.9native
> convertX(unit(.1,"npc"),"picas")
[1] 4.21575picas #making window smaller
> convertX(unit(.1,"npc"),"picas")
[1] 1.9798375984252picas #making window larger
> convertX(unit(.1,"npc"),"picas")
[1] 5.25783218503937picas
So you need a viewport first to get sensible values out.
Apparently, after the viewport is pushed, it has forgotten about the set coordinate of the underlying plot and the new coordinates seem to be equivalent to the npc coordinates.
Until you plot into the new viewport, after which you are back to square one:
xyplot(1:10 ~ 10:1)
> convertX(unit(.9, "npc"), "native")
[1] 605.7native
> pushViewport(viewport())
> convertX(unit(.9, "npc"), "native")
[1] 0.9native
> xyplot(1:10 ~ 10:1)
> convertX(unit(.9, "npc"), "native")
[1] 605.7native
Is it possible to obtain coordinates that correspond to those in which x and y are actually plotted?
Related
I have a SpatVect consisting of points and I want to rasterize them into a SpatRaster with a given resolution. Is there a way of specifying a function taking in the points that are within a buffer of each raster cell?
Many thanks
Joao
-- Update --
Maybe a figure would help understand what I'm after with my question. The red square will have to be run over the center of each pixel to calculate some statistics using the ovelaying points. Apologies for the clumsy question, but I hope the figure is clear enough...
terra version 1.6-28 supports rasterization of points with a rectangular moving window.
Example data
library(terra)
#terra 1.6.33
r <- rast(ncol=100, nrow=100, crs="local", xmin=0, xmax=50, ymin=0, ymax=50)
set.seed(100)
x <- runif(50, 5, 45)
y <- runif(50, 5, 45)
z <- sample(50)
v <- vect(data.frame(x,y,z), geom=c("x", "y"))
Solution
r1 <- rasterizeWin(v, r, field="z", fun="count", pars=10, win="rectangle")
plot(r1)
points(x, y)
You can change fun to another function that works for you, and you can change the size of the moving window with pars.
Instead of a rectangle, you can also use a circle or an ellipse. The border of a circular window is equidistant from the center of the cells. In contrast, the border of rectangles are at a constant distance from the border of the grid cells in most directions (not at the corners). Here is an example.
r2 <- rasterizeWin(v, r, field="z", fun="count", pars=5.25, win="circle")
plot(r2)
You can also use buffers around each cell to get a window that is truly equidistant from each cell border.
r3 <- rasterizeWin(v, r, field="z", fun=length, pars=5, win="buf")
plot(r3)
In this case, because the buffer size is large relative to the cell size, the result is very similar to what you get when using a circular window. Using "circle" should be the fastest, and using "buffer" should be the slowest in most cases. The function should now in all cases be memory-safe, except, perhaps when using very large buffers (more could be done if need be).
Version 1.6-28 is currently the development version. You can install it with
install.packages('terra', repos='https://rspatial.r-universe.dev')
The approach you take seems to depend on what result you're looking for from the above and the relationship they have with each other.
library(terra)
`terra::buffer(` # both SpatVectx/SpatRastery, to distance in 'm'
`terra::buffer(` # that is meaningful
#take Rasty to SpatVecty
`terra::as.polygons(`, #then
`z<-terra::intersection(SpatVectx, SpatVecty)`
then back to SpatRastz? terra::mask or crop, might also be useful, again depending on where things are going next.
I'm currently struggling with some image analysis. I have images of zebrafish embryo vasculature, and I want to measure the distance between certain features (the highest point to the lowest etc).
I have processed the images to be more visible (higher contrast) using EBImage
.
I would appreciate any guidance.
Since you are using R and EBImage, I would presume that there is more analysis intended than just extracting measurements from an image. If that is all you intend, other software such as Fiji or the more streamline precursor, ImageJ, may be more user-friendly.
To answer the question, don't use display() for the image as you show here. Rather, use the plot() method that uses the option method = raster as the default. With the image plotted in a graphic window, you can use all the tools of R to interact with the plot. The resolution you have is determined by the size of your image and display. All values are returned in pixels and obviously need to be scaled appropriately.
This example uses locator() in a small helper function to measure diagonal distances between vascular junctions (?) in the image.
This simple helper function marks two points and measures the distance between the points. End the call to locator() with a right-click control-click or the escape key. In RStudio, you may have to explicitly press another button in the window and the points/lines may not be drawn until all calls to locator() are terminated.
p2p <- function(n = 512) # end with ctrl-click or Esc
{
ans <- numeric()
while (n > 0) {
# this call to locator places 2 points as crosses
# and connects them with a line
p <- locator(2, type = "o", pch = 3, col = "magenta")
if (is.null(p)) break
ans <- c(ans, sqrt(sum(sapply(p, diff)^2)))
n <- n - 1
}
return(ans) # return the vector of point-to-point distances
}
Now replot the image in the question (without the elements from the browser display) and then interact with the image.
plot(img) # not 'display(img)'
d <- p2p() # interact with the image, collecting distances
Here's the image after selecting six pairs of points with the distances measured between each pair of points.
round(d, 1)
> [1] 113.4 99.2 109.4 110.8 120.6 122.7
mean(d)
> 112.6736
Have fun!
Not dumb at all. Yes, it is in pixels—EBImage and R gives you fractional pixels.
Somewhat inexplicably, the length parameter in arrows is specified in inches (from ?arrows):
length length of the edges of the arrow head (in inches).
R source even goes so far as to explicitly make note that this measurement is in inches in a comment, highlighting how peculiar this design is.
That means the relative size of the arrows depends on dev.size(). What's not clear is how to translate inches into axis units (which are infinitely more useful in the first place). Here's a simplified version:
h = c(1, 2, 3)
xs = barplot(h, space = 0, ylim = c(0, 4))
arrows(xs, h - .5, xs, h + .5,
length = .5*mean(diff(xs)))
How this displays will depend on the device. E.g. here is the output on this device:
png('test.png', width = 5, height = 5)
And here it is on another:
png('test.png', width = 8, height = 8)
It's a bit of an optical illusion to tell on sight, but the arrows are indeed the same width in the two plots. How can I control this so that both plots (which convey the same data) display identically? More specifically, how can I make sure that the arrows are exactly .5 plot units in width?
I spent far too much time in the rabbit hole on this, but here goes. I'll document a bit of my journey first to aid others who happen upon this in the types of nooks and crannies to search when trying to pull yourself up by your bootstraps.
I started looking in the source of arrows, but to no avail, since it quickly dives into internal code. So I searched the R source for "C_arrows" to find what's happening; luckily, it's not too esoteric, as far as R internal code goes. Poking around it seems the workhorse is actually GArrow, but this was a dead end, as it seems the length parameter isn't really transformed there (IIUC this means the conversion to inches is done for the other coordinates and length is untouched). But I happened to notice some GConvert calls that looked closer to what I want and hoped to find some user-facing function that appeals to these directly.
This led me to go back to R and to simply run through the gamut of functions in the same package as arrows looking for anything that could be useful:
ls(envir = as.environment('package:grDevices'))
ls(envir = as.environment('package:graphics'))
Finally I found three functions in graphics: xinch, yinch, and xyinch (all found on ?xinch) are used for the opposite of my goal here -- namely, they take inches and convert them into device units (in the x, y, and x&y directions, respectively). Luckily enough, these functions are all very simple, e.g. the work horse of xinch is the conversion factor:
diff(par("usr")[1:2])/par("pin")[1L]
Examining ?par (for the 1,000,000th time), indeed pin and usr are exactly the graphical parameter we need (pin is new to me, usr comes up here and there):
pin The current plot dimensions, (width, height), in inches.
usr A vector of the form c(x1, x2, y1, y2) giving the extremes of the user coordinates of the plotting region.
Hence, we can convert from plot units to inches by inverting this function:
xinch_inv = function(dev_unit) {
dev_unit * par("pin")[1L]/diff(par("usr")[1:2])
}
h = c(1, 2, 3)
xs = barplot(h, space = 0, ylim = c(0, 4))
arrows(xs, h - .5, xs, h + .5,
# just convert plot units to inches
length = xinch_inv(.5*mean(diff(xs))))
Resulting in (5x5):
And (8x8):
One further note, it appears length is the length of each side of the arrow head -- using length = xinch_inv(.5), code = 3, angle = 90 results in segments as wide as the bars (i.e., 1).
On the off chance you're interested, I've packaged these in my package as xdev2in, etc.; GitHub only for now.
A quick question that I can't find answer on the web (or Wickham's book):
What is the unit of the size argument in ggplot2? For example, geom_text(size = 10) -- 10 in what units?
The same question applies to default unit in ggsave(height = 10, width = 10).
The answer is : The unit is the points. It is the unit of fontsize in the grid package. In ?unit, we find the following definition
"points" Points. There are 72.27 points per inch.
(but note the closely related "bigpts" Big Points. 72 bp = 1 in.)
Internally ggplot2 will multiply the font size by a magic number ggplot2:::.pt, defined as 1/0.352777778.
Here a demonstration, I create a letter using grid and ggplot2 with same size:
library(grid)
library(ggplot2)
ggplot(data=data.frame(x=1,y=1,label=c('A'))) +
geom_text(aes(x,y,label=label),size=100)
## I divide by the magic number to get the same size.
grid.text('A',gp=gpar(fontsize=100/0.352777778,col='red'))
Addendum Thanks to #baptiste
The "magic number"(defined in aaa-constants.r as .pt <- 1 / 0.352777778) is really just the conversion factor between "points" and "mm", that is 1/72 * 25.4 = 0.352777778. Unfortunately, grid makes the subtle distinction between "pts" and "bigpts", which explains why convertUnit(unit(1, "pt"), "mm", valueOnly=TRUE) gives the slightly different value of 0.3514598.
The 'ggplot2' package, like 'lattice' before it, is built on the grid package. You can get the available units at:
?grid::unit
?grid::convertX
?grid::convertY
grid::convertX(grid::unit(72.27, "points"), "inches")
(I use the formalism pkg::func because in most cases grid is loaded a a NAMESPACE but not attached when either lattice or `ggplot2 are loaded.)
I earlier posted a comment that I later deleted saying that size was in points. I did so after seeing that the size of the text with size=10 was roughly 10 mm. The "magic" number mentioned by agstudy is in fact within 1% of:
as.numeric(grid::convertX(grid::unit(1, "points"), "mm"))
#[1] 0.3514598
0.352777778/.Last.value
#[1] 1.00375
From ?aes_linetype_size_shape
# Size examples
# Should be specified with a numerical value (in millimetres),
# or from a variable source
height and width in ggsave relate to par("din") from ?par
din
R.O.; the device dimensions, (width, height), in inches. See also dev.size,
which is updated immediately when an on-screen device windows is re-sized.
So I guess size in aes is in millimetres and ggsave height and width are in inches.
I would like to know the approximate dimensions of symbol in my plot area. I think that par()$ps only really refers to text size. So how is a symbol size calculated using the cex parameter? For example, below is a plot of a single point of size cex=10. Can i determine its size from the plot devices par parameters?
plot(50, 50, ylim=c(0,100), xlim=c(0,100), cex=10)
#click on outer x limits
p1 <- locator(n=1,typ="n")
p2 <- locator(n=1,typ="n")
#approx width in x units(~15)
abs(p1$x - p2$x)
Thanks for you help. -Marc
According to the documentation contained in ?par, we have that,
cin - R.O.; character size (width, height) in inches. These are the same measurements as cra, expressed in different units.
cra - R.O.; size of default character (width, height) in ‘rasters’ (pixels). Some devices have no concept of pixels and so assume an arbitrary pixel size, usually 1/72 inch. These are the same measurements as cin, expressed in different units.
On my machine, these values appear to be:
par("cin")
[1] 0.15 0.20
> par("cra")
[1] 10.8 14.4
So character magnification via cex ought to happen relative to these dimensions, presumably by scaling the horizontal and vertical dimensions separately (although I don't know that for sure).