darktable-org
Exif data not recorded in the Windows version of darktable 5.3.0~...
Is there an existing issue for this?
- [x] I checked and did not find my issue in the already reported ones
Describe the bug
The exif data such as date image taken, aperture, iso and speed are not recorded (raf and corrresponding jpeg and dng) after importing from a local hard drive (no file copies).
Steps to reproduce
- Lighttable import/add to the library;
- Select files within a folder on a local hard drive;
- Import;
- Look at exif data from any image
- See snapshot, empty fields are displayed with weird values corresponding possibly to empty fields in the database.
Expected behavior
Register correctly the values such as date time taken, speed, iso, aperture, distance, lens and focal length...
Logfile | Screenshot | Screencast
No response
Commit
No response
Where did you obtain darktable from?
darktable.org / GitHub release
darktable version
5.3.0+946~ge8b378d586
What OS are you using?
Windows
What is the version of your OS?
Win 11 Pro
Describe your system
No response
Are you using OpenCL GPU in darktable?
Yes
If yes, what is the GPU card and driver?
Nvidia
Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip
No response
I can confirm the same with CR2 files from my Canon EOS 7D (Win 11, AMD GPU, DT 5.3.0+949~g610a60488b). Also, orientation (i.e. rotation) is not applied or read out with new imports. Upon closer inspection, only images taken on the 15th & 18th Nov. 2025 are affected, not those taken later. The XMP created right upon importing is also significantly shorter (with the first difference being the line exif:DateTimeOriginal="") Furthermore, for testing purposes, a clean re-import of the old dsc_8666.nef from this PlayRaw topic in discuss.pixls.us works perfectly, displaying all data. https://discuss.pixls.us/t/night-scene-at-the-bar/26405 My existing older imports & edits performed with a nightly build of about two weeks ago also still display everything correctly.
Confirmed on my side with DT 5.3.0+949~g610a60488b under Win 11, Nvidia GPU. However that same version behaves OK with Linux Mint (zara) using the AppImage. So I am tempted to conclude that this is a Windows issue (exiv2 version to check?).
Confirmed on my side with DT 5.3.0+949~g610a60488b under Win 11, Nvidia GPU. However that same version behaves OK with Linux Mint (zara) using the AppImage. So I am tempted to conclude that this is a Windows issue (exiv2 version to check?).
Your conclusion is absolutely correct. Yes, the cause of this problem is that the current darktable code for Windows is incompatible with the exiv2 0.28.x releases. To work correctly on Windows, we have to build the program with exiv2 0.27.x and this is how the official installers for Windows are built (both release and nightly).
So if you are experiencing a problem with reading Exif metadata, the only cause can be that you are using an unofficial build of the program with an incompatible exiv2 version.
The version of exiv2 with which the program was built can be seen by running darktable from the command line with the --version option.
Well, it was downloaded from the official github center: https://github.com/darktable-org/darktable/releases/tag/nightly
Running from the cmd line gives:
Exiv2 -> 0.27.7
I did the same with the stable release 5.2.1 (which does record correctly the exif data), and it reported the same exiv2 version 0.27.7
So is there anything else to look at ?
Windows-specific bug corrected in version 5.3.0~957...! I close this issue.
Strangely, not solved in my case (with today's Win11 nightly build - 5.3.0+958~gbc1371a722)
Hi Neutralgray-eu,
It was fine in my case this morning with 958 on updating 957 in Windows 11, keeping the configuration files. So to verify this further, I did a fresh install of 958 after removing the App data darktable config folder as well as the program darktable-dev folder.
Under these conditions, I can reproduce your observation with my old cr2 files as well as my newest raf files. I reopen this issue and play a little bit with the configuration folder to find the culprit.
I tried again, now with the same config folder to which 5.2.1 and 5.3.0~958 are connected one after the other under Windows. It is clear that the former does import correctly the exif and the latter does not. Once images are imported with 5.2.1, the exif data are exact when the database is used by 5.3.0. The converse is not true, as expected. If so, one has to remove the images from the database and re-import them with 5.2.1 for the exif to be right. It is as if the import module compiled for windows differs from that under Linux in 5.3.0.....
Still not solved for nightly build 5.3.0+961~gf26491d2a9
running exiv2 version 0.27.7
Windows 11 Pro Version 25H2 OS build 26200.7171 Experience Windows Feature Experience Pack 1000.26100.265.0
Upon import and no sidecar is created all EXIF is empty:
Upon creation of a sidecar after edit the camera maker and model are recorded, but no other EXIF data:
Tested version 5.3.0~970 this morning after fresh install and darktable config folder re-created on install (no xmp sidecars in images folders). Two sets of raw images (raf) from the same fuji X100V were imported; DateImageTaken (DD/MM/YYYY format) was 07/11/2025 and, respectively, 28/11/2025. In Linux no problem, exif data were correctly reported with both sets of images. In Windows 11, exif data were correctly reported for the raw images taken on 07/11/2025 but not for those taken on 28/11/2025. Needless to say this is beyond my technical skills.
Tested this morning with the Windows version of 5.3.0~979...under Windows 11 25H2 26200.7309
One can predict how darktable will be able to read the exif by the way the thumbnails are displayed on import according to the date of the files were copied in the windows folder.
Cannot read the exif:
Can read the exif:
Importing directly from the SD card allows darktable to read the exif!
The Windows 11 version at date of import into the local hard disk did not influence the outcome according to my testing with older folders, of which one could not be imported correctly while others were OK.
"Importing directly from the SD card allows darktable to read the exif!"
My attempt in this direction: Instead of importing from my standard subfolder (external HDD), I copied the files in question to a test folder on my internal SSD, and the import worked flawlessly, with all data displayed.
Failed attempt: Removed (without deleting) the images from the library (both original & test folder), deleted original xmp, moved xmp files from test folder to original folder, reimported (drag'n'drop) with "functioning" xmps present: No data displayed.
Functioning workaround: Removed original images from the library, kept test images in library, copied new xmps to original folder, updated path to files (via right-click) in film roll view of the collections module in Lighttable, deleted test folder: All data displayed.
(Win11, 5.3.0+979~g76c392907e)
Win 11, dt 5.3.0+979~g76c392907e
I created a new database. Copy and imported from sd card:
no EXIF data appeared:
I made edits. No EXIF data appeared.
I tried with a new database to simply add to library. No EXIF data appeared.
The EXIF data is there since on copy and import when I use a renaming pattern to name the files as creation date and creation time, darktable successfully renames them, but will not show the correct creation date or creation time in the image information panel. Also, I know the information is there since every other tool I have to inspect image data show the EXIF information as being there:
put it on a file sharing service(google drive, dropbox, etc) and post the link
I believe I resolved my problem. The Job name I was using was '2017-06-08 montaña de oro'
As soon as I changed the 'ñ' to just 'n' and added the images to the library, the EXIF data showed up.
I confirm. All images within a (sub)folder whose name contains a weird (not for french-speaking or spanish-speaking persons obviously) special characters like éöäàüè& etc are not handled correctly by this version of darktable in Windows 11; is that a pagecode issue that may not be present in Linux? By simply renaming the folder using standard english characters solves this. It should be corrected however for people using special characters. I remove the link...
special characters like éöäàüè& etc are not handled correctly
This also concerns exporting: While my "workaround" above may allow exif data to be displayed correctly within DT, if you export the image (as JPG), the data will be missing again.
It looks like the bug is still present in the last 5.5.0 release under windows. Should I compile the program to make it compatible with my laptop?