`imrotate(img, pi/2)` changes size of image

[anandijain]

img = rand(RGB{N0f8}, 1000, 1000)
img2 = imrotate(img, π/2)
size(img) # (1000, 1000)
size(img2) # (1002, 1002)

I realize it's pretty naive to just ask "why doesn't this work as expected?". I get the sense that "simply" rotating an image is not so simple. (I know very little about image processing)

I'm wondering how I should get the desired result for rotations where the degree is multiples of pi/2. This might be related to #119 although I'm not sure.

Would it make sense to just define a new imrotate specifically for these factors of pi/2?

[johnnychen94]

The expectation that "imrotate(img, pi/2) should have the same size as img" can be somehow illusive due to the numerical error. A trick we use in this package is to discretization on ratio so that we consistently have imrotate(img, theta) == imrotate(img, theta+2pi) but that doesn't handle special pi/2, pi and 3pi/2 case.

ImageTransformations.jl/src/warp.jl

Line 247 in 4d89e5c

θ = floor(mod(θ,2pi)*typemax(Int16))/typemax(Int16) # periodic discretezation

To get the same size you can use imrorate(img, π/2, axes(img)).

---

Would it make sense to just define a new imrotate specifically for these factors of pi/2?

Yes it totally makes sense, I did some experiment a long time ago in #79 but there are performance concerns.

[johnnychen94]

Would it make sense to just define a new imrotate specifically for these factors of pi/2?

There're Base functions rotl90, rotr90 and rot180 for this very purpose. In the meantime, I still think #79 is needed.

I believe that we also need more documentation on this behavior because other image processing frameworks don't have this axes stuff.

[timholy]

This is also fixed by #148