Possible bug with sub directory naming pattern during import (EXIF DATA)

[gid000]

Describe the bug

Hi all,

Before importing around 5k images today, I noticed something strange. Not sure if is a bug or not, and I would like to double check with you guys.

Here are are my current settings:

base directory name pattern: $(PICTURES_FOLDER)/Darktable
sub directory name pattern: $(YEAR)$(MONTH)
file name pattern: $(YEAR)$(MONTH)$(DAY)_$(SEQUENCE).$(FILE_EXTENSION)

And here an example of a file I found after import:

Darktable/202312/20171010_211335.jpg

The only folder created was 202312, even if a 2017 file was found (as show above). Based on my settings, I was expecting another folder called "201710" to accommodate those files. Then I noticed in darktable documentation there is a difference between $(YEAR) and $(EXIF_YEAR). I will change my settings to use EXIF_YEAR, however I find confusing the mismatch between the folder and file. Did I missed something?

Steps to reproduce

1. Configure the settings above;
2. try to import a lot of photos.
3. find for inconsistency under the output folder

Expected behavior

no inconsistency

Logfile | Screenshot | Screencast

No response

Commit

No response

Where did you obtain darktable from?

downloaded from www.darktable.org

darktable version

4.5.0+445.g0fcf57c4fe

What OS are you using?

Linux

What is the version of your OS?

Fedora 38

Describe your system?

It is an appimage:

./Darktable-4.5.0+445.g0fcf57c4fe-x86_64.AppImage

Are you using OpenCL GPU in darktable?

None

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

No response

[gi-man]

The folder is using today date (date of import). I think the filename is using the date of export from the jpg metadata.

[gid000]

@gi-man yes,. I noticed that. But since they are both using $(YEAR)$(MONTH) shouldn't we expect something like Darktable/202312/20231228_211335.jpg instead of Darktable/202312/20171010_211335.jpg ?

[gi-man]

If you do exiv2 or exiftool on the jpg, it likely has an export date of 2017.10.10

[gid000]

@gi-man I don't think exif will store the export date. $(YEAR)$(MONTH)$(DAY) it seems to be extracted from the current day the file was imported. Do you know any way to get this information from the exif?

File name       : 20171010_211335.jpg
File size       : 1817566 Bytes
MIME type       : image/jpeg
Image size      : 4032 x 2268
Thumbnail       : image/jpeg, 13176 Bytes
Camera make     : samsung
Camera model    : SM-G950F
Image timestamp : 2017:10:10 21:13:35
File number     : 
Exposure time   : 1/10 s
Aperture        : F1.7
Exposure bias   : 0 EV
Flash           : No flash
Flash bias      : 
Focal length    : 4.2 mm
Subject distance: 
ISO speed       : 250
Exposure mode   : Auto
Metering mode   : Multi-segment
Macro mode      : 
Image quality   : 
White balance   : Auto
Copyright       : 
Exif comment    : 

Please, note that the export date folder it was set to today: 202312. The filename was set from the exif timestamp.

[gi-man]

Dt uses exiv2, so ideally use that to evaluate your jpg. There are likely multiple date fields (icpt, xmp, exit,... Date taken, date capture, date ...)

But look at the image timestamp in the info you posted: 2017:10:10.

[zisoft]

The thing is that using the same variable $(YEAR) twice it should give the same result in both cases.

[zisoft]

According to the variables documentation $(YEAR), $(MONTH), $(DAY) are substituted by the date of the import, thats why you get the folder 202312 which is correct.

To get the folder structure based on the image datetime you need to use $(EXIF.YEAR), $(EXIF.MONTH) and $(EXIF.DAY).

file name pattern: $(YEAR)$(MONTH)$(DAY)_$(SEQUENCE).$(FILE_EXTENSION)

Darktable/202312/20171010_211335.jpg

There is no sequence in the resulting filename, instead it is the filename of the original file without substitution so something other is strange.

[gid000]

There is no sequence in the resulting filename, instead it is the filename of the original file without substitution so something other is strange.

Thank you @zisoft,

I assumed _211335 would be the sequence. That makes sense, and I just double checked, indeed this filename was the original file. Good catch!

If exiv2 shows the timestamp properly, why the filename wasn't renamed during the import? Something is still odd to me.

[gi-man]

Share the jpg and I can look at it in more detail in a few hours.

[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.