- LR 6.2 is out so you can update your LR.
- Can you also let us know once files are imported, are the files still out of order, sort order being selected as capture time.
Many people have run into this issue. It sounds like your camera is not recording the sub-second capture times in the EXIF metadata (a number don't). I suggest you verify that -- upload a sample pic to Dropbox (or similar) and we'll take a look at it.
Assuming it isn't recording the sub-second capture time: LR has a couple of issues here. It doesn't assign sequence numbers in the order that pics appear on the camera card, and Library Sort: Capture Time doesn't sort secondarily by filename when the capture dates of two pics are identical.
You can work around the problem by maintaining the original filenames on import and sorting in Library by filename. Or you can use Original File Number in your renaming template and then sort by filename.
Interesting. That would make sense, but, I would be surprised if my Nikon D3 didn't support sub-second times.
I just used 'exiftool' to look at the .JPG files, and I see this:
Create Date : 2015:10:02 08:48:04.73
Modify Date : 2015:10:02 08:48:04.73
This would lead me to believe that it supports sub-second storing in the JPG file.
I'll keep digging and see what else I find.
I tried to put a couple of images into a spreadsheet to help describe this issue. Images ending in 644 and 645 where shot in separate seconds, but 646, 647, and 648 are all shot in the same second, but LR reverse orders them (Date: Capture Time) even though the exif data for each one shows their sub second data (included in the spreadsheet).
Here is the link: http://jinx.jinxed.net/~jaypike/20151006-LRCC-Example.xlsx
Unfortunately, Excel converted the inserted pics from their original format to PNGs, and the Exiftool listing you provided doesn't give all the low-level details needed to troubleshoot. Can you upload the original pics to Dropbox or similar?
This issue has been reported intermittently over a number of years and I've never been able to track it down. By having a reproducible test case, we can file an actionable bug report with Adobe and possibly find a suitable workaround.
I'm guessing the low level details you were looking for from the Exif data might have been in rows 402 and 403 of the excel spreadsheet.
That said, I've exported the 5 images as a LRCC catalog and created a zip file with the images and the catalog for you to download and hopefully reproduce.
The files can be found here: http://jinx.jinxed.net/~jaypike/test.zip
Thanks, uploading the files helped. (I needed to see the sources of the individual fields -- EXIF, IPTC, XMP -- and I suspected a very low-level EXIF formatting problem which didn't in fact exist.)
I spent quite a while investigating this, and here's what I've learned:
- The sample Nikon D3 files you provided are missing the fractional seconds of the capture time. The year/month/day/hour/minutes/seconds are stored in EXIF:DateTimeOriginal, as expected. The fractional seconds should be stored in EXIF:SubSecTimeOriginal, but the files are missing that field. They do, however, contain EXIF:SubSecTime (fractional seconds of when the file was last modified by software), and EXIF:SubSecTimeDigitized (the fractional seconds of when the file was recorded digitally). This is a bug in the D3 firmware -- the developer probably confused EXIF:SubSecTime and EXIF:SubSecTimeOriginal. I happen to have had some files taken with a D4, and they correctly record the fractional seconds. You might see if the most recent firmware update for the D3 fixes the problem.
- When properly recorded in the metadata, LR will display the fractional seconds in the Date Created field of the IPTC Metadata panel tagset. But it won't display them in the Capture Time or Date Time Original fields of the Metadata panel.
- When properly recorded in the metadata, LR will use the fractional seconds when sorting images by Capture Time in Library mode. At least it does with the test cases I've seen so far.
So if the firmware update for the D3 doesn't fix the issue, I think you'll need to retain the original filenames or use the Original File Number in your renaming template. (The sorting will fail for a burst of photos in which the numbering has rolled over from 9999 to 0.)
Looking at the EXIF data, you can see the version of the firmware in the camera is 2.03.
Looking at Nikon's site, here: Nikon | Download center | D3, the latest firmware is 2.03 as of April of 2013, so, looks like I'm out of luck on that one.
I'm surprised that a top-notch body, such as the D3, would have incorrect firmware, but alas, I don't have much of a choice since this is the latest version they have out and it doesn't fix the problem.
As I initially suspected, I will need to rely on the original file names to keep the ordering correct going forwards.
I will have to also check my D2Xs and my D3s to see if they too have this same issue.
Thank you for all of your amazing help on all of this! Just had a chance to read about Turn, your amazing history and PhD, and all of the amazing LR products you've developed and sell!
Needless to say, I'm thrilled with the professionalism in the above communications and the patience you've had in explaining all of this while working through it.
Thank you so much!
Hopefully you have another amazing year of heliskiing!
John R Ellis,
Looking at some of my gphoto2 import perl scripts, I see now why I've not had this issue before (I normally import using gphoto2 rather than LR).
Here are some EXIF snippets from a D810, D4s and D4 with the fields you mentioned above:
Jays-Mac:jaypike:[9:58pm]:~/Pictures/2015/October/October 3, 2015 - PPHS - Talent Show> exiftool 20151003203257.Nikon-D4S.DSC_8883.JPG | grep -i sec
Sub Sec Time : 77
Sub Sec Time Original : 77
Sub Sec Time Digitized : 77
Jays-Mac:jaypike:[9:58pm]:~/Pictures/2015/October/October 3, 2015 - PPHS - Talent Show> exiftool 20151003201652.Nikon-D4.DSC_9237.JPG | grep -i sec
Sub Sec Time : 6
Sub Sec Time Original : 6
Sub Sec Time Digitized : 6
Jays-Mac:jaypike:[9:58pm]:~/Pictures/2015/October/October 3, 2015 - PPHS - Talent Show> exiftool 20151003193837.Nikon-D810.DSC_5458.JPG | grep -i sec
Sub Sec Time : 7
Sub Sec Time Original : 7
Sub Sec Time Digitized : 7
Jays-Mac:jaypike:[9:59pm]:~/Pictures/2015/October/October 3, 2015 - PPHS - Talent Show>
Let me see if I can compare this to D2xs, D3, and D3s images.
Ok... now I'm confused... The D2Xs does it correctly, but the D3 and D3s don't....
Jays-Mac:jaypike:[10:06pm]:~/Pictures/Professional/2015/August 19, 2015 - Professional - Alex Repyak> exiftool 20150819-181955-175086.JPG | egrep -i '(model|sec)'
Camera Model Name : NIKON D2Xs
Sub Sec Time : 96
Sub Sec Time Original : 96
Sub Sec Time Digitized : 96
Lens Model : 70.0-200.0 mm f/2.8
Jays-Mac:jaypike:[10:06pm]:~/Pictures/Professional/2015/August 19, 2015 - Professional - Alex Repyak>
Camera Model Name : NIKON D4
Sub Sec Time : 6
Sub Sec Time Original : 6
Sub Sec Time Digitized : 6
Camera Model Name : NIKON D3S
Sub Sec Time : 45
Sub Sec Time Digitized : 45
Camera Model Name : NIKON D3
Sub Sec Time : 64
Sub Sec Time Digitized : 64
I'm surprised that a top-notch body, such as the D3, would have incorrect firmware
I had previously found this thread that claims a number of Nikon models didn't record SubSecTimeOriginal: subsecond exif data? - Photo.net Nikon Forum.Don't know how accurate it is.