Most sensible remedy is probably to do something similar to what we're doing with crops that don't divide by 16 - do as much as we can in jpegtran but then passing the image to another lib to do the final bit of work? Might be possible here, might not, will require some investigation. At the very least doing rotations isn't a high throughput op so if it isn't as fast as other ops it's probably not the end of the world.
For example consider this (https://data.nhm.ac.uk/media/1d278ef1-35e2-41b5-bb34-aeaf35ff02e9/0,0,2048,2048/1500,/0/default.jpg):
vs. this (https://data.nhm.ac.uk/media/1d278ef1-35e2-41b5-bb34-aeaf35ff02e9/0,0,2048,2048/319,/!0/default.jpg):
See the right hand edge where something isn't right. This is due to a limitation in the jpegtran lib, as noted here: https://github.com/jbaiter/jpegtran-cffi/issues/23.
Most sensible remedy is probably to do something similar to what we're doing with crops that don't divide by 16 - do as much as we can in jpegtran but then passing the image to another lib to do the final bit of work? Might be possible here, might not, will require some investigation. At the very least doing rotations isn't a high throughput op so if it isn't as fast as other ops it's probably not the end of the world.