Hacker News Reader

Comment by rkagerer | Hacker News Reader

Even outside of machine vision this issue has caused me all sorts of headaches. Especially when switching between tools that honor or ignore the tag.

"But the tricky part is that your camera doesn’t actually rotate the image data inside the file that it saves to disk."

Cameraphones are so powerful these days. I don't understand why the app can't simply include a behavior setting to always flip the original pixels.

View on HN

It might not be up to the app? If the phone has hardware-accelerated JPEG compression, then potentially the image will already be compressed in the 'wrong' orientation before the app gets its hands on it. So rotating the image data could involve re-compressing the image again, leading to quality loss. Or if you choose to get the raw sensor data instead, and rotate the data before doing the compression yourself, you might lose out on the hw acceleration entirely.

(I've not developed any camera apps, so this is just a guess!)

> So rotating the image data could involve re-compressing the image again, leading to quality loss.

With JPEG, no, 90 degree rotations can be accomplished in a lossless manner.

See jpegtran from the libjpeg library. A version of its manpage is here:

https://linux.die.net/man/1/jpegtran

Quoting:

"... It can also perform some rearrangements of the image data, for example turning an image from landscape to portrait format by rotation.

jpegtran works by rearranging the compressed data (DCT coefficients), without ever fully decoding the image. Therefore, its transformations are lossless: there is no image degradation at all, which would not be true if you used djpeg followed by cjpeg to accomplish the same conversion. ..."

Because the data sources are unrelated. The camera sensor is hooked up to the ISP which is hooked up to a hardware JPEG encoder. This is necessary in order to get those hyper fast shots off.

You'll notice that an orientation sensor is no where in that list. So what happens is the camera hardware spits out a JPEG. The app then combines it with the orientation sensor & produces the EXIF headers. It could choose to decode, rotate, re-encode, but that's slow (~100ms) and hurts shot-to-shot latency. And it loses quality. And, hey, since everything supports EXIF orientation anyway, why bother?

> It could choose to decode, rotate, re-encode

Or it could simply rotate without decoding or re-encoding, which has the added advantage of being lossless.

Obviously it's still added processing time and (probably more importantly) development time, so it's generally not worth bothering, however it's important to point out that JPEG rotation can (in the case of 90 degree increments) be done losslessly.

The phone is accurately recording the image, as well as the orientation. The bug happens when the EXIF information is stripped. Sure, phone apps could add an option to physically rotate the image, as a bug workaround, but it's not surprising that they don't do this.

It is surprising, because it seems like such an obvious fix to the problem of stripped EXIF data. Couldn't be that hard to implement a user setting which tells the app to rotate the file itself before saving.

This is a major oversight for the companies who develop camera apps. The major ones even have whole teams dedicated to that single app.

It would be trivial to rotate a bitmap with no loss of quality, but you can’t rotate an already compressed jpg without changing the image itself, which reduces quality.

Assuming the image size is a multiple of the block size (8x8, 16x8, or 16x16 depending on the chroma subsampling), lossless rotation of JPEGs is possible, e.g. with jpegtran:

http://jpegclub.org/jpegtran/

Really interesting, good find.

Funny, it looks like a common headache.

Lots of other complaints in this thread and also something I have encountered on Android with a small side feature allowing users to upload some pictures.

Reply on news.ycombinator.com