# Setting Date/Time on digitized slides in LR



## dpirazzi (Oct 27, 2019)

I just started digitizing slides using my camera tethered to my computer and lightroom classic. I would like to find an easy way to set the capture date/time for the images in LR.

All I know for sure is the month and year the slides were processed (date stamped on the slide mount). Often, I don't even know the order they were shot, since back then I would routinely switch film mid roll in camera bodies (to switch film speed, boy I love digital).

How are others assigning capture date/time to digitized images in LR? Or maybe it is not worth the effort?  Assuming I can put the images in rough order within Lightroom, is there an easy way batch process sequential capture date/time changes?

thx, Dave


----------



## Paul McFarlane (Oct 27, 2019)

Dave

I have tended to scan in a batch that I know are around the same time, then set the date/time for the batch based on what info I know. At least then they show in the right date sequence and can be found that way.

Page 125 in your Classic book explains _Edit Capture Time_


----------



## johnbeardy (Oct 27, 2019)

I use my Capture Time to Exif plugin which writes the time and other information like the camera into the file.  One then reads the metadata into LR.

John


----------



## Linwood Ferguson (Oct 27, 2019)

I've been setting whole groups to one date/time, but this does remind me that I hate that as the order comes out all wrong whenever things are sorted by capture date (which I often do, including on the web).  This might inspire me a bit to search for a simple way to do something like add one minute to each in the order I arrange them, but I suspect that's not going to be simple as it needs to tie to the catalog (and I'm not a plugin author). 

Hint... hint... any plugin authors out there?


----------



## dpirazzi (Oct 27, 2019)

Thanks for the replies, I did look into the Edit Capture Time function within lightroom, particularly the ability to specify a date and have all the other selected photos adjusted by the same amount. This will work for most of my scanning where the slides were digitized in the order taken. And going forward I will be sure to put them in order prior to digitizing. Fortunately I just started this journey. 

But for projects already scanned out of order, I was hoping to be able to order them in LR and then adjust the capture time of the first image and have all the other selected images adjusted by a set increment. For instance, I have about 300 slides from a 1994 trip to Isle Royale which were not scanned in order. I have ordered them in their LR folder but the capture times are all still incorrect.

John, I will look into your plug in. The files are currently ARW (sony raw) but I could convert to another supported format (not crazy about sidecar files). Does it have the ability to write capture date/time to groups of files with a set increment, or is it one file at a time?

thx, Dave


----------



## johnbeardy (Oct 27, 2019)

dpirazzi said:


> John, I will look into your plug in. The files are currently ARW (sony raw) but I could convert to another supported format (not crazy about sidecar files). Does it have the ability to write capture date/time to groups of files with a set increment, or is it one file at a time?


There is an increment, Dave, for batch writing. I think it's just a second, but this means you can introduce a frame order. It will write directly into raw files too, though the default is sidecar files, and you can use it to change the make and model to whatever you were using when the film was originally shot.


----------



## PhilBurton (Oct 27, 2019)

Ferguson said:


> I've been setting whole groups to one date/time, but this does remind me that I hate that as the order comes out all wrong whenever things are sorted by capture date (which I often do, including on the web).  This might inspire me a bit to search for a simple way to do something like add one minute to each in the order I arrange them, but I suspect that's not going to be simple as it needs to tie to the catalog (and I'm not a plugin author).
> 
> Hint... hint... any plugin authors out there?


The elephant in this room is that we may know only the month or even only the year of a particular scanned image.  Or maybe just a range of years.  The last time I looked at the definition for the date field, there were no settings to allow for anything other than day, month, year.  I have looked but I haven't found any standard that is recognized by Lightroom or Windows for such imprecise dates.

Phil


----------



## Linwood Ferguson (Oct 27, 2019)

I would say that's what the captions (or other metadata fields) are for.

I'm struggling in many cases to figure out the year, and really coming to appreciate digital metadata.

And don't get me started on "who are those people?"


----------



## PhilBurton (Oct 28, 2019)

Ferguson said:


> I would say that's what the captions (or other metadata fields) are for.
> 
> I'm struggling in many cases to figure out the year, and really coming to appreciate digital metadata.
> 
> And don't get me started on "who are those people?"


True enough about metadata, and I'm sure that works as a workaround, but it's clunky because it means that there are now two, not just one way to do a search involving dates.

I too really appreciate metadata.  As soon as I got my Nikon D3, I went out and bought a GPS so that all my (outdoor) photos are geo-encoded.  For me, that increase in functionalty over film was HUGE.  No more scrambling around with maps or looking for nearby street signs. As with a date-stamp, theoretically  you could incorporate geo location into film, but then there is the minor problem of reading this data it is put into the space between negatives or slides.


----------



## Victoria Bampton (Oct 28, 2019)

PhilBurton said:


> The elephant in this room is that we may know only the month or even only the year of a particular scanned image.


in those scenarios, I use first minute of the hour, hour of the day, day of the month, month of the year, year of the decade. That gives me a clue that it’s a fuzzy date but still sorts roughly in date order.


----------



## Linwood Ferguson (Oct 28, 2019)

On thing to add to the prior reply - while I like metadata a lot, the other tools you have are collections and folders. I was looking back through some of my folder names, and noticed I had put things like "1978 sometime" or "1980 October maybe" as a way to document vagueness.

I also have one labeled "needs year" that I dumped stuff in I had no clue about hoping for inspiration.


----------



## dpirazzi (Oct 28, 2019)

Thanks again for the replies. 

John, I tried your plugin on some jpegs and on an ARW file, it updated the Date, Date Original and Date Digitized fields nicely (as viewed in LR). I also selected the "Update created and modified time" for Finder/Explorer Dates, but Explorer still shows the original date/time. Is that some of the functionality that is only available after unlocking the plugin?


----------



## PhilBurton (Oct 29, 2019)

Victoria Bampton said:


> in those scenarios, I use first minute of the hour, hour of the day, day of the month, month of the year, year of the decade. That gives me a clue that it’s a fuzzy date but still sorts roughly in date order.


I thought I might use something similar, but only if I could communicate that approach to any future users of my Lightroom catalog.


----------



## Paul McFarlane (Oct 29, 2019)

PhilBurton said:


> I thought I might use something similar, but only if I could communicate that approach to any future users of my Lightroom catalog.


Maybe a comment in one of the metadata fields would be an idea.


----------



## PhilBurton (Oct 29, 2019)

Paul McFarlane said:


> Maybe a comment in one of the metadata fields would be an idea.


True, but that works ONLY if that future user actually looks at the additional metadata fields.  The short answer is that the date/time field definition did not consider "fuzzy dates."


----------



## camner (Jul 10, 2021)

I'm having trouble using Capture Time to EXIF to change the Date/Time Digitized field.
Here's a screenshot of what I've entered into the plugin as a test:

Per the instructions, after running this via the plugin, I've loaded the metadata into LR from the file.  I've also checked the file in Adobe Bridge, and both LR and Adobe Bridge still show the Date/Time Digitized as the original (where it is equal to Date/Time Original). 

This seems straightforward enough, but I'm obviously missing something, since the Date/Time Digitized field doesn't change.


----------



## camner (Jul 10, 2021)

After hours of additional experimenting, I think I have resolved the issue...

I had set Capture Time to EXIF to use the plugin's version of ExifTool.  I changed that so that the plugin uses the version of ExifTool I installed on my iMac, and then following exactly the same steps as I did before, LR (and Bridge) show the Date/Time Digitized field as updated.

This suggests to me that for some reason, the plugin's ExifTool command was not "taking."  John Beardsworth mentions on his site that this could be due to a permissions issue, and suggests that the plugin be installed somewhere in the file system tree under Dropbox (assuming one is a Dropbox user...).  But that is exactly where the plugin is installed, so I'm not sure what the issue is.

[FWIW, I'm running MacOS Big Sur 11.4]


----------



## johnbeardy (Jul 10, 2021)

The problem is that Apple is blocking the plugin's Exiftool component and you'd see this if you tried running the command line (see troubleshooting FAQ). So you need to install Exiftool separately and tell the plugin to use it. This was shown on the plugin's How to Use page:






However, I appreciate that this area is too tricky for most people, and I have been changing my Exiftool-based plugins (and the documentation) to make it clearer that on Mac you should install Exiftool separately.  So I've just "officially" released 2.0 which adds some major changes to  the layout .


----------



## johnrellis (Jul 10, 2021)

My plugins include a number of executables (Exiftool, Imagemagick, custom C programs). Here's the code the plugins use to unquarrantine (unblock) them:


```
--[[----------------------------------------------------------------------------
public boolean unquarantinePlugin ()

On Mac, if the file "_quarantined" exists in the current plugin's folder,
removes the "com.apple.quarantine" extended attribute from all files in the
folder and removes the "_quarantined" file. Returns true if successful.
Returns false if there's any sort of error, displaying an error message to the
user, and leaving the "_quarantined" file in place.

On Windows, always returns true.
------------------------------------------------------------------------------]]

function Util.unquarantinePlugin ()
    if WIN_ENV then return true end

    local path = child (_PLUGIN.path, "_quarantined")
    if not LrFileUtils.exists (path) then return true end

    local code, err = Util.safeExecute (
        "xattr -r -d com.apple.quarantine '" .. _PLUGIN.path .. "'", true)
    if code ~= 0 then
        Debug.logn ("xattr: ", code, err)
        LrDialogs.message ("Problem unquarantining the plugin after download",
            "See 'debug.log' for details. The plugin may not run correctly " ..
                " -- contact support via the Help page")
        return false
        end

    LrFileUtils.delete (path)
    return true
    end
```


----------



## johnbeardy (Jul 11, 2021)

Thanks for sharing that, John. How long have you been using this for? It's an approach I've never tried as I assume Apple would be smart enough to prevent it!


----------



## johnrellis (Jul 11, 2021)

I have four plugins using that since Mac OS 10.15 (fall 2019), when Apple introduced the stricter quarantining.  The plugins use Imagemagick, two custom C programs, and a modified version of "sqlite3". I found the technique mentioned in several forums (don't remember which).  

But looking now at my plugins, the two that just use Exiftool (e.g. Any Filter) don't do unquarantining, so I wonder why Capture Time To Exif would need to do it.  The Mac version of Exiftool doesn't have any binary executables -- it just invokes the Perl interpreter pre-installed on Mac OS.


----------



## johnbeardy (Jul 12, 2021)

I've had plenty of people hitting this problem with each of my plugins which uses Exiftool (Capture Time To Exif, X-LR, and Video Metadata). I suspect that one factor is allowing the browser to save the plugin, rather than downloading the zip file and unzipping it with Finder. Another may be where the user stores the plugin. But obviously I'd prefer not to require a separate Exiftool installation, easy though it is.


----------



## johnrellis (Jul 12, 2021)

I wonder what the difference is -- over hundreds of installs, I haven't received any reports of problems with Exiftool.  But I've never really tried to grok Apple's ever-changing security architecture.


----------



## johnbeardy (Jul 12, 2021)

This was a recent example from someone on MacOS 11.0.1 who copied the command line from the plugin and tested it in Terminal:

```
"/Users/abc/Apps/Capture Time to EXIF/jbcapturetimetoexif.lrplugin/exiftool" -AllDates="2020:11:12 07:00:01" "/Users/abc/Desktop/Test/Test-003.jpg" -preserve -overwrite_original -X -m -k
-bash: /Users/abc/Apps/Capture Time to EXIF/jbcapturetimetoexif.lrplugin/exiftool: Permission denied
```

Also this year, on 10.15.7, I wonder what you make of this:

```
Poking around on the internet, I found a suggestion to put “perl” in front of the command line, and that worked:
[QUOTE]
JMBP-2:Desktop john$ perl "/Users/john/Pictures/Blue-2TB/LR Plugins/jbcapturetimetoexif.lrplugin/exiftool" -CreateDate="2013:11:02 15:54:01"     "/Users/john/Documents/Photography/Businsess Card v1-Edit.tif" -overwrite_original_in_place -X -m -k
    1 image files updated
[/QUOTE]
```


----------



## johnrellis (Jul 13, 2021)

Hmm, I did an little testing, and "Permission denied" indicates that "exiftool" doesn't have the execute permission.  In contrast, when you download an executable, it will have the com.apple.quarantine extended attribute, and when you try to execute it from the command line, you'll get a popup dialog:





Finder normally preserves file permissions when you unzip a folder. I just downloaded the current Capture Time To Exif and unzipped it, and "exiftool" was missing execute permission:

```
$ ls -l jbcapturetimetoexif.lrplugin/exiftool
[email protected] 1 john  staff  295684 Feb 13  2020 jbcapturetimetoexif.lrplugin/exiftool
```
 which suggests that it's getting zipped without it being set?


----------



## dpirazzi (Oct 27, 2019)

I just started digitizing slides using my camera tethered to my computer and lightroom classic. I would like to find an easy way to set the capture date/time for the images in LR.

All I know for sure is the month and year the slides were processed (date stamped on the slide mount). Often, I don't even know the order they were shot, since back then I would routinely switch film mid roll in camera bodies (to switch film speed, boy I love digital).

How are others assigning capture date/time to digitized images in LR? Or maybe it is not worth the effort?  Assuming I can put the images in rough order within Lightroom, is there an easy way batch process sequential capture date/time changes?

thx, Dave


----------



## johnbeardy (Jul 14, 2021)

johnrellis said:


> which suggests that it's getting zipped without it being set?


Possibly, as I finalize plugins and zip them on my main PC. _If_ this is the explanation, I could conceivably switch to my Mac and apply those execute permissions before zipping, but I do wonder if there's more than one factor. I've just replaced my Mac laptop and can test ideas on Big Sur, but for now the separate installation does seem a dependable solution.


----------



## johnbeardy (Jul 15, 2021)

johnbeardy said:


> Also this year, on 10.15.7, I wonder what you make of this:
> 
> ```
> Poking around on the internet, I found a suggestion to put “perl” in front of the command line, and that worked:
> ...



I followed up this suggestion on a brand new Mac and got interesting results. I ran the same command string twice but added "perl" in one case, and this was sufficient to get the plugin's Exiftool to run correctly:


----------



## johnrellis (Jul 15, 2021)

johnbeardy said:


> ran the same command string twice but added "perl" in one case, and this was sufficient to get the plugin's Exiftool to run correctly:


That's consistent with the file "exiftool" not have the execute permission set.   In general, the shell will only execute files (executables and scripts) that have execute permission.  When "exiftool" is the first word on the command line, the shell refuses to execute that file, since it doesn't have execute permission. But when you put "perl" as the first word, the shell willingly executes "perl" (which has execute permission).   "perl" doesn't require the perl scripts passed on its command line to have execute permission.   

Doing "chmod +x exiftool" in the directory containing it should then lot both versions of the command line run without error.


----------

