Help with DAMN! (Digital Assets Management Now! :0)

[David H. Hartman]

There are two discussions running just now that touch on DAM but maybe a general discussion is in order.

I never developed any scheme for DAM. I save NEF files by Camera Model, Date and a running number, e.g. D850_DSC0000.NEF which is nothing more than appending a prefix of D850 or the camera model to the number the camera assigns to my NEF(s). They are saved in folders by date, e.g. D850_2021-mm-dd_9999. The trailing number created by Nikon Transfer 2 is an aid to returning to a folder from a specific series of photographs.

My filing system for NEF(s) is out of hand and increasingly useless: remember the camera model, remember the approximate date, sift through thumbnails.

I'm sure many here are more prolific as photographers and have much better filing systems and are using catalogs and XMP/IPTC data to locate specific photographs. Also many are using GPS data tagging and wonder if that is being accessed to locate photographs and how. My system is basically a digital shoe box under the bed filled with digital negatives.

I hope not too many have such a poor system.

Dave

[Snoogly]

I need to know how to make Nikon Transfer 2 save in dated folders. It was fine until I did a computer update, but now for the life of me I can't find the setting to create folders with the date.

[David H. Hartman]

Under the “Primary Destination” tab I set “(x) Create subfolder for each transfer.” I set new name “D850” <Underscore> <Date Transferred> in the form of yyyy-mm-dd then <None> then trailing number in the form of 99999. There is a slider to set the number of digits and you can edit the next number to be used if needed.

This is all in a dialogue box called “Folder Naming.”

The reason for using the YYYY-MM-DD format is a computer will display the folder in ascending order for easy access in Finder or Explorer. If a format of MM-DD-YYYY or DD-MM-YYYY is used it's more difficult to locate the desired folder by date. If there are several folders with one date the running number at the end keeps them in order and saving an *.nxd or *.nka (Save all adjustments) file needs to be in the same folder with the NEF who's adjustments they pertain to.

I hope this makes sense. 

Dave

[Snoogly]

Many thanks.

It’s such an ugly app, especially the settings panels, but you helped me figure it out.

[Anthony]

I have created a logical (to me) folder structure. For finding photos, the least useful information to me is the camera model and then the date the photos were taken. I use the Photo Mechanic 6+ catalogue program, but my underlying folder structure is independent of any software other than the operating system.

Them Hogan has some interesting thoughts https://www.dslrbodies.com/accessories/software-for-nikon-dslrs/software-articles/file-hierarchy.html

[arthurking83]

.....



I'm sure many here are more prolific as photographers and have much better filing systems and are using catalogs and XMP/IPTC data to locate specific photographs. Also many are using GPS data tagging and wonder if that is being accessed to locate photographs and how. My system is basically a digital shoe box under the bed filled with digital negatives.

I hope not too many have such a poor system.

Dave

I'm no expert on DAM, but my system is near foolproof. Considering that I'm quite the fool sometimes(always!) and even I can work this stuff out, I'm confident that it's it's near foolproof! 

But it's Windows specific, and have no idea how it or if it would work on another OS.

I use the ability to set ITPC data into the NEF file. I've used GPS data on the odd occasion too. But the most important thing about it is even tho it's a wee bit tedious to add it, just adding some info then makes it easier to enhance each image later on making it easier to manage.
So my 'filing' system is similar to you in that I use my camera models as a prefix for each file name, using the camera generated file name(DSCxxxx) and Nikon transfer to rename each session. At every rollover/resetting of the 4 digit number in the camera number, I would use the camera's file naming feature to begin a new string for the number reset .. and that would simply become DSD_xxxx and DSE_xxxx ... etc. Just maintains sequencing of each file(if this ever became an important concept).

And use directories with the format YEAR->Camera model->(optional repeating folders)->date_reason for session|location|subject(or any combination of that info)

I use optional repeating folders for stuff like for example if I was with the brother, or sister, or at home or just taking some test images with some unique gear or whatever. Reason for this is in case a specific person(eg. family member) wanted a photo of ... situation and we couldn't remember a specific date for the photo... etc. etc eg. family christmas gatherings. You know this particular event/or photo happened at a christmas lunch, just cant recall which year or whatever. so easier to

