10

I notice that when taking photos using my camera phone, the file name consists of the date and time. (e.g. 20131101-110015.jpg)

However, most point and shoot and DSLR cameras do not. Their file name is usually in a sequence like DCM0011.jpg

Is there a way that we can set a camera option so that it will create the file with a name that contains the date and time?

With reference to a Point and Shoot Camera Samsung EX1 vs a Camera phone Samsung Galaxy S2

  • I for one would love this to be an option! Canon 5D MkIII's have limited file name control but that's more a case of 3 letters... >_> With DSLR's that can take multiple photos per second, the file name gets longer and longer – NULLZ Apr 10 '13 at 6:01
  • The Brand Olympus has a simple system: it usually starts its names with a 'P' or '_'(don't remember what means but it's related to colorspace), then a digit for the month: 1,2,3,4,5,6,7,8,9,A,B,C, two digits for the day and four other digits for correlative. Thus, file PC083651 was shot on December 8th. It is indeed VERY useful and at least I have never had a problem. It's only odd if you shot during Dec 31 midnight, because "older" file suddenly gets on top of the alphabetically ordered list. Maybe they have a patent and it keeps the rest from doing it. – Jahaziel Apr 10 '13 at 20:52
  • 3
    If they did include the date, it should be in ISO 8601 format. Anything else would be confusing. Also ISO format means it will sort properly. – vclaw Nov 6 '17 at 12:33
  • 1
    I think its easier for most people to just get all the photos in one place. For regular people a convention like this would mean your cameras storage would have very few photos in each folder. Its also trivial to create scripts to import photos and use the exif data to arrange them however you like, though most people probably use software like Lightroom for all of this anyway – JimL Nov 6 '17 at 16:48
  • 2
    Note that the filesystem itself has a timestamp. The ordering convention is still needed for cases where the image creation speed is faster than the resolution of the timer and/or filesystem support (I don't think FAT32 supports milliseconds?). Also, in normal usage, the time is probably going to be Jan 1 1970 for a large subset of users. – Yorik Nov 7 '17 at 15:39
16

This comes down to software patents — not on dates, but in a way that limits filenames. The only filesystem which is widely available and cross-platform is FAT, the venerable Microsoft DOS filesystem. It works on both old and new versions of Windows, worked on OS/2, works on Macs, works on Linux, and there are plenty of embedded implementations for the mini operating systems that run on cameras. It's old enough that it is public domain.

But, there's a catch. The original version only allowed filenames of eight characters plus a dot plus the three-character extension. The extensions which allow longer filenames are much more recent, and a while back Microsoft was doing some serious saber-rattling over collecting royalties. That means most cameras — and the DCIM standard — take the safe route and avoid code to generate long filenames. And that means human-meaningful date and time isn't viable, because it's just plain too long.

This is backed up by a technical manual for an embedded SD card driver, which notes:

Microsoft offers licensing for the use of its FAT filing system on a per unit sold basis. However it is generally viewed that this only applies to applications that implement the patented long file name system (LFN). It is our understanding that if long filenames are not used then no licence fee is due, however you should ascertain if you agree with this view yourself (to our knowledge Microsoft have not stated this but others have determined this based on original releases of the FAT standard by Microsoft).

Cameras or cameraphones which do write longer filenames have either paid Microsoft, are using a different filesystem, or aren't worried about the legal threat.

  • You got it! That is pretty much the restriction. Even dates for cameras that support date file-names are encoded bizarrely with month past October as a single letter to make it fit. – Itai Apr 10 '13 at 13:04
  • 1
    FAT32 can support more than 8.3 and is not encumbered as far as I know. Cultural date issues and name sorting is a bigger issue. – AJ Henderson Apr 10 '13 at 18:57
  • 3
    @AJ Unfortunately the situation is not so rosy. It's specifically the long filename support in VFAT/FAT32 that is at issue; specifically USPTO 5579517. This was tossed out on review but then reinstated a few years later. The Linux implementation has a workaround which is believed to not infringe (see more on that at LWN), but the most simple workaround is to avoid creating long filenames. – mattdm Apr 10 '13 at 19:16
  • They could work around this by storing the dates as separate folders, rather than as part of the file name. In fact, that is exactly what my Sony a390 does (though that option is off by default) – BlueRaja - Danny Pflughoeft Apr 15 '13 at 18:15
  • Actually, FAT only supports 11-character directory entry names. These are commonly displayed as 8+3, but back in the old days, it wasn't all that uncommon to simply use all 11 available characters as the name with no specific extension. Of course, these days, using extensions is commonplace and anything else would at best cause much confusion. – a CVn Apr 16 '13 at 11:58
7

The reason most cameras don't store files by data and time is simply because no one wrote the code in the camera's software to do so.

One possible reason nobody wrote that code is that the date/time format is illegal according to the DCF standard that describes how cameras should store images for compatibility with other cameras, viewing devices and printers (wikipedia link, actual standard doc).

Another reason nobody wrote the code is that writing code, even seemingly simple code, requires more time than you think (what to do when switching file name modes, what to do when a file with that name already exists, will it work with the software in the CD that comes with the camera? and now you have to test everything twice, once with the old file name mode and once with the date time mode...) - and all this work for a feature that will not sell more cameras - so all that time is better spent elsewhere.

Now, for how to do it with your cameras, a quick search in the Samsung EX1 user manual did not find a way to change file names, so it's probably not possible.

  • 1
    I think the second paragraph here is the important one: the standard specifies <3 letters>_<4 numbers>, and date and time don't fit into that. – Philip Kendall Apr 10 '13 at 8:36
  • @PhilipKendall - you can always just not conform to the DCF at all (like his cellphone) - or have two modes, a DCF mode for people who want compatibility with all printers and picture frames and a date/time mode for people who care about file names (and then you get to my 3rd paragraph, the cost of those options is non trivial). – Nir Apr 10 '13 at 8:44
  • 3
    @PaulCezanne - I disagree, from an engineering point of view there's only one reasonable date/time format you can use - the number of milliseconds since the UNIX epoch obviously, in UTC timezone – Nir Apr 10 '13 at 10:17
  • 5
    I think it introduces to many variables outside of the 'programmers control'. For example, how does the camera respond to 14 shots per second? Also, because time and dates change, it is possible to take a photo, then an hour later, change the time back to an hour earlier, then take a photo. What's the camera to do then? Too many conditions, that a simple incremental file numbers solves nicely. – cmason Apr 10 '13 at 13:05
  • 1
    @PhilipKendall - true, but the deeper question is why do the standards specify that. The short answer is cultural agnosticism and proper sorting by name. Also the file creation datetime stamp already captures the datetime as a timestamp that is culture independent. – AJ Henderson Apr 10 '13 at 18:58
3

It's mainly about file name lengths at the time the Design Rules for Camera File Systems was developed. Many operating systems in widespread usage at that time did not allow file names long enough to accommodate date/time stamps with enough detail to differentiate, for example, two images taken within the same minute, much less the same second. There's also the EXIF specifications that can be even more restrictive.

Pretty much any modern digital image file management application from third party vendors (Lightroom, On1, CaptureOne, etc.) or camera makers (EOS Utility/Digital Photo Professional, ViewNX, etc.) allow you to assign new file names to images when importing them onto a computer. It's pretty trivial with most of them to set up automatically assigning a new file name upon import based on date and time. With modern frame rates being what they are, you'd need a filename that could differentiate 10 or more frames taken within the same second for a number of cameras, though. Then there's the whole issue of importing images taken using two different cameras (mult-shooter wedding,etc.) at the same time (or near the same time but with clocks on each camera offset just enough that some of the images' timestamps would be identical - sports or event shooter) into the same folder.

  • 2
    The extensions to FAT directories to cover longer names were patented by Microsoft, so long file names were avoided even though they were well known and trivial to implement. That's where the 8 character limit comes from. – Mark Ransom Nov 6 '17 at 23:51
  • Yep. That's why the answer says, "... did not allow file names long enough..." rather than, "could not allow file names..." – Michael C Feb 19 at 21:36
3

Yes, there is a specific reason. Doing so is not the simplest application of the standard. Conforming to the simplest application of the standard facilitates interoperability across manufacturer's, software, and time. New software can handle file level operations on old images. Old software can probably handle file level operations on new images.

There are also non-specific reasons. One is that date and time can be better encoded in EXIF alongside other relevant data like camera model, aperture, white balance, etc. and putting it in the file name is redundant and opens the can of worms that is distributed data (which is the cannonical truth, EXIF or filename?). More practically speaking, filenames are a matter of personal preference: one person may want timestamps, another lens model or focus distance or shutter speed or white point.

Remember, your camera is a computer and naming things, cache invalidation, and off-by-one errors are the two hard problems of computer science.

1

No digital camera does it but many Android cell phones do, so it is probably simply historical. You need at least sub-second accuracy as you said because the majority of cameras can fire more than once in a second, even in single-shot mode. With modern burst rates at 60 FPS, you would need at least two digits, so hours + minutes + second + hundredths is already 8 chars and there is no room for a prefix, so you're out of the FAT limit which was in use when the current convention started.

In any case, I don't think it buys you much. Would you know which photo you took by looking at it if the name was a timestamp? What if your camera time was wrong or you were in a different timezone? A few people keep their cameras in UTC but most have it set to local-time. So a sequence number is as good as any other convention to distinguish images. Personally, I am more concerned now by having images spit into folders and forgetting to download or backup the next one.

-1

The main reason is that date formats are also not internationally standard and are not always sortable by order. For example, if I was to view files in order in the US, then mmddyyyy format, then files for March of 2003 would be listed after files for January of 2012. Using a continuous sequence insures that the files will sort by when they were shot when sorted by name. The file's date/time itself stores the datetime in a internationally compatible format and the meta-data on the image itself also contains the information.

One other reason I can think of is that you would need sub-second accuracy for the timing represented. With most DSLRs it is possible to shoot multiple shots per second. My camera for example shoots 6 to 7 shots in 1 second if I hold down the button.

So, in short, the main 4 reasons are to prevent confusion from cultural differences, ensure proper sort order by filename, because multiple photos can be taken per second and because the datetime is already stored through the file creation time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.