This is not “exactly” a bug, but something that limits the usefulness of the new vuo.image.equi.fisheye node. First, thanks for adding this and I’ve tested it and it performs identically to my shader versions, which is to be expected. However … the order of rotations is an issue. “Normally” one would want to tilt (latitude), then pan (longitude, about the poles) and then roll. When I suggested the order before perhaps there was some misunderstanding or misdirection on my part, because the order as implemented is the opposite, probably because the order in a shader should be the opposite to which one normally things because it involves a reverse mapping from output vector to input.
But, ideally one would be able to choose the order, but I’m not sure how this might be implemented. This applies to the order of rotations of 3D vectors in other nodes as well.
Other notes
Vuo version: 2.0.0-beta3
macOS version: macOS 10.13
How severely does this bug affect you? It’s annoying but I can work around it.
Maybe it’s related, maybe it’s not, but software I use for audio that rotates the audio scene often allow two possible sequences: Yaw → Pitch → Roll or Roll → Pitch → Yaw.
Is it something that would be pertinent to include in the node?
But, ideally one would be able to choose the order, but I’m not sure how this might be implemented. This applies to the order of rotations of 3D vectors in other nodes as well.
Good idea. That’s something we’d like to do eventually but is too much to fit into 2.0.0. Probably we’d add a new VuoRotation data type with an input editor where you could choose the order, then modify nodes that have rotation/transform input ports to use that type.
“Normally” one would want to tilt (latitude), then pan (longitude, about the poles) and then roll.
It would be an improvement over the current situation if we just reversed the order of the rotations on the vuo.image.equi.fisheye node to match what you stated above, right? We’ll plan to do that for 2.0.0.
The first suggestion would seem nice and general, so good as a future solution. If it fits into the proposed scheme, then the ability to add an indefinite number of rotations would be even better. For example, do a pan, then a roll, then a tilt, and then do another roll. This arises often when one does a correction for tilted cameras say, and the one applies the navigational rotations. For example in my command line apps I can do
-x 20 -y 90 -z 5 -y 20 etc
The second suggestion for this particular node would cover most cases (not all though) since panning and then tilting within 360 camera footage is the most common navigation, simulating longitude and latitude navigation.
It would be an improvement over the current situation if we just reversed the order of the rotations on the vuo.image.equi.fisheye node to match what you stated above, right? We’ll plan to do that for 2.0.0.
