read user-defined exif tags

[zisoft]

This change implements reading of exif tags which were added to the metadata editor.

In previous versions the metadata editor allowed to add all tags which are supported by exiv2. This led to some confusion when users added exif tags to the metadata editor and then expected these tags to be read on import, which didn't work.

The "solution" was to restrict the list of allowed tags for the metadata editor to only those tags which are supposed to be user-editable. I have removed this restriction, now the user has complete freedom on what tags to add.

Now on import or refresh EXIF the user-defined tags from the metadata editor are read from the image as well.

To test this I have added 5 exif tags to the metadata editor, which are definitely embedded in the image:

Which looks like this:

After importing a new image (or refresh EXIF on already existing ones):

Image information panel:

fixes #20856

@wpferguson : would you like to test?

[wpferguson]

🎆 🎆 🎆

One issue -

I added some fields and tested. Then I removed some fields and added different fields. When I did the save the image information module inverted the rows.

Next, how can I access the information from Lua? It'll probably take an API change. Maybe I can extend dt_lua_image_t with maybe value = image:metadata(<tag name>). This would save spawning exiv2 externally to get values for scripts.

Very good!

[zisoft]

...the image information module inverted the rows.

I have occasionally seen this in the image information module.
This PR does not touch the code of the image information module so this is a bug in that module which I will analyse separately.

[wpferguson]

I have occasionally seen this in the image information module.

I think it might have been that I removed and added fields at the same time and it just got confused.

[gi-man]

I think we need to add a note in the manual that the changes are only managed in the xmp / database. The raw file tags will remain unchanged. Maybe even tooltips since folks don't read the manual.

[wpferguson]

@zisoft this works even better than I thought. I went to look at adding metadata access to dt_lua_image_t and found that any defined metadata key gets automatically added to dt_lua_image_t and can be accessed by the last part of the tag name so if I

• define a metadata Exif.Canon.RawBurstModeRoll
• I can access it with <image>.RawBurstModeRoll

[zisoft]

@wpferguson : Using only the last part of the tag name is ambiguous. That's the reason why I had to change the tag name variable expansion to the full tag name.

[wpferguson]

Using only the last part of the tag name is ambiguous

in lua/image.c we do

  dt_pthread_mutex_lock(&darktable.metadata_threadsafe);
  for(GList *iter = dt_metadata_get_list(); iter; iter = iter->next)
  {
    dt_metadata_t *metadata = iter->data;

    if(!metadata->internal)
    {
      lua_pushcfunction(L, metadata_member);
      dt_lua_type_register(L, dt_lua_image_t, dt_metadata_get_tag_subkey(metadata->tagname));
    }
  }
  dt_pthread_mutex_unlock(&darktable.metadata_threadsafe);

which adds the metadata fields to dt_lua_image_t as R/W members using the subkey. I can see where it could be ambiguous, but that might also be an advantage, if they agree on subkey, where all the maker specific information is excluded

EDIT: The advantage comes with a caveat that the user only enables the metadata tag they need and not all of them 😄

[wpferguson]

Fixes #19973
Closes #19622 - fixes with a better solution

[zisoft]

in lua/image.c we do

That's my code :)

When I changed the variable expansion to the full tag name I simply forgot to change that part as well.

You are the lua expert, please decide what is best here.

[wpferguson]

That's my code :)

Between that and this PR it solves one of the biggest issues with Lua scripting, having to run an external executable to get metadata.

You are the lua expert, please decide what is best here.

For now I'd say it's not broken, so let's not fix it.