So one of my last camera sessions was camping with the brother with the D800E .. 2020\D800E\Paul\20200608_Teddington_camp\

Paul is the brother(ie. why images exist in the first place), date,(for obvious reasons), Teddington(is a location) is a nice spot to camp, but I've spent just a single day or hour there driving through there too, so camp is also a unique identifier for that instance at Teddington.
Reasoning for this is that sometimes forgetfulness, lack of time, or simply laziness in tagging the images at the time of upload, and also easier to find images as you remember some unique aspect from them if you don't tag them in some way.

I used to(not so much now) occasionally have no time to tag images as I'd be out working/driving for 20 or more hours a day, start at 7am and possibly get home late into the night to start again the next day.
So time was limited that I'd get home, PC on quickly transfer, charge batteries for camera, quickly transfer and forget to add some tagged info(even tho most of the time they'd be tagged with GPS info) get up early next day and possibly do it all again the next day(whilst at work). Work was driving, and nothing to do with photography itself .. the photography may have been an opportunity whilst at work, during or afterwards.

In Transfer(now) I usually at least try to set at least one tagged bit of info, in addition to embedded GPS data.
The reason why at least one bit of tagged info is important(to me) in an image is it's then easier to use better tagging software to complete tagging the images in that set.

So for example, if I didn't have the time, or simply forget too(easy to get distracted with life) with the Teddington camping set, I would set at least one word in the IPTC section in Transfer so that images were subsequently easier to tag with more specific data at a later date .. could be even months later .. and having not tagged most of my early images I occasionally go back and look for those images and tag them(in bulk) too.

Back in the day Microsoft had a terrible set of software(Windows Live) and one piece in that set was Windows Photo Viewer. It's only saving grace is that it can tag raw files(NEFs in my case) directly and not ruin them in any way. It does this on the proviso that you install Nikon's codec for NEFs on the Windows PC. Windows Photo Viewer(and Windows Live software set) ceased support with Windows 7, but still works fine on Win10.
It's near impossible to get untagged files into PhotoViewer, so this is the reason for having at least one keyword inputted with Transfer.  Once tagged, PhotoViewer is so much more feature rich compared to Nikon's useless software for tagging files, and remember this refers to raw files only.
That I know of there is no other software that will safely tag raw files embed that data into raw files and allow cross compatibility with almost every other software out there that can do DAM.
They all rely on their own database system, and if you ever require tagged data to be viewed by any(or all) of them at a pinch .. impossible. You need to use another process step to convert one database set into another .. and so on and so forth.
In my opinion .. really stupid!

That is, to have a fully feature rich DAM system whereby you have to rely on one single software for eternity .. for me is not an option.

For NEF files, I found(and yet to find any alternative that simply works) is ViewNX2. I use ITPC tagging in that software which embeds into the NEF, then is searchable by Windows itself too. Windows and Windows PhotoViewer both seem to use the same database when searching for keywords.

Back in Windows PhotoViewer, which I use to tag untagged NEFs, and where you can't directly open untagged images is not quite accurately written. You can, but it's a little tedious in that you have to view all untagged images(of which I currently have about 70 thousands remaining). There is a column of all the tagged info within the database on the LHS of the window, and the top most is labelled untagged. click on this and it lists all untagged files. It doesn't list them by any folder/directory structure .. just shows all thumbnails for all images. In the main window, there are obviously limits as to how many thumbnails can be displayed at any one time, and it can be tedious to do some batch lot jobs.
When I have lots of time and not much to do, I may go back into Photo Viewer and tag some more images .. at my leisure. The main idea is more so to separate this 70K lot of files into easier to manage chunks, so I look for obvious small sets of similar files(sessions) and again just add at least one keyword into that set. smaller sets of images are easier to work with. When I began the process of tagging untagged images I had nearly 200K images to go back too .. and the process seemed impossible to do.

My original DAM software was IDImager which used it's own database system(ie. not compatible with Windows OS itself) and worked quite well for me. I like the simple and usable interface(way back then). Dev stopped developing this program and began a new program .. now called Photo Supreme. I tried it but didn't like it(again back then). I needed to build thumbnails and all manner of additional paraphernalia .. and it's own database size inflated to near 10 Gigabytes on it's own.
For comparison, I see my Windows/Windows Photo Viewer database is approx 100-200 megabytes in size.

I never set out to use Windows Photo Viewer for the purpose of searching for tagged images directly via Windows Search, but this is a bonus to have. All I wanted was an easier way(than any Nikon software at the time) to add tagged data into NEF files so that each NEF file is then searchable by any software(into the future). I'm hoping that one day a software that is no so selfishly programmed that it's developer think that it's the only option available .. to date nothing like this exists .. and I suspect never will. So each image at the moment needs to be tagged and embedded.

embedded GPS data can be handy to have, and (that I've seen) many DAM software have the ability to use this to tag a locale name with that GPS data, but I've yet to see one that is actually 100% accurate with place names. Other may have better experiences with this, but living in Australia, and place names in remote areas are not what most mapping software will lead you to believe they are! Here, they can be hundreds of klms off.
So I mostly don't use GPS data for this ability.
I do occasionally check it out in VNX2 tho. As VNX2 is no longer supported and weblinks change over time, most of the GPS/mapping features no longer works. The only section that does work with respect to location data is keywording via GPS data, and only then it works with Wikipedia. The other option(which IIRC) is linked to an now dead Google method of location pinpointing .. so doesn't work. Wiki can be accurate but not guaranteed to be. Id' guess it's accurate for names in popular locales. tho.
Nikon's NX Studio is currently laughably helpful. On images with embedded GPS data, it doesn't even recognise this fact correctly for use in keywording. It knows that there is GPS data, shows the lat/lon coordinates in the INFO panel. But the tag with GPS data option only works if you use the Map window. Why this is is anyones guess. I rarely use the map window for editing and tagging images.

Apologies for the arduous response. But DAM can be important as your store of images inflates to unamanageable proportions. At least one keyword for each session can be helpful. I replied on software specific databases, and didn't like it. I'm not a pro, and nowadays barely even amature enthusiast any longer .. time limited to get out and take photos. Hope that one day will find this lost time. But I'm still interested, but usually disorganised, hence the need a foolproof method.

[Hugh_3170]

Yes, the inclusion of GPS data is well worth the effort IMHO.

[David H. Hartman]

Back in the day Microsoft had a terrible set of software(Windows Live) and one piece in that set was Windows Photo Viewer.

Might I have tried this "Windows Live" to flip or letter box videos that were shot vertically? I found an install program in my Downloads folder in a "Widows Live Essetials" subfolder named "wlsetup-all.exe". I'll have to have a look at the Windows Photo Viewer module.

I'm going to poor over your post to get ideas.

Dave

I never gave a damn about DAM until lately. Sorry 

[MFloyd]

I’m using the DAM features of Lightroom (Lr), which is constructed around a SQL Light architecture, and gives plenty of possibilities to build Albums (dynamic or static) with the images contained in the Catalog.

The Lr Catalog architecture I’m using is the default one; with a year, date hierarchy. The date, on which the pictures are taken, are the easiest for me to remember, and therefore, the most appropriate index for me.

The image index is build under a simple structure: _xxynnnn i.e. nnnn the sequence number generated by the camera (good for 9’999 images); the xx for the camera used eg D6, 85(0), 61(0).. and the y being incremented every 10’000 pictures. One could say that the old fashioned 8 digit structure is becoming an increasing burden.

Last detail, I’m working in a MacOS environment.

[Asle F]

embedded GPS data can be handy to have, and (that I've seen) many DAM software have the ability to use this to tag a locale name with that GPS data, but I've yet to see one that is actually 100% accurate with place names. Other may have better experiences with this, but living in Australia, and place names in remote areas are not what most mapping software will lead you to believe they are!

With embedded GPS data, I don't need names. I can find the pictures in the map. And with a GPS connected to my cameras, this data is collected automaticly and save me for much works afterwards.

[MFloyd]

With embedded GPS data, I don't need names. I can find the pictures in the map. And with a GPS connected to my cameras, this data is collected automaticlyy and save me for much works afterwards.

Positioning data is part of DAM. One angle to access images.

[Birna Rørslett]

Reverse map-lookups to find all images within an area is a highly useful tool. I apply it every day, times and times over. My first GPS-enabled camera was the venerable D1X if memory serves, thus "geotagging" has been with me for a very long time. I already had added GPS coordinates to all my scanned images at that time.

Otherwise, the basic idea is any image should have a unique identifier, which all instances derived from the original are "stamped" with. This is not meant to be used for information retrieval as such, only that you through a relational database can easily locate the original or any instance of it. Let the database keep track of the instances, ie. one stores a pointer to the actual storage location not the image itself in the database. All the technical data would be there for automatic extraction via EXIF to be added to the DB, so why bother trying to make a search structure for the data yourself?  Put any useful metadata (person names, species ID, ...) into the DB for future searches.

The unique identifier can be as easy to construct as using the precise time of the given capture, down to millisec level. Or you can generate a 128-bit GUID if you wish. Doesn't matter as long a the DB knows.

[David H. Hartman]

A problem for me is I only started embedding GPS into NEF files recently. Worse most are taken at or near the same location so for most of my photographs GPS is not useful. I've only started using Snapbridge with my D850 so all of my digital images going back to 2004 and up to late 2020 have no GPS data.

The date and time of an NEF is slightly more helpful but depends on my memory. I need to note who or what is the subject. Many photographs in the last few years even have the same subject so actions or the subject or descriptions are needed. I have simply ignored rating and tagging my NEF files.

This XMP/IPTC data is a pain. It seems the camera and ViewNX2 stores it in the NEF and it's with or a part of the EXIF data. Then ON1 Perfect Browser stores this data in sidecar files as I recall. Now it appears that ViewNXi and NX Studio stores XMP/IPCT data in *.nksc side car files.

Do I understand that ON1 and Nikon software as well as most other software will find the XMP/IPCT data in the NEF but will be oblivious to XMP/IPCT data stored in side car files other than their own?

It seems to me I'll have to add XMP/IPCT data as I can giving information about the subject and what the subject is doing. If the XMP/IPCT data only list the name of the subject then I'd need a way to scan visually large thumbnails to find a specific image. It's going to be an exercise in archaeology. It's like looking for the Lost City of Atlantis which is probably several kilometers down in the mid Atlantic Ocean and probably has been for nearly 12,000 years.

I might be looking for photographs I took at the time of Melt Water Pulse 1B at the end of the Younger Dryas. 

Dave Hartman

[Birna Rørslett]

Nothing inherently "wrong" about having metadata embedded in the RAW file or sidecars. However, searching tend to be inefficient unless a separate search index is built, and then you are heading towards a DB strategy so why not go the whole way?

Without some kind of universal  identificator to each image, how can you tell an instance of  say a jpg or TIF derives from a given RAW file? and how shall the original metadata be associated to these instances? If you add more metadata later, how will the new information trickle back to your initial RAW? All of these issues vanish with a relational database.

[David H. Hartman]

All of these issues vanish with a relational database.

...but which one?

Adobe Lightroom is out. I didn't have internet at my home for about 22 months. I was paying for a friend's internet as she could not afford her own. She is quadriplegic. She was taking on line classes or hybrid classes when her internet was shut off. I'd be paying $20.00 (USD) a month for Photoshop and Lightroom. I would not use Lightroom except for DAM. Doesn't Lightroom gather all NEF into some specialized folder/archive like iPhoto did? Sorry I can't think of the term used for the massive iPhoto collection. Then when Apple discontinued iPhoto and replaced it with MAC Photos I had to down load a utility from Apple to convert from iPhoto to Photos.

For a data base to be acceptable to me it would have to catalog the NEF(s) but leave them in the folders and sub folders that I specify with Nikon Transfer 2. It could not rename the files or folders after upload. Ii could not compress them into some archive. They would have to be accessible to Windows Explorer and MAC Finder. I've unpacked my friend's iPhoto special folder. They are in dated sub folders but not in the form of YYYY-MM-DD so they don't sort properly in Finder or Explorer. I think it's MMM-DD-YYYY.

The lack of compatibility between various DAM products may have stopped me last time I thought of this. This all seems like an unkept backyard full of weeds. Some have pretty flowers and have seeds that work their way into your socks and scratch up your legs.

Dave

---

What if any software can edit EXIF data in NEF(s)? I have a few NEF(s) with incorrect copy right dates that I would like to correct.