Project

General

Profile

Feature #8415

camera import: using Exif-date

Added by Simon Spannagel almost 8 years ago. Updated about 2 years ago.

Status:
Fixed
Priority:
Low
Assignee:
-
Category:
Lighttable
Target version:
Start date:
Due date:
% Done:

100%

Affected Version:
git development version
System:
all
bitness:
64-bit
hardware architecture:
amd64/x86

Description

If dt offers to import from the camera, I'd like to be able to do it all with dt without using extra tools.

Especially the "import with the date of exposure" and not "import with import-date" seems to be important for me since I think most photographers remember their pictures combined with the event and not the time of import...

Maybe you wanna keep your current possibility - then I would suggest radio buttons with three options:

  • Use Exif-date of earliest photo to import
  • Use today's date
  • Overwrite date with: [...]

What about that?

photos-import (1.61 KB) Antoine Beaupré, 06/12/2015 09:41 PM


Related issues

Related to darktable - Bug #8916: Import Problem : Import only first with specifi filename structure Duplicate 09/08/2012
Duplicated by darktable - Bug #8305: Fix date override in camera import dialog Duplicate
Duplicated by darktable - Bug #8521: Cannot override date in camera import Duplicate
Duplicated by darktable - Bug #10260: Variable $(EXIF_YEAR) etc is not supported when importing from camera Fixed 01/02/2015

History

#1 Updated by Tobias Ellinghaus almost 8 years ago

I can see one problem: Before downloading images you have to create the directory they should reside in. But the name of that directory is dependant on the exif data in the image which isn't known until you downloaded the file.

This doesn't mean that it's impossible. We could create a temp folder, download to that folder, look for the date and move the images around.

#2 Updated by Simon Spannagel almost 8 years ago

Can't you use the capabilities of libghpoto2 to retrieve the date (same way as you get the preview thumbnail on each image, you could do that together...)

#3 Updated by tetaberta - over 7 years ago

In understand from this bug report, that using EXIF_MONTH, EXIF_DAY, EXIF_HOUR etc is not supported when specifying the name of imported files. However, before I found this ticket, I tried using these for importing in the format
$(EXIF_YEAR)$(EXIF_MONTH)$(EXIF_DAY)_$(EXIF_HOUR)$(EXIF_MINUTE)$(EXIF_SECOND).$(FILE_EXTENSION)
and darktable just replaced the with the time of import, which caused that that all images had the same name, got overwritten, and only the last one was really imported (if I understand it correctly).

I think, that these strings should be disabled if they do not work, and some warning may be given to the user (although it might be OK in the development version).

Another thing is, that darktable should in my opinion ask before overwriting other images during the import, but this has already been reported in Ticket #210.

#4 Updated by Simon Spannagel over 7 years ago

hih tetaberta,

in fact you understood this improvment request wrong.

Nowadays the import folder is always names as "$TODAY_$NAME" which is not the best choice if I import photographs from a shooting last week.

My request was to add a functionality that instead detects the exif date of the earliest photo to be imported and uses is as date for the folder:
"$(EXIF-OF-EARLIEST-PHOTO)_$NAME" would then be the foldername. A lot better in my opinion.

And even better if one could choose between both methods and maybe the third one that is implemented in the UI but has no functionality: direct input of your own customized date.

best regards,
Simon

#5 Updated by Richard Wonka over 6 years ago

seconded. The import day plays virtually no role in my workflow, but the exif date is vital.

A default of creating one folder per day (of taking) seems sensible from my point of view. (FWIW: This would also conform with what Shotwell does.)

#6 Updated by Simon Spannagel over 6 years ago

  • % Done changed from 0 to 20
  • Category set to Lighttable
  • Status changed from New to Triaged

Possible solution:
Copying to /tmp/ and then moving/changing inode pointer.

#7 Updated by Tobias Ellinghaus about 6 years ago

/tmp/ is a bad choice. Instead look at the path, find out if it contains an exif date/time and remove everything after the first occurence of that, including the exif date/time. That way you find the longest prefix that can be evaluated without downloading the image and the one with the highest chance that the file will be on the same partition. Once it got downloaded you have to get the exif data, complete the original storage location and check if a simple move would work (inode based). If yes: do it with virtually no costs, otherwise do an expensive copy&delete operation.

#8 Updated by Florian Demmer about 6 years ago

automatically choosing a location is a much worse choice.

