Hello,
I don’t know if this has already been discussed but when I try to use the $(MAKER) or $(MODEL) variables when importing from an SD card, this information is returned blank in the filename.
Dates work fine, nested folders work fine too.
For example, the filename I would like to implement is $(MODEL)-$(EXIF_YEAR)-$(EXIF_MONTH)-$(EXIF_DAY)-$(EXIF_HOUR)h$(EXIF_MINUTE)min$(EXIF_SECOND)s.$(FILE_EXTENSION)
but the resulting filename starts with a hyphen, eg : -2022-03-04-10h23min32s.raf
Yes, good idea … but no ! $(MODEL) is recognised because it comes out blank $(EXIF_MODEL) is not recognised because the file name starts with $(EXIF_MODEL)
Yes, using dk 3.9 at the moment but didn’t work in 3.8 either.
It doesn’t work with fuji Raf, canon cr3 or Olympus orf
I don’t have a problematic file, they all are.
I am on Mac.
I’m on a recent build of Windows…I don’t use this feature but I seem to see what you see. If I toggle keep original file name off and then add $(model)_ to the start of the renaming string my imported images would start with _ and no model info…
Probably some of us read this section (at least I did) and it mentions using these for export so assumed import would also access them…It seems perhaps something that could be reviewed and perhaps making wider access to variables… https://docs.darktable.org/usermanual/3.8/en/special-topics/variables/
You are right obviously, but the code is not organized to provide a general answer here. We can add easily one variable, but why not another one … a bit of mess without a bit of refactoring …
Thanks for the reply. Like Todd, I hoped that variables were part of the ‘core’ of Darktable and could be accessed by all the modules, import and export included.
I hope this possibility will come one day, I still use photomechanic to import for this functionality.
I see nothing wrong with using several programs, each for its strong points. I think it even has several advantages, esp. in open source:
each group can concentrate on what they like doing, without worrying about “peripheral” issues that could be needed;
programs stay smaller, so easier to understand and debug;
upgrades come more regularly (unless all your programs are on a synchronised schedule), so less to learn at any time.
The down side is that using several programs can appear to be a bit clumsier. For me, the slight inconvenience of having to switch program is more than offset by the greater ease of use of each individual program.
All good by me…its might just be a bit misleading that the documentation for export goes to the main section on variables however input is not the same…having said that many of the variables in that larger list would not make sense for importing but lens maker model and a few others might… @nwinspeare perhaps scan the list and provide a short list and it could be submitted for consideration??
Here is a quick list of variables that could be useful on import :
All the date and time variables (but they are already working as I understand)
$(LONGITUDE) longitude
$(LATITUDE) latitude
$(ELEVATION) elevation
$(MAKER) camera maker
$(MODEL) camera model
$(LENS) lens
$(TITLE) title from metadata
$(DESCRIPTION) description from metadata
$(CREATOR) creator from metadata
$(PUBLISHER) publisher from metadata
Variables ( $(xxx) ) are contextual image information. They exist when the image itself exists in dt, which is not the case at import time. That’s why there are limitations.
Currently, at import time, Exif.Image.DateTimeOriginal is read from image file and it should be possible (with some rework) to get more of these Exif.Image information (before the image creation in dt).
So, in the above list, only Exif.Image.Make and Exif.Image.Model are generally available in the read file and could be pre-extracted.
