Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug 17148: rasterImage shows incorrect image orientation #75

Open
5 tasks
hturner opened this issue Nov 8, 2024 · 1 comment
Open
5 tasks

Bug 17148: rasterImage shows incorrect image orientation #75

hturner opened this issue Nov 8, 2024 · 1 comment
Assignees
Labels
Graphics Issues related to graphics LatinR 2024 needs reprex Write a minimal reproducible example that demonstrates the bug R Issue should require knowledge of R only

Comments

@hturner
Copy link
Member

hturner commented Nov 8, 2024

This task is to create some test images to help with fixing Bug 17148. It has two parts - the second should only be attempt once the first is completed at least for the Cairo device.

Part 1: Image to check rotation

The following hand-drawn image is intended to demonstrate the documented behaviour of rasterImage:
IMG_0863

  • The blue square marks the position of the (xleft, ybottom) coordinate
  • The red square marks the position of the (xright, ytop) coordinate.
  • Based on the blue and red squares, we can determine the direction of the positive x axis (from xleft to xright) and the positive y axis (from ybottom to ytop). These are marked by the arrows labelled x and y.
  • Each quadrant shows a square with no rotation (angle = 0) and a rotation of 20 degrees anti-clockwise from positive x-axis about the bottom-left corner (angle = 20)

We expect this image to display correctly on a Cairo device, but incorrectly on other devices. You can draw on a Cairo device by changing the graphics backend in RStudio (Tools > Global Options > General > Graphics > Backend: Cairo) or setting type = "cairo" when opening a file to draw on, e.g.

png("demo.png", type = "cairo)
plot(1:10)
dev.off()

Todo:

  • Write some R code based on the raster4() function in Martin Maechler's comment to create the test plot. Use a Cairo device when developing your code.
    • The quadrants in the test plot are reordered from Martin's code: the first column of plots in the test plot corresponds to the second column in Martin's code.
    • Draw each black square based on a raster created from a 4x4 matrix of colours.
    • Redraw the border of each black square using rect(), grid.rect(). When everything is working correctly, this should draw on top of the previous border (you might play with line thickness/colour so we can see the overplotting). When something is not working, it may help us work out what is going wrong.
  • Once you have a working plot on the Cairo device, try drawing the plot on the devices below. Create the device using png(type = *) or windows(). You may need to enlist helpers to draw the plot on different operating systems. We expect some or all of these to look incorrect due to the existing bug(s)!
    • Quartz (only available on macOS) - set via RStudio or png()
    • Xlib (only available on macOS/Linux)
    • windows (only available on Windows)

Share your R code and the 4 images (or as many of the 4 images that you can produce) in a comment on this issue.

@hturner hturner added needs reprex Write a minimal reproducible example that demonstrates the bug Graphics Issues related to graphics R Issue should require knowledge of R only labels Nov 8, 2024
@hturner
Copy link
Member Author

hturner commented Nov 8, 2024

Part 2: Image to check orientation

In the first part, the raster (black square) was symmetrical about the diagonal from bottom-left (blue square) to top-right (red square). For the second image, we will use a non-symmetrical matrix that depicts an "F" shape:
IMG_0866
This will help us check if rasterImage() preserves the order of cells within thewhen the axes are rotated (i.e. when the location of "bottom-left" and "top-right" are not in the same orientation as the canvas). When everything is working correctly, the plot should look something like this:
IMG_0865

Warning: we think this will display correctly in the Cairo device, but it might not! Do not adapt the code to fix any problems you see!

Todo:

  • Update the R code from part 1 to draw the second image.
    • Plot a single "F" shape with angle = 0 in all four quadrants, using the same (xleft, ybottom) and (xright, ytop) coordinates as before.
    • Draw each F with a raster created from a 4x4 matrix of colours. These F's may not all look correct on the Cairo device, but at least the top-right F should look correct
    • Redraw each F using line() or grid.line() (you might play with line thickness/colour so we can see the overplotting). These F's should look correct on the Cairo device (and hopefully all devices, so we have a correct reference).
  • Once you have a working plot on the Cairo device, try drawing the plot on the devices below. We expect some or all of these to look incorrect due to the existing bug(s)!
    • Quartz (only available on macOS) - set via RStudio or png()
    • Xlib (only available on macOS/Linux)
    • windows (only available on Windows)

@pmur002 pmur002 self-assigned this Nov 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Graphics Issues related to graphics LatinR 2024 needs reprex Write a minimal reproducible example that demonstrates the bug R Issue should require knowledge of R only
Projects
None yet
Development

No branches or pull requests

2 participants