Pictures: Move image metadata processing to exiv2 as a new dependency

[enen92]

Description

This provides a revamp of our picture metadata (exif and iptc) extraction handling logic moving it from a custom implementation (untouched for 14 years - and rencently broken (and fixed) for most of the tags) to an external dependency (exiv2). This allows us to use a single dependency for all image metadata needs and also avoid a lot of corner cases we have currently in our own handling logic while contributing directly to the open-source ecosystem.

Upstream contributions:
Add EXIV2_ENABLE_FILESYSTEM_ACCESS option - Exiv2/exiv2#2837
Set conditional HTTP depending on EXIV2_ENABLE_WEBREADY - Exiv2/exiv2#2844
jpeg: add encodingProcess and numColorComponents SOF members - Exiv2/exiv2#2874
Disable psapi in UWP (unsupported): Exiv2/exiv2#2990

Motivation and context

Custom logic we have in Kodi without any maintainers should be delegated as much as possible to well maintained libs. Exiv2 is a good example, well maintained, easy to contribute and is part of a lot of software projects (e.g. gimp). Also cleans up a lot of magic in GUIPictureInfo.

How has this been tested?

Runtime tested in windows, android, macOS as well as UWP.

What is the effect on users?

None, this is a 1:1 match of our current implementation. I'll track eventual regressions.

Screenshots (if appropriate):

IPTC:

EXIF:

Types of change

• Bug fix (non-breaking change which fixes an issue)
• Clean up (non-breaking change which removes non-working, unmaintained functionality)
• Improvement (non-breaking change which improves existing functionality)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that will cause existing functionality to change)
• Cosmetic change (non-breaking change that doesn't touch code)
• Student submission (PR was done for educational purposes and will be treated as such)
• None of the above (please explain below)

Checklist:

• My code follows the Code Guidelines of this project
• My change requires a change to the documentation, either Doxygen or wiki
• I have updated the documentation accordingly
• I have read the Contributing document
• I have added tests to cover my change
• All new and existing tests passed

[garbear]

great work so far! looking forward to this reaching completion for P*.

[fuzzard]

Test failure completely unrelated, and build failure from previous 2 jobs were builder related and not a test failure. Merging now

[thexai]

exiv2 fails to build in debug mode:

cl : command line error D8016: '/Ox' and '/RTC1' command-line options are incompatible

to reproduce:

cmake -G "Visual Studio 17 2022" -A x64 -T host=x64 V:\kodi

cmake --build . --config "Debug" --target exiv2

Seems is due this:
https://github.com/Exiv2/exiv2/blob/e843bc4834aff138db7dc87bd2f4dfd98c49de4a/cmake/compilerFlags.cmake#L136

[enen92]

@fuzzard I guess I need your help. Any way of guarding that set call if RTC1 is enabled? For what I can tell it seems to be set by cmake build type debug automatically.

[fuzzard]

There isnt. your options are either patch it out of the exiv lib, or alter our flags we pass through. We do option 2 for the effects11 library already for a pointer to how to do it on our side

xbmc/cmake/modules/FindEffects11.cmake

Lines 17 to 26 in 5069e47

	# Effects 11 cant be built using /permissive-
	# strip and manually set the rest of the build flags
	string(REPLACE "/permissive-" "" EFFECTS_CXX_FLAGS ${CMAKE_CXX_FLAGS} )
	set(CMAKE_ARGS
	"-DCMAKE_CXX_FLAGS=${EFFECTS_CXX_FLAGS} $<$<CONFIG:Debug>:${CMAKE_CXX_FLAGS_DEBUG}> $<$<CONFIG:Release>:${CMAKE_CXX_FLAGS_RELEASE}>"
	"-DCMAKE_EXE_LINKER_FLAGS=${CMAKE_EXE_LINKER_FLAGS} $<$<CONFIG:Debug>:${CMAKE_EXE_LINKER_FLAGS_DEBUG}> $<$<CONFIG:Release>:${CMAKE_EXE_LINKER_FLAGS_RELEASE}>")
	set(EFFECTS11_DEBUG_POSTFIX d)
	set(WIN_DISABLE_PROJECT_FLAGS ON)

You'll want to strip from CMAKE_CXX_FLAGS_DEBUG

[mkreisl]

Sorry, something wrong finding the files:

-- EXIV2_URL: https://mirrors.kodi.tv/build-deps/sources/exiv2-0.28.2.tar.gz
CMake Error at /usr/share/cmake-3.25/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find Exiv2 (missing: EXIV2_LIBRARY) (found version "0.27.6")
Call Stack (most recent call first):
  /usr/share/cmake-3.25/Modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE)
  cmake/modules/FindExiv2.cmake:104 (find_package_handle_standard_args)
  cmake/scripts/common/Macros.cmake:390 (find_package)
  cmake/scripts/common/Macros.cmake:404 (find_package_with_ver)
  CMakeLists.txt:269 (core_require_dep)

dev package(s) are installed:

dpkg -l | grep exiv
ii  libexiv2-27:arm64                     0.27.6-1                            arm64        EXIF/IPTC/XMP metadata manipulation library
ii  libexiv2-27:armhf                     0.27.6-1                            armhf        EXIF/IPTC/XMP metadata manipulation library
ii  libexiv2-dev:arm64                    0.27.6-1                            arm64        EXIF/IPTC/XMP metadata manipulation library - development files
ii  libexiv2-dev:armhf                    0.27.6-1                            armhf        EXIF/IPTC/XMP metadata manipulation library - development files

[enen92]

@mkreisl version 0.28.2 is required (you seem to have 0.27.6):
https://github.com/xbmc/xbmc/blob/master/tools/depends/target/exiv2/EXIV2-VERSION#L2

[mkreisl]

WTF, that's what Debian Bookworm has

The 0.28 version is not even available in Sid. I don't think that makes sense

Edit:
It now works with the self-built version from the depends path.
Not great but for the moment it's fine

Thanks

[enen92]

I was about to recommend to use ENABLE_INTERNAL_EXIV2.

[mkreisl]

I was about to recommend to use ENABLE_INTERNAL_EXIV2.

Ah yes, I somehow lost sight of that, would be a cool option if the external version doesn't meet the requirements to build the internal one. But anyway. the way it was solved here now works for me too.