[enen92]

Hey guys,

I've decided to spend some time improving our picture metadata handling for v22 since most of the exif tags, as you may have noticed, are broken. My plan is to delegate this to an external library (exiv2 being the most complete one I could find since it covers both EXIF and IPTC) and remove our internal parsing. The work has started here: https://github.com/xbmc/xbmc/pull/24109

Having said that, for those that use pictures in Kodi - or simply are more familiar with photos in general - which information do you find missing in Kodi that you'd like to see exposed in the UI (or other APIs)? I don't mean those that don't work currently and were supposed to work

You can see the available tags exiv2 provides here:

exiv: https://exiv2.org/tags.html
iptc: https://exiv2.org/iptc.html

Kodi provides a subset of them: https://github.com/xbmc/xbmc/blob/master....h#L49-L75

Cheers

[Buschel]

Thanks for looking into this and bringing this to the next level for future Kodi versions.

But let me ask: Is there any chance to fix the functionality which broke after Kodi 19.5? For the same images the JSON API on Kodi 19.5 provides EXIF data, but not on 20 and 21 anymore. It seems not to be a problem of the tags not being interpreted correctly, but something else (JSON API?).

[enen92]

Thanks for looking into this and bringing this to the next level for future Kodi versions.

But let me ask: Is there any chance to fix the functionality which broke after Kodi 19.5? For the same images the JSON API on Kodi 19.5 provides EXIF data, but not on 20 and 21 anymore. It seems not to be a problem of the tags not being interpreted correctly, but something else (JSON API?).

I had a look into it first but the issue is precisely the fact most of the tags (except camera make, model and others) not being extracted in the first place. This was caused by a few backports from chromium libexif to fix security issues (reading out specific offsets). The effort and energy to fix this is IMOH quite a waste of time since this is better delegated to external and well maintained libraries than using a custom parser like kodi does. I also plan to add a few unit tests to make sure it doesn't break accidentally in the future.
That being said, at least I won't pursue a band-aid fix for v21 (but others are for sure free to take the initiative).

[Buschel]

This was caused by a few backports from chromium libexif to fix security issues (reading out specific offsets). The effort and energy to fix this is IMOH quite a waste of time since this is better delegated to external and well maintained libraries than using a custom parser like kodi does.

Thanks for sharing the background, this makes sense.

[Buschel]

This was caused by a few backports from chromium libexif to fix security issues (reading out specific offsets). The effort and energy to fix this is IMOH quite a waste of time since this is better delegated to external and well maintained libraries than using a custom parser like kodi does.

I tried to look into the latest changes (the recent back ports which were made in 7e5f9fbf and 00fec1db) to see, if I can a way to fix this. But these changes are not making any difference. I then tried to bisect, but failed to compiled older Kodi versions due to compile/liinker failure around ffmpeg. As we got reports that exif problems occurs since already since 20.0 (see GitHub #22900), but all works with 19.5, the root cause is older. When I look at all changes done to the code exif code I do not see any other relevant change since Kodi 19.5. But for the whole folder /xbmc/pictures there is e.g. 1de66eb8 which seems an interesting candidate. Do you have other changes in mind which caused the problem? Are you by chance able to build such older version?

[enen92]

This was caused by a few backports from chromium libexif to fix security issues (reading out specific offsets). The effort and energy to fix this is IMOH quite a waste of time since this is better delegated to external and well maintained libraries than using a custom parser like kodi does.

I tried to look into the latest changes (the recent back ports which were made in 7e5f9fbf and 00fec1db) to see, if I can a way to fix this. But these changes are not making any difference. I then tried to bisect, but failed to compiled older Kodi versions due to compile/liinker failure around ffmpeg. As we got reports that exif problems occurs since already since 20.0 (see GitHub #22900), but all works with 19.5, the root cause is older. When I look at all changes done to the code exif code I do not see any other relevant change since Kodi 19.5. But for the whole folder /xbmc/pictures there is e.g. 1de66eb8 which seems an interesting candidate. Do you have other changes in mind which caused the problem? Are you by chance able to build such older version?

Should be fixed by https://github.com/xbmc/xbmc/pull/24344 for v21.

[Buschel]

Should be fixed by https://github.com/xbmc/xbmc/pull/24344 for v21.

Thanks for this fix. I confirm the JSON API now again provides the EXIF data (local build of Kodi master).

On the initial question in which tags to support: I guess the best would be to keep supporting the same as we do right now -- also keeping the same JSON API naming conventions. There might otherwise be impacts to applications/skins which use the API. Or is there a technical reason to drop compatibility?

[enen92]

Should be fixed by https://github.com/xbmc/xbmc/pull/24344 for v21.

Thanks for this fix. I confirm the JSON API now again provides the EXIF data (local build of Kodi master).

On the initial question in which tags to support: I guess the best would be to keep supporting the same as we do right now -- also keeping the same JSON API naming conventions. There might otherwise be impacts to applications/skins which use the API. Or is there a technical reason to drop compatibility?

Yeah there's technical reasons behind the question. There are two tags that are not either EXIF or IPTC: Slideshow.Process and Slideshow.Colour. They are "tags" that only apply to JPEG and are not available is any of the opensource libraries available - they are related to the parsing of the JPEG file itself. They convey little to no useful information and while it's somehow possible to try to extend the library I plan to use to include them, I don't think it's worth the effort. They only exist in Kodi because we parse the files and include logic to extract metadata (unmaintained as you can tell by the long time this has been broken...). Nuking this and rely on an external well maintained library will make Kodi more close to support newer tags (e.g. exif 3 was published a while ago: https://iptc.org/news/exif-3-0-released-...8-support/ and the library already has this on the roadmap https://github.com/Exiv2/exiv2/issues/2659 )

I plan to add Slideshow.Colourspace as an alternative to Colour (since that is a standard exif tag unlike the later). For Process I think I'll simply nuke it, probably will add Slideshow.Software to have the same number of tags (implementation of this tag is not completed nowadays).
I've taken a look into what other software tools display for exif tags and we already cover them all.

[Buschel]

Thanks for sharing the details. Seems the most important infos/tags are still supported. When I was searching for which tags to show in the remote app I finally took a kind of "most wanted" and neither "Process" nor "Colour" was part of them.

Remote app's list:

Code:

Resolution
Filename
CameraModel
EXIFTime
Aperture
ISOEquivalence
ExposureTime
Exposure
ExposureBias
MeteringMode
FocalLength

And I remember that also

Code:

CameraMake, FlashUsed, Whitebalance, Description

and the

Code:

GPS

tags are used often.

[Stafthcote]

Thank you for addressing this matter and for considering its implications for future Kodi versions.

However, I'd like to inquire: Is there a possibility of rectifying the functionality that ceased to function properly after Kodi 19.5? Specifically, for the same images, the JSON API on Kodi 19.5 presents EXIF data, whereas versions 20 and 21 no longer do so. It appears that this issue may not stem from misinterpreted tags, but rather from another aspect such as the JSON API.