please make it user configurable and default to something fixed, dont' make it unpredictable/hard to predict where data ends up at any time. in my case /tmp would be great, because it is actually a ramdrive (reduce writes on ssd) and my final storage is on a mounted cifs share. with a "guessed" directory somewhere on the network share there would be moving around files remotely. also a guess could lead to issues with write access in one of the higher up directories.

the only really reliable solution to getting data safely off a camera is, imho:

1. copy to a temporary location
2. check if the transfer was complete
3. get all the info you need for final location/renaming/tagging/whatever
4. move file there/tag/whatever
5. optionally delete from source

importing data off the camera is a critical step in the digital asset management chain, users absolutely need to be able to trust darktable not to screw this up.

thank you and hopefully we will soon see this feature planned for release and implemented.

#9 Updated by Tobias Ellinghaus about 6 years ago

Since none of the devs use this import feature (at least none that I am aware of) it will rather be removed completely than fixed. It's just messy.

#10 Updated by Christian iuga about 6 years ago

Hi,
Maybe we can get arround about this :
gphoto seem's to be able to get exif information via the command "show-exif" (see http://gphoto.org/doc/manual/ref-gphoto2-cli.html#cli-examples for more information)

#11 Updated by Tobias Ellinghaus about 6 years ago

gphoto2 can't get EXIF data for RAW files, only for JPEGs. It's the same as with thumbnails.

#12 Updated by Gonçalo Marrafa about 5 years ago

Hi guys.

I've been using Rapid Photo Downloader as my import tool. I don't know what strategy they use but it works great and i can easily include exif date info in my folder structure. Maybe you can have a look on how they do it. I'd really like to have DT as a complete end-to-end solution for photo management.

#13 Updated by Gonçalo Marrafa about 5 years ago

Ping!

Is this being worked on?

#14 Updated by Tobias Ellinghaus about 5 years ago

  • Priority changed from Medium to Low

No.

#15 Updated by Gonçalo Marrafa about 5 years ago

:( I think this is an essential feature in the photo management workflow... For me at least it forces me to use an external tool for this step.

#16 Updated by Tobias Ellinghaus about 5 years ago

Patches are welcome. I personally don't like to code that since it requires me to find an USB cable every time I work on it, attach the camera to the computer, take care of batteries and all this. It's all too inconvenient. Maybe some day …

#17 Updated by Gonçalo Marrafa about 5 years ago

My import "from camera" just means i insert my sdcard. I never attach my camera directly to the computer.

#18 Updated by Reto Omlin about 5 years ago

Take a look how shotwell manage this (don't know anymore if it's standard import setting or not). I think this is the way it should be.
Using import from shotwell for quite a long time now and i'm happy having all photos in their "shoot-date"-Folder

#19 Updated by Javier Fernandez almost 5 years ago

I agree with previous posters. The Exif date is essential.
How else can you import old pictures with proper dates? Imagine your summer holidays or long holidays, when you are back you want the pictures sorted according to the day when they were taken, not all according to the downloaded date.

#20 Updated by Jérémy Rosen over 4 years ago

  • Status changed from Triaged to Patch attached
  • % Done changed from 20 to 70

https://github.com/darktable-org/darktable/pull/350 implements this, but it needs testing/rebasing review

#21 Updated by Rudolf Martin about 4 years ago

It seems the task in github is closed without result.

I'm also interested in renaming picturefiles during import. Up to now I use "exiftool" to rename my pictures with EXIF-date before importing them in darktable.

Following variables would be helpful.

base directory naming pattern: $(PICTURES_FOLDER)/Darktable
sub directory naming pattern: $(YEAR)$(MONTH)$(DAY)_$(JOBCODE)
file naming pattern: $(YEAR)$(MONTH)$(DAY)_$(HOUR)$(MINUTE)$(SECOND)$(COPY).$(FILE_EXTENSION)

COPY should add a serial number with leading '-' if the file already exists, e.g. several pictures taken in the same time intervall.

#22 Updated by Rudolf Martin about 4 years ago

Exiftool can rename picture files according to their creation date. It can also move or copy image files into folders by year and month and day. You can also choose upper or lower case for the extension.

Is it possible to involve exiftool in the importing process of dt?

There can occur a problem with filmrolls. If the pictures are copied to different folders according to the creation date, should there be also different filmrolls?

#23 Updated by Antoine Beaupré about 4 years ago

Rudolf Martin wrote:

It seems the task in github is closed without result.

i have reopened a separate PR after rebasing this properly here:

https://github.com/darktable-org/darktable/pull/675

testing would be welcome, i didn't test this myself.

I'm also interested in renaming picturefiles during import. Up to now I use "exiftool" to rename my pictures with EXIF-date before importing them in darktable.

i'd be curious to hear more about your workflow: what commands are you running exactly?

#24 Updated by Rudolf Martin about 4 years ago

i'd be curious to hear more about your workflow: what commands are you running exactly?

First I copy the images manualy from the sd-card to directories naming "year-month", e.g. "2014-09".
Then I start a custom action within thunar, but you can start the bashscript in a terminal also. I use exiftool only to rename picturefiles within one directory, although it can move files to new directories naming with date from exifdata. You can also enable subdirectories, if needed.
Exiftool works with JPG- and RAW-files, opposite to jhead which only affects JPG-files.

#!/bin/bash
# actions refers to all files in a directory
# Rename all images in dir with date+time of exif data
# subdirectories are not affected
# first paramter = directory name

exiftool '-FileModifyDate<DateTimeOriginal' '-FileName<DateTimeOriginal' -P -d %Y%m%d_%H%M%S%%lc.%%le "$1" 

#25 Updated by Christian iuga about 4 years ago

Antoine Beaupré wrote:

Rudolf Martin wrote:

It seems the task in github is closed without result.

i have reopened a separate PR after rebasing this properly here:

https://github.com/darktable-org/darktable/pull/675

testing would be welcome, i didn't test this myself.

I'm also interested in renaming picturefiles during import. Up to now I use "exiftool" to rename my pictures with EXIF-date before importing them in darktable.

i'd be curious to hear more about your workflow: what commands are you running exactly?

Hi,

The main problem was :
gphoto2 is not to be able to get EXIF data for Raw file (at least for the 2.4 version)
I have contacted gphoto2 mailinglist at 12 octobre 2012 and Marcus Meissner <> repond me :

It might not be able to do so, but perhaps we can implement it if not yet possible.
There is no general technical limit.

But i never got a answer

http://sourceforge.net/p/gphoto/mailman/gphoto-user/thread/1367825655.1542.3.camel@roumano/

If you want, you can try to contact gphoto maintener about it.

#26 Updated by Jake Probst almost 4 years ago

Christian iuga wrote:

The main problem was :
gphoto2 is not to be able to get EXIF data for Raw file (at least for the 2.4 version)

Getting exif data out of raw files was NEVER the issue. The patch would use gphoto to get the file, then use darktable's own exif parsing to get the information. The issue was that darktable's exif reading could not handle the jpegs. I never could quite figure out why and it was completely out of my use case so I never really put much effort into fixing it (I mean, if you`re using darktable you`re probably going to be shooting in raw anyway?).

I do have some time/desire to get this patch working again so I`ll probably have something working in a week or two.

#27 Updated by Peter Maffter almost 4 years ago

  • Target version changed from Future to Candidate for next major release

Hello,

"import with the date of exposure" is an important feature.

If exif data is:
Create Date : 2014:11:28 21:42:42.33
then I'd expect the possibility to put this into the filename and/or use it as modification date of the
imported photo.

I did not find that in darktable-1.6.0 .
Therefore I currently have to use digiKam for importing photos from the camera (which imports with 1hr offset which can be corrected).
Also digiKam keeps a record which photos have been imported, I am currently missing that in darktable (is there someting like that?).

I also tried rapid-photo-downloader-0.4.10 which only has some experimental feature of importing photos from camera, which never worked.

So the all-in-one solution is still missing.
Can you do that? ;-)

Thx in advance

#28 Updated by Tobias Ellinghaus almost 4 years ago

  • bitness set to 64-bit
  • Affected Version set to git development version
  • System set to all
  • Target version changed from Candidate for next major release to Future

#29 Updated by Antoine Beaupré over 3 years ago

here's my homegrown script... it uses exiftool to import the pictures, then throws git-annex in to track them properly, which allows me in turn to figure out which directories were actually created, and then opens up that stuff in darktable...0

#30 Updated by Roman Lebedev over 3 years ago

  • Duplicated by Bug #10260: Variable $(EXIF_YEAR) etc is not supported when importing from camera added

#31 Updated by Tobias Ellinghaus about 2 years ago

  • % Done changed from 70 to 100
  • Status changed from Patch attached to Fixed

So ... the PR got finally cleaned up and merged. It will be in 2.2.0.

#32 Updated by Roman Lebedev about 2 years ago

  • Target version changed from Future to 2.2.0

Also available in: Atom PDF