#7. "RE: PhotoMechanic Whys?? And Then What? (new to PP)" In response to In response to 4
There is a very good reason why you have to own a Nikon camera to be a member here
Once you bring up Lightroom (LR) vs Capture NX2 (CNX2) and then start looking for alternative cataloging solutions you can end up in a bottomless pit of analysis paralysis that you may never be able to climb out of
Here is the way I would try to approach it, and I think there is a fair consensus of opinion here on this matter...
You are trying to pick out a browser, an image editor, and with at least an eye on a catalog app down the road if not immediately. That is a a confusing mess to think through.
However, at the core of the problem is your selection of an image editor. CNX2 and LR take completely different and very incompatible approaches to raw editing and that flows down to your cataloging decision and perhaps the browser decision.
And that decision is somewhat irrevocable to the extent that no raw editor can read the raw edits performed by another editor. The only way to switch editors is to output all your old raw edits to TIF files, or some other hopefully loss-less and universal format.
The raw editor is your FIRST decision. Once you have made that decision your other options become somewhat more limited, which has some benefit in making those followup decisions easier
With CNX2, your edits are "embedded" in the actual raw file, as well as a very high quality JPG equivalent to about a 95% JPG quality setting in CNX2.
Your out of camera raw images look exactly like a JPG version would look out of camera, responding to all the camera picture control settings. That out of camera image forms the starting point of your CNX2 edits.
With LightRoom, you lose that easy sync between all the camera settings and stock raw rendering. But there are presets that many believe gets either really close or is more to their liking anyway. And in exchange for that you get a single integrated "browser", raw editor and cataloger.
I put browser in quotes because LR is not really a browser to the extent that I think you have to import images in order to get that functionality (or I could be technically wrong on that point?).
Some LR users do use PM for initial browsing and culling. And I believe that PM can set up the metadata such that LR can read it on ingest. So there are some interesting potential app combinations.
I left off a critically important benefit of PM - soft crops. That is an extremely powerful feature. And as a CNX2 user it allows me to avoid cropping inside of CNX2. CNX2 has, to this day, not gotten it's cropping well integrated with localized edits. So that PM feature helps to mitigate one of CNX2's glaring problems.
I use iMatch for a cataloging app. There may not be many viable alternatives now to iMatch or LR now that IDImager has seemingly taken a new direction that may not have been well received by at least it's "power users".
I like iMatch but the current public version has no versioning capability. On the other hand it is possible to make up for it with custom or pre-built scripts. I wrote my own versioning scripts and they work well but I have some scaling issues because I have 300,000 cataloged images. Although LR has some versioning capability I am not sure if it is conducive to the way I have done things in the past, do it's a very complex subject .
iMatch does a lot of things that LR does not do, and it may scale better, or perhaps more to my liking, but it cannot do soft crops, and that alone is problematic. And in particular because in general, when using independent browsers, editors and catalogers, going back and doing updates in a front end browser gets the catalog app out of sync, causing more problems.
And those problems get back to versioning, particularly trying to maintain cohesion between the metadata in the original raw images and then the multiplying output versions, or perhaps TIF or PSD master edits.
If all that sounds ugly, that is why I think that if one can get LR to work, it is the simplest solution. And while it is easy to nitpick LR features (comparing to iMatch for example), over the long haul LR may offer the best combination of coherent features. And perhaps PM as a front end culler and browser can help make LR work for you.
I understand your "obsession" with image organization. It is good to think all that through on the front end, before you dive into a solution.
As far as image file renaming, I have a suggestion. I've run about 300,000 images over an 8 year period using a never ending sequential number as the unique image file name.
That approach, over the long haul, is fraught with peril. I have to constantly check and verify that something didn't burp, causing me to reuse numbers. That is something you need to catch very quickly or it creates some very ugly problems.
PM has been very good about that, but I have had a few problems. One problem was a PM bug that they very quickly fixed for me (that's where their support is so important). Others I never identified and somehow it could have been user error.
I think a better approach may be to use a time stamp in the file name, with sub-seconds to handle high frame rate rips. I did not do that at the outset because of what I thought was a bulky and cumbersome file name. But it well may be a lesser evil. You may also want to add some sort of prefix with camera model number or a code for each camera you may own. You may not even have multiple bodies now, but file naming conventions are best left unchanged so plan ahead for any and all possibilities.
If you do use a timestamp file name you do have to be very careful to keep your camera(s) clock accurate in regard to daylight savings time, and generally avoid the need to change EXIF shot dates (something that PM can easily do but then the EXIF is out of sync with the file name unless you also do a rename- which could be done too .
Just to say there is always the opportunity for user error in any file naming convention but if I could start over, I think I would try to make the time stamp system work.