I noticed that RandomRotation range only from (min, max); however it is more realistic to rotate from the set (angle1, angle2, angle3) randomly?
Could you be a bit more clear on what you mean by those three angles?
When images are being randomly rotated, they should be rotated angle1 or angle2 or angle3 degrees, not from (mix, max) degrees
If I understand correctly, you are saying that we should propose the rotations to be randomly sampled from a discrete subset, instead of having them being sampled from a continuous interval, is that right?
If that's the case, I'd say that having it being sampled from an interval is more generic, and should probably be kept.
I agree with @fmassa. That being said, @noeagles, you could use the functional transforms and build that functionality yourself.
import torchvision.transforms.functional as TF
import random
angle = random.choice([-30, -15, 0, 15, 30])
img = TF.rotate(img, angle)
@fmassa @sotte Thank you both very much!! I came up with this issue mainly because that many papers i encoutered use discrete rotation as data augmentation. Thanks again!
How it can be used inside the transforms.Compose([...])?
Something like this would work:
import torchvision.transforms.functional as TF
import random
from typing import Sequence
class MyRotateTransform:
def __init__(self, angles: Sequence[int]):
self.angles = angles
def __call__(self, x):
angle = random.choice(self.angles)
return TF.rotate(x, angle)
@sotte do you think this snippet could be added somewhere in torchvision? Maybe in the documentation of rotate?
@fmassa Um, if you think it's helpful, sure :)
If we add this we should maybe just document the general procedure how you can use TF to build your own transform classes (and use the example from above).
I guess I could add it to https://pytorch.org/docs/stable/torchvision/transforms.html#functional-transforms.
I can create a PR (let me know if want something specific), but you can also just add the snippet. Both is fine with me.
I think a note in the documentation of the functional interface, explaining that it gives full flexibility sounds like best thing to do, with an example for a particular case, like the rotation that you proposed just above
I'll send the PR later today.
@fmassa I have a use-case which prohibits the use of "generic interval" rotations because it destroys information I need in the corners. In particular, I can only use order-4 symmetry transforms (image attached). Using only reflections (RandomHorizontalFlip and RandomVerticalFlip) I can only get 4 of the 8 possible transforms.
![]()
wiki/File:Dih4_cycle_graph.svg
These order-4 symmetry transforms are ubiquitous, for instance, in computer vision for satellite imagery research. I'm surprised that it isn't a built-in.
@crypdick that is a valid point.
@vfdev-5 thoughts on this?
@crypdick yes, rotations by 90 degrees as you suggest are definitely make sense for satellite, medical imagery and as data augmentations in torchvision. IMO, the reason why this is not yet built-in in torchvision, probably, due to "photography" type of imagery intended to be processed (like ImageNet) where upside-down rotation does not make much sense...
@fmassa I agree that this can be an enhancement for transforms and functional operations.
Most helpful comment
Something like this would work: