filename limitations?

[gemini]

Hello all,

I downloaded the Trial version of 2020 and am getting my feet wet. So far, so good.

Some folders however don't update. When I first scan the folder, some subfolders show there are pictures (.CR2) and show them with the "file has been relocated" icon in the top left. If I rescan the folder, all files disappear.

I do see them in explorer and they appear in Lightroom.

If I change the name of the file, then it appears in iMatch.

Are there restrictions on filenames in iMatch?

Examples of filenames that have the issue:

CAN_Honeymoon_Blackcomb Glacier - Blackcomb Glacier Run_20150302_Canon EOS 6D_Susan Takes a Break Mid-Glacier_1725.CR2
USA_Monhegan Vacation_Lighthouse Hill_20180727_Canon EOS 5D Mark IV_Mars Opposition behind the Monhegan Lighthouse_1022.JPG

Thanks,

Paul

[jch2103]

I don't know if this is your issue, but Windows has had a 260 character limit for path name lengths. It's possible you're bumping into the limit with your long file names.

[Mario]

Tip:_ It helps a lot if you include the IMatch log file of the IMatch session where you've experienced problems.
We don't even know which IMatch version you are using. See log file.

IMatch does not limit file or folder names. But it is of bound by the typical file name limits in Windows.
While IMatch may handle excessively long file names with more than 260 characters, many of the helper software it uses (ExifTool, FFMPeg, PDFLib, WIC Codecs, LibRaw, ...) may have issues with such long file names.

The file name "CAN_Honeymoon_Blackcomb Glacier - Blackcomb Glacier Run_20150302_Canon EOS 6D_Susan Takes a Break Mid-Glacier_1725.CR2" is OK, though. Works here.

But it has a whooping 120 (!) characters, just for the file name. Very unusual.
And if you know store these files in a very deep folder structure, you may run into the 260 character limit.

I'm not sure if I have seen such 'expressive' file names ever before. It looks like you store titles, keywords, date and even a description in them...data which usually goes into the metadata of the image.

[gemini]

Hi Mario,

I'll dig up the log file when I get back on the desktop.

Point taken on the long file names. I might have to rethink that.

What puzzled me was that I use Windows 10 Pro and have longpathnames enabled in the registry, as well as for Win32 NTFS. However, it makes sense that helper applications might not like it.

The interesting part is that I updated Lightroom Classic and it does the same thing as iMatch, i.e., it sees the files on import, but once I browse to the file, there are no thumbnails and the file is marked as missing. So, it is not an iMatch-only issue.

In Explorer, though, I see the file just fine.

In the meantime, I'll rethink my naming, as I like what I am seeing in iMatch.

Thanks,

Paul

[sinus]

Paul,
you are right, I would also rething the naming-convention, that you use.
Too long names are nice, but can give you later problems, not only in IMatch.

I use also long names, but all in the same way and not that long as you.
Your name e.g.

CAN_Honeymoon_Blackcomb Glacier - Blackcomb Glacier Run_20150302_Canon EOS 6D_Susan Takes a Break Mid-Glacier_1725.CR2

would be in my system e.g.

20150302-1725-EOS-6D-Honeymoon-Susan-Takes-a-break-mid-glacier.cr2

Date first, good for sorting.
Canon is not necessary (I think)
and a short description
I would avoid spaces

My naming-convention is like this:

20150625-1027-262268-s-kun-oski_m.nef
20170607-1510-315735-s-pri-roomescape_m.nef
20181214-1031-359160-c-coo-schmid_m.nef
20200527-1108-387364-s-ref-mirjam-sothmann_m_v1.jpg

And this is for other users almost quite long.
Often is at the start the date and time (like I do), because it gives a good sorting, also in Windows.
Then maybe a uniqe number or the orignal number or something else.
That's it.
I do append some hints for me, like -s- and -pri- and in my case then a SHORT description.

In you example, I guess, if you want search this image, you would not search for "Susan Takes a Break Mid-Glacier", because you can maybe not remember all correct, but you would search for "Mid-Glacier" or for "Susan" or for both, like "Susan AND Glacier".
And that works fine and fast in IMatch.

[Mario]

The interesting part is that I updated Lightroom Classic and it does the same thing as iMatch, i.e., it sees the files on import, but once I browse to the file, there are no thumbnails and the file is marked as missing. So, it is not an iMatch-only issue.

Hard to tell without a log file.
But by the looks of it, probably the WIC codec (if used), the LibRaw image library (if used) or the 3rd party imaging library used by IMatch to extract images from files fail with your excessively long file names.
260 characters is a lot and you usually never exceed it. Not even when you use really deep folder hierarchies, which is unusual.
But if your file name has 120 characters already and you use also rather long folder names or deep hierarchies, you may run  into this.

[Carlo Didier]

In the company I work, we regularly run into those problems. I've seen file names and paths where my first thought was "this file might as well be empty because everything is already in the name and path ..."

The problem with Windows is that it usually allows you to create such a file/path, but then your won't be able to delete/rename or move it afterwards ...

My naming convention only includes the date and a counter to assure the names are unique. The folders just contain a very short (1-3 words) indication of the content. All the rest is in iMatch. That's what a DAM is for, after all.

[herman]

[...]

In the meantime, I'll rethink my naming, as I like what I am seeing in iMatch.

I guess most of us have been there, seen that and done that.

I suggest you search for some national standard or recommendation, depending where you live there may be an organization issuing this.

I live in The Netherlands, over here we have the NIDF (Nederlands Instituut Digitale Fotografie) who issued a standard with respect to digital photography saying something about filenames as well.

For filenames they recommend:
nn-YYYYMMDD-xxxx.ext
where nn stands for the initials of the photographer
YYYYMMDD stand for year, month and date
xxxx is a four-digit sequential number, so you can have 9999 unique photos per photographer per day without filename duplication.
ext of course is the file extension such as JPG or DNG.

You will find the IMatch renamer to be a very powerful tool in this area.

[Mario]

Sensible advice from the NIDF!

I prefer to keep the date part in front, because this allows me to see the files sorted by time even in dumb tools which cannot sort by metadata: YYYYMMDD-NN-nnnn.ext

A common variant of this often used in commercial photography is to add a c-p prefix/suffic for the client and project, giving CCC-PPP-NN-YYYYMMDD-nnnn.ext or YYYYMMDD-CCC-PPP-NN-nnnn.ext.
Some also include a company short code (like PTC for photools.com) or similar, especially in files delivered to clients.

All good conventions. Short, same length for all file names, easy to produce with IMatch Renamer.

And very easy to automatically organize files by photographer, client, project, year... (or combinations thereof) using IMatch data-driven categories and the photools.com filename tag.

For 'normal' photographers, the date and time and a sequential number is usually sufficient, IMHO.
All else should go into metadata, where it belongs.

[sinus]

I prefer to keep the date part in front, because this allows me to see the files sorted by time even in dumb tools which cannot sort by metadata: YYYYMMDD-NN-nnnn.ext

Exactly what I would advise.
If you are totally alone, nn in front would be ok, but then you could ask, is it generally necessary!?

And if there are more than one photographer, or sometimes only another from the family, who took the image, then I would also prefere sorting for date.

BTW: I had in the last time a private wedding, where I had at the end a lot of different images from different people for the same event.
Puh, the only thing for me was sorting after date-time to get all this together (and some had a wrong date-time in the cam  )