image icon indicating copy to clipboard operation
image copied to clipboard

Reading and writing images with metadata

Open ror6ax opened this issue 1 year ago • 6 comments

So my use case is open a photograph, so stuff to it, save it in a different filename. So far I get pristine no-metadata images as the output, I'd like to copy over [some] metadata from the original image. Any recommendations how to do that? exif crate? From what I see it has it own reader, could I somehow not write the image and the exif in two passes on the same file?

ror6ax avatar Mar 28 '23 21:03 ror6ax

We really don't have much support for dealing with EXIF metadata today. It would be a bit of work, but if this is something you'd like to look at improving, I'd suggest starting with the individual image format crates. So png or tiff or whatever.

fintelia avatar Mar 29 '23 02:03 fintelia

Hi, I've recently fixed a bug in our app caused by image-rs ignoring orientation in metadata. Also lost metadata was a surprise as well. I've used the Rust crate kamadak-exif to read and filter Exif fields and then img-parts to write the Exif data. Also I had to fix the image orientation before processing the image by image-rs and then remove the orientation field from Exif. You can rewrite this C# snippet to Rust to fix the orientation. Just my tips / experience :)

MartinKavik avatar Apr 10 '23 15:04 MartinKavik

I'm interested in similar things for image editing in Loupe. I'm also willing to try contributing to it mid-term.

In my head, that needs a decoder that keeps all original image data around and returns a ReEncoder. If, for example, an image is just cropped, the ReEncoder would just be updated with the new image information. All data like ICC profile, CICP, EXIF, XMP, HEIF metadata, etc, would just remain untouched.

Additional to updating the image data, functions for updating that information as well, could be added. Updating fields inside the EXIF information should be left to an external library (it's a rabbit hole in itself.)

Trying to transfer all metadata explicitly sounds like an unrealistic task and not what one wants for image editing.

Of course, in practice, it's probably not that easy. The encoder for the format might not support the original storage format or other things. However, each encoder should have a pretty good idea of which chunks or segments it needs to write for image data so that it can add/replace them.

As recent bugs have shown, cropping an image and replacing the image data in place is apparently pretty easy to get wrong as well :upside_down_face:

In theory, the things I have described here should already be possible to do by combining img-parts and image-rs. However, having this feature in image-rs would be a much better thing.

sophie-h avatar Apr 27 '23 20:04 sophie-h

If you want to either (a) retain a specific sort of metadata like EXIF or ICC profile, or (b) retain all the metadata chunks from a file but accept that you'll be unable to convert formats, then I think this might be feasible to implement.

However, if you want to load an arbitrary PNG/JPEG/TIFF/etc. file and save it as a different one of those formats with every bit of metadata intact, you are looking at a huge undertaking. Many chunks don't have equivalents across all the formats, and even the ones that do may frequently require parsing and re-encoding the metadata.

fintelia avatar Apr 28 '23 02:04 fintelia

save it as a different one of those formats

Agreed, that's unrealistic and wasn't my intention. You would have to stick to the same format to ReEncode an image. What I meant with "storage format" in my original post is something like the original JPEG is progressive, but image-rs can only encode baseline.

sophie-h avatar Apr 28 '23 11:04 sophie-h

In that case, the best starting point would probably be to look at adding re-encoding functionality to one/several of the format specific crates image uses and then go from there.

fintelia avatar Apr 28 '23 17:04 fintelia