Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

easyaccess: list of keys for different meta data could be enhanced #2338

Closed
norbertwg opened this issue Aug 24, 2022 · 8 comments
Closed

easyaccess: list of keys for different meta data could be enhanced #2338

norbertwg opened this issue Aug 24, 2022 · 8 comments
Labels
request feature request or any other kind of wish

Comments

@norbertwg
Copy link
Contributor

I noticed, that the lists of keys in easyaccess.cpp seems to be incomplete.
One example: An image has Exif.PanasonicRaw.ISOSpeed filled, But as the image does not contain Exif.Photo or Exif.Image, the command exiv2.exe -ps does not show the ISO speed.

From my point of view, it makes sense to add Exif.PanasonicRaw.ISOSpeed to ExifData::const_iterator isoSpeed (and some others as well).

If Exif.PanasonicRaw was intentionally not included, please let me know. If this is not the case and in general the iterators should include all respective keys, I would create a list of keys, which I think are missing.

@norbertwg norbertwg added the request feature request or any other kind of wish label Aug 24, 2022
@postscript-dev
Copy link
Collaborator

postscript-dev commented Aug 26, 2022

@norbertwg:

I noticed, that the lists of keys in easyaccess.cpp seems to be incomplete.

If Exif.PanasonicRaw was intentionally not included, please let me know. If this is not the case and in general the iterators should include all respective keys, I would create a list of keys, which I think are missing.

You are right, the easyaccess.cpp list of tags is incomplete and I don't know of any reason to exclude the PanasonicRaw tags. This is part of the code that has not been kept up to date and needs work. In the future, when we add new tags to exiv2, it would be helpful to also update easyaccess.cpp.

As it happens, this is something that I have been looking at recently myself. In #2323, I am updating the Exif.Sony1/Exif.Sony2 tag group and decided to change easyaccess.cpp. However my PR only involves the tag group that I am working on.

Would you be willing to work on this? I don't have time to provide code but will try and answer questions if I can.

@norbertwg
Copy link
Contributor Author

@postscript-dev
Yes, I will work on it. Thanks for fast response and offer to answer questions.

@norbertwg
Copy link
Contributor Author

I have now an overview of potentially missing keys, which can be grouped as follows:

  1. Looking at the key and its value found in some examples, it can be clearly added to the respective list in easyaccess.cpp.
    Example: Exif.NikonLd4.FNumber has shown in all sample files the same value as Exif.Photo.FNumber

  2. The key is clear, the value is numeric, whereas keys alread added to easyaccess have descriptive values. Assuming that the intepreted values are just not yet implemented for these keys, I would add them to the group.
    Example: For Exif.Sony2.Saturation I found values 0, 1 and 3, whereas the already added keys have (interpreted) values like Normal, High, Enhanced.

  3. The key is clear, but the values found in examples do not match to already added keys. In this case I would not add the key as the output may be interpreted wrong.
    Examples:
    Exif.MinoltaCs5D.FNumber is of type Short and has in one file the value 56. Could be read as F5.6, but Exif.Photo.FNumber in the same file shows F8.
    Exif.Sony2010e.BrightnessValue has a Short value 15966, whereas the already added keys have Rational values like -1.83 or 2.03 - completely different number range.

  4. The key is clear, but I could not find example values. In this case I would not add the key as I cannot judge, which of the previous cases apply.

@postscript-dev: Is this approach reasonable and does it fit to the idea of exifeasy?

@postscript-dev
Copy link
Collaborator

@norbertwg:
Sorry for the delay replying.

I have now an overview of potentially missing keys, which can be grouped as follows:

I like your cautions approach. While reading your post, I thought of some things that might be of help.

  1. Some of the makernotes tags are encoded and require a translated function to make sense of them (e.g., Exif.NikonLd4.FNumber). Sadly the translated functions have not been added for every tag in Exiv2 (e.g., Exif.MinoltaCs5D.FNumber, Exif.Sony2010e.BrightnessValue). To fix this, I usually look at the tag in the ExifTool source code and transcribe their work into exiv2. Unless you want to, I don't expect you to do this for every tag in the easyaccess API. The encoding problem may be the reason why some of your tags were interpreted wrongly.
  2. As there are no published makernotes specifications, we are not always sure if a tag contains array descriptions or actual values. I usually look in ExifTool's tag list and the ExifTool source code as their list of tags is more complete than Exiv2.
  3. If you need more examples of metadata, then try ExifTool's JPEG samples. ExifTool attempt to include a sample file for every camera model that the manufacturer produces and this provides lots of helpful data.

@norbertwg
Copy link
Contributor Author

@postscript-dev
Thanks for the response and the helpful references, especially the source for samples. I will have a look on them and try to clarify my points and then prepare the changes in easyaccess.cpp. After that I will also have a look on missing translated functions. But as my knowledge of C++ is very limited, I might fail on that.

@kmilos
Copy link
Collaborator

kmilos commented Sep 7, 2022

Please also keep in mind that for some tags different vendors might mean different things and they are not necessarily readily interchangeable - this is the case e.g. for a lot of the custom ISO calculation code we have in easyaccess.cpp

Finally, this easy access is just there for some small convenience only - maintaining it and making it feature complete (how do you even set that goal?) might be a bit of a pain long term...

@norbertwg
Copy link
Contributor Author

@kmilos When I started, I thought it should be rather easy to make the feature "complete". But as you state and I have learned by looking at the different values from a lot of sample images, different vendors can have for some tags a different understanding what to store there. So make it complete will be quite difficult.
But after this investigation I think I have now also a better understanding what should be the goal. There is information, which is stored in standard tags (Exif.Image or Exif.Photo) and in maker specific tags. My observation: Usually the standard tags are filled, and as they are first checked in easyaccess.cpp, it makes no big difference, if a specific tag is missed. The big benefit of easyaccess is information, which is not stored in standard tags, e.g. lens name.
So my priority is to complete the tags, which are only in maker notes. The other tags I intend to add only, if based on the sample values I am sure, that the respective vendor has the same understanding of the value like expressed in already entered tags, especially those from Exif.Image and Exif.Photo.

norbertwg added a commit to norbertwg/exiv2 that referenced this issue Sep 19, 2022
@norbertwg
Copy link
Contributor Author

My PR to add some keys to easyaccess is merged, Some more keys are candidates to be added, but I think, this issue can be closed now. I will keep an eye on this topic and plan to make some more changes in easyaccess.

The result of my investigation is documented in the attached file.
easyaccess-analysis.md

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
request feature request or any other kind of wish
Projects
None yet
Development

No branches or pull requests

3 participants