Wouldn't it make more sense if `image::open()` automatically applied the orientation by default?
Resizing images in Rust, now with EXIF orientation support
11–20 of 35 posts
Re: Resizing images in Rust, now with EXIF orientation support
#12Earlier quoted context omitted.
One reason I can think of: when you rotate an image in the windows photo viewer (and probably lots of other apps), it stores that in the EXIF metadata. So the rotation is lossless, by not having to re-compress the JPEG. I could also imagine that the earliest digital cameras wouldn't have had the processing power, or RAM to store the entire image in memory after reading it from the sensor, in order to do such a rotati…
You can rotate (in 90 degree increments) and mirror jpgs losslessly. I assume it doesn't require much ram or compute since you're just reordering the blocks. https://www.betterjpeg.com/lossless-rotation.htm
Having read that article, I'd say this is not really an honest takeaway. I mean, I guess it is lossless, it just really flies in the face of what I'd consider reasonable baseline expectations.
They offer three "solutions" to the issue of partial blocks:
- cut them off and stop worrying about it
- show whatever the original JPEG encoder put there and stop worrying about it
- replace whatever the original JPEG encoder put there and stop worrying about it
I cannot imagine anyone honestly considering these and then shipping them. It's fine if the user manually consents, but automated, this is pretty objectionable. Extending the image in arbitrary ways or cutting off of it is really not what I'd expect from a codec to do when I ask it to perform a lossless transformation, particularly specific ones, like flip and rotate, which I'd expect to be outright periodic. And periodicity is violated immediately with the dimensions changing.
Re: Resizing images in Rust, now with EXIF orientation support
#13The rexif crate supports editing, so you can apply rotation when resizing, and then remove the rotation tag from the EXIF data. Keeping EXIF isn't necessary for small thumbnails, but could be desirable for larger versions of the image.
Re: Resizing images in Rust, now with EXIF orientation support
#14Earlier quoted context omitted.
One reason I can think of: when you rotate an image in the windows photo viewer (and probably lots of other apps), it stores that in the EXIF metadata. So the rotation is lossless, by not having to re-compress the JPEG. I could also imagine that the earliest digital cameras wouldn't have had the processing power, or RAM to store the entire image in memory after reading it from the sensor, in order to do such a rotati…
You can rotate (in 90 degree increments) and mirror jpgs losslessly. I assume it doesn't require much ram or compute since you're just reordering the blocks. https://www.betterjpeg.com/lossless-rotation.htm
[deleted]
Re: Resizing images in Rust, now with EXIF orientation support
#15I'm sure there's very good reasoning but I've never been able to convince myself of it - why does EXIF transform metadata exist? If you're taking a selfie, why doesn't the camera itself perform a simple rotation or mirror of the actual image data rather than using EXIF?
You need to appreciate how little RAM and CPU power those cameras have.
As far as cost:
Applying the right tag: 0
Anything else: not 0
Why not include a faster CPU or more RAM? In an industry where people pick one product over the other because of a $10 price difference, you’re never going to convince management to approve the better CPU when a tag solves the problem.
These are hardware companies. They look at software as a nuisance. “fix it in software” is for the downstream.
Re: Resizing images in Rust, now with EXIF orientation support
#16I'm sure there's very good reasoning but I've never been able to convince myself of it - why does EXIF transform metadata exist? If you're taking a selfie, why doesn't the camera itself perform a simple rotation or mirror of the actual image data rather than using EXIF?
I don't know why I should have a preference when it comes to the memory layout of an image. If metadata tells be to orient it this way, I'll orient it this way, if that way, then that way. It seems weird and wasteful to me (and potentially prone to error) to want to reorder the data in order to change the display orientation.
I can only imagine caring when it comes to streaming a very large image serially, and then I still have no idea what preference I would have (other than that I get the metadata first.)
As an analogy, if I have some irreplaceable video that has a bad aspect ratio, I fix it in the metadata, I don't transcode it. The data is a blob, the metadata is what tells me how to display it (even if it's just the mimetype.)
Re: Resizing images in Rust, now with EXIF orientation support
#17One good reason to keep the raw data and orientation separate is hardware calibrations. I see some discussion here along the lines of "why not just flip the data before saving it", and one counter-argument is that you should store the flip metadata anyways, as it important to trace which hardware pixel corresponds to which stored pixel. I realize this information is not vital for everyone, but it is super useful in fields where you need to characterize the hardware performance at the pixel level (for example astronomy).
Re: Resizing images in Rust, now with EXIF orientation support
#18a wasm port available?
Re: Resizing images in Rust, now with EXIF orientation support
#19Earlier quoted context omitted.
You can rotate (in 90 degree increments) and mirror jpgs losslessly. I assume it doesn't require much ram or compute since you're just reordering the blocks. https://www.betterjpeg.com/lossless-rotation.htm
Having read that article, I'd say this is not really an honest takeaway. I mean, I guess it is lossless, it just really flies in the face of what I'd consider reasonable baseline expectations. They offer three "solutions" to the issue of partial blocks: - cut them off and stop worrying about it - show whatever the original JPEG encoder put there and stop worrying about it - replace whatever the original JPEG encoder…
Does the issue of partial blocks come up for any real world sensor sizes?
Re: Resizing images in Rust, now with EXIF orientation support
#20Earlier quoted context omitted.
Having read that article, I'd say this is not really an honest takeaway. I mean, I guess it is lossless, it just really flies in the face of what I'd consider reasonable baseline expectations. They offer three "solutions" to the issue of partial blocks: - cut them off and stop worrying about it - show whatever the original JPEG encoder put there and stop worrying about it - replace whatever the original JPEG encoder…
Does the issue of partial blocks come up for any real world sensor sizes?
Considering I'd need to enumerate every single sensor in former or current production to answer that, that's a very good question indeed. I have no idea dude.
Are all JPEGs photos, following sensor pixel dimensions?