-
Notifications
You must be signed in to change notification settings - Fork 222
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
Random rotations are not uniformly sampled #84
Comments
Indeed. How would you do this instead? I am not an expert in this at all :-) |
There are multiple methods, see for instance: https://mathworld.wolfram.com/SpherePointPicking.html Since
|
so if we use |
Yes, according to the documentation, the resulting rotation matrices are uniformly distributed and 10k random rotations of a single fixed vector look uniformly distributed to me. I don't have a solution that preserves uniformity and works if your bounds are defined in Euler angles. For the 2D case, it is sufficient to produce random angles uniformly in the interval of interest. For 3D, Euler angles (and quaternions) are discontinuous (see https://arxiv.org/abs/1812.07035). Interpolation in SO(3) can be performed linearly using the Lie algebra (link). For instance, 100%, 30% and 10% rotations obtained via |
Actually, the method I posted of sampling a uniform unit vector for the axis together with a uniform random angle is wrong. I actually found this out 8 years ago and completely forgot about it. Here is the answer I got 8 years ago. It uses rejection sampling which is quite efficient for small rotation angles. Another solution is to generate a uniform random point on the spherical cap (centered on e.g. the x-axis) like here, and take the cross product with the x-axis to get the axis and angle of rotation. |
I recognize that this is an important problem and would like to improve this in batchgenerators. Unfortunately this is really going well over my head. Would it be possible for one of you to contribute a function that, given intervals for rotation around each axis will return a rotation matrix that is uniformly distributed on the unit sphere within the allowed range? def uniformly_sample_rotation_matrix(angle_range_x: Tuple[float, float], angle_range_y: Tuple[float, float], angle_range_z: Tuple[float, float]) -> np.ndarray:
XXXX |
Hey, thank you so much! I think that the rectangular shape is actually the intended behavior. If the user specifies a max angle of rotation of 15 degrees along all axes then the corners are exactly that maximum. But I am happy to investigate the sampling of euler angles as well. Maybe I am just dumb - but how do I get a rotation matrix out of the rotation vectors you are returning? |
I don't quite understand why anyone would want to specify separate angles. Perhaps something to do with how the patient can be oriented on the table? If that's the intended behaviour, there is probably also an issue with the order of rotations. If you change the order this rectangular shape will be rotated. Note that the shape is not symmetric, the top and bottom is flat, while the sides are not. About your second question, if you use scipy, you can get the rotation matrix like this: from scipy.spatial.transform import Rotation as R
rotation_matrix = R.from_rotvec(rotvec).as_matrix() |
Thanks! batchgenerators is not just for medical images, it is supposed to be a general purpose tool. I agree that having the rectangular is not ideal - it's just how we initially designed it and as you said: the design has flaws. That is why I am happy to look into your approach. Some use cases might want to be able to specify different angles around different axes. You are of course right that the order of the rotations matters. Not sure what the best solution is here |
Due to the use of Euler angles (yaw-pitch-roll), the rotations are not uniformly distributed. I'm not sure what the motivations is for choosing this convention. This choice can lead to various problems, for example in nnUnet, it is difficult to calculate the patch_size correctly. Presumably, orientations closer to the original one are sampled more, so you need much higher sampling to sample more different orientations. I'm not sure what the impact of this is on learning, but it might be worth checking out.
The text was updated successfully, but these errors were encountered: