EXIF broken in recent 4.5.0

[jsmucr]

Describe the bug

Recent Darktable builds no longer recognize most of EXIF metadata. I've tried with my Lumix G9 RW2 files (as well as with the same files converted to DNG and SOOC JPEGs) and Nikon D5300 NEF files.

Steps to reproduce

1. Build DT 4.5.0+970~g84c55f84cf for Windows following this manual: https://github.com/darktable-org/darktable/blob/master/packaging/windows/README.md
2. Run it, and import an image.
3. See that there's hardly any metadata available in the image information module. Also vertically taken images aren't automatically rotated and noise profiles are missing from the denoise module.

Expected behavior

EXIF data should be visible and leveraged by Darktable

Logfile | Screenshot | Screencast

No response

Commit

No response

Where did you install darktable from?

self compiled

darktable version

4.5.0+970~g84c55f84cf

What OS are you using?

Windows

What is the version of your OS?

Windows 10 Pro 22H2

Describe your system?

Intel Core i5-3570k 8 GB RAM NVIDIA GeForce GTX 1070 12 GB

Are you using OpenCL GPU in darktable?

Yes

If yes, what is the GPU card and driver?

No response

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

• I believe it didn't work in f3deba711d either, but I don't build every commit, and I have two different machines with individual builds.
• Reproducible with a fresh database.

[MStraeten]

which exiv2 library are you using? Maybe you need to downgrade to 0.27.7… maybe similar to this upstream issue https://github.com/Exiv2/exiv2/issues/2746

[jsmucr]

which exiv2 library are you using? Maybe you need to downgrade to 0.27.7… maybe similar to this upstream issue Exiv2/exiv2#2746

I was building it with 0.28.0. Pacman in MinGW doesn't allow for downgrades, and exiv2 MinGW install target is broken as it tries to copy binaries into C:\Program Files (x86)\exiv2. So now I'm doomed.

EDIT: So I've managed to get my hands on the old package and install it via pacman. So I'll build DT again and get back here with the result.

[kmilos]

Can't reproduce here, just built 4.5.0+980~g99e1d8c3ba on a fully up to date MSYS2 UCRT64 w/ mingw-w64-ucrt-x86_64-exiv2 0.28.0-2

Do you perhaps have non-ASCII characters in your filenames/paths?

[jsmucr]

Do you perhaps have non-ASCII characters in your filenames/paths?

Yes, I do.

Build 4.5.0+980~g99e1d8c3ba with mingw-w64-ucrt-x86_64-exiv2-0.27.7-1 works fine (after reimporting the files of course).

[kmilos]

Yes, I do.

Then this is most likely related to https://github.com/Exiv2/exiv2/issues/2637 instead.

Please confirm it works w/ 0.28.0 and ASCII-only paths.

Build 4.5.0+980~g99e1d8c3ba with mingw-w64-ucrt-x86_64-exiv2-0.27.7-1 works fine

FYI @wpferguson

[jsmucr]

Correct. This very DT version with exiv2 0.28.0 behaves as expected with ASCII-only paths.

[wpferguson]

@kmilos I'm sitting on 0.27.7-1

Thanks

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[victoryforce]

Build 4.5.0+980~g99e1d8c3ba with mingw-w64-ucrt-x86_64-exiv2-0.27.7-1 works fine

Since the release was built with this still unbroken version of exiv2, I think this issue can be closed.

[jsmucr]

Since the release was built with this still unbroken version of exiv2, I think this issue can be closed.

People should be aware that it's still something to deal with when building from source. Or has it been added to the docs already?

[victoryforce]

This issue was referenced from PR, which suggests one way to solve the problem. If this PR will be accepted (it probably will eventually), or if the exiv2 guys change their mind about removing the wstring API (which I hope so, because it was just a sabotage), then no changes to the instructions for building darktable will be necessary.

In fact, there is no need for users to build darktable for Windows themselves, as there are both official release builds and nightly git snapshot builds. And if they do, an open issue on the n-th page among 4 hundred open issues will in no way help those who build darktable on their own. It's hard to imagine someone reading all these issues to learn how to properly build darktable.

That's why I don't see any reasonable need to keep this issue open.

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[victoryforce]

Since the release was built with this still unbroken version of exiv2, I think this issue can be closed.

People should be aware that it's still something to deal with when building from source. Or has it been added to the docs already?

There is already a PR which, when accepted, will fix this problem in the darktable. Sooner or later we'll probably have to go that route unless exiv2 rolls back their change that breaks the current darktable. Therefore, I see no value in keeping this issue open.