Support to set the new orientation as EXIF metadata

[h2non]

In case of image rotation / flip, it could be useful to store the new orientation as image metadata header before saving?

I guess it could be done from image headers functions:
http://www.vips.ecs.soton.ac.uk/supported/7.40/doc/html/libvips/libvips-header.html#vips-image-set

Thanks

[lovell]

Is this due to a side effect of using the existing auto-orient feature of rotate() and withMetadata() together, where the output image might then have the incorrect metadata value? If so, a quick fix might be to clear this header if a rotation/flip was required to achieve auto-orientation.

If more than this, then It's possible to set the orientation value; the complexity is in what value it should be set to.

What would you expect to happen if there is already an existing orientation value combined with an explicit rotation or flip? A few worked examples or test cases would help the implementor of such a feature.

Simplifying things slightly, would exposing the ability to manually set arbitrary EXIF headers provide enough API for you to plug in your own logic?

[h2non]

Thank you Lovell for the quick response.

The idea is, essentially, in the case that the user want to flip an image, and then reprocess it, I think there's no way to auto detect the rotation degrees of the processed image. Regarding to the original value, the idea could be simply override the previous rotation value, if it exists o not.
In any case, I think the user should explicitly define a option to enable the override/update the image headers over the different transformation processes.

Regarding to the EXIF headers, I think it could be a good solution, therefore supporting native bindings from the public API could be a reasonable approach to provide the freedom to manipulate the EXIF metadata with more versatility.

[lovell]

My current thinking around the behaviour and API to support this is to do both of the following:

• Remove the orientation metadata, if present, when using any of rotate, flip or flop.
• Extend the existing withMetadata method to accept optional key/values to override. Initially this would only support the orientation attribute, e.g. withMetadata({orientation: 0}).

[lovell]

The current libvips logic seems to be only able to set EXIF tags in JPEG output where those tags already existed in the input (and have not been explicitly removed).

This means the use of withMetadata({orientation: 3}) will only update an existing EXIF Orientation tag and will not add it.

[h2non]

What about vips_image_set()?

[lovell]

@h2non Whilst it's possible to set arbitrary image headers during the pipeline, libvips' JPEG writer seems to loop over the input's EXIF headers to set the output headers and therefore is ignoring any inserted EXIF headers.

@jcupitt Would it make sense for libvips' logic to be modified to instead loop over all image headers with an exif- prefix at write-time?

[jcupitt]

Oh yes, you're right, you can't set new EXIF tags, I hadn't thought of that. You're right, it should probably look for any metadata starting with "exif-". I'll have a look.

On autorotate, I think my 2p would be to have a special autorotate() method which looked at the orientation tag, applied it, then removed it. I'd think it would be unexpected to auto remove it anywhere else.

[lovell]

Thanks for confirming John. sharp's parameter-less version of rotate() provides the "autorotate" feature.

With commit d303703 I've added the ability to override the Orientation tag using withMetadata.

Any change to libvips to allow the insertion of new EXIF tags should get automagically picked up too.

The default behaviour of sharp, which I believe meets most web use cases, is to strip EXIF metadata anyway. Should someone rotate or mirror an image then any existing Orientation value is going to be wrong. At least they can now manually re-insert the wrong value if so desired :)

[lovell]

This is now in master awaiting release.

[lovell]

v0.11.0 will be released today with this improvement, thanks for the original suggestion.

[h2non]

@lovell Thank you!

[jcupitt]

I've made a vips branch with this change.

Unfortunately I had to change the way exif tags are encoded as vips metadata fields :( before it was

"exif-ifd%d-%s", ifd, title

I'm not sure why. But the title field of an exif entry is subject to i18n and also can't be looked up by libexif, for obvious reasons, so there was no way to create a new exif tag on output.

I've changed it to be

"exif-ifd%d-%s", ifd, name

where name is the canonical tag name. These can now be looked up, so it's possible to create new tags by setting vips metadata.

Of course this means most vips exif metadata has been renamed, very unfortunate. The only good thing seems to be that the "Orientation" tag has the same title and name, so that at least hasn't changed.

All code which looks at exif tags needs checking and updating.

[lovell]

Thanks John, your libvips' change feels like the right future-proof approach (even though it breaks the API).

Currently the only EXIF tag sharp cares about is Orientation so should work before and after.

[jcupitt]

I've fixed up some more stuff, added a test for exif modification, and merged to master.

jcupitt/libvips@2a6dd4e...677a7db