|
|
|
thx pix.. just to note - the DAM book is very out of date and even the support website is falling behind the times. Iview (the author's recommended tool) is no longer in business and its successor product is not well received by the user base.
|
|
|
|
Installing DAM applications seems... legit? What does that mean?
|
|
|
|
Peleus.. do you truly believe renaming an image from a DAM program is a function that the average person doesn't use? Its an image management program.... how do you propose keeping the catalog and images in the OS in sync then? Or is this program really just an imageviewer with some post processing function thrown in? To me, I'll use Irfranview to view images and Photoshop to edit them... I want a DAM program to manage the images.
|
|
|
|
Wasn't negative.. just stating the obvious. If you cannot rename an image file within a DAM program.. then that DAM program is not worth using. Otherwise, your catalog and OS files get out of synch!
|
|
|
Don't forget to look beyond the photo editing tools however - that really isn't the primary reason most folks use a DAM application.
A DAM application is used to Data Management - ie: importing, tagging, and finding your images when you need them, quickly and efficiently. Editing capabilities is a nice plus - but there are programs that are dedicated to that as well and do a very nice job of it. Certainly a single program that can "do it all" would be wonderful - but at the moment - it just doesn't exist.
Personally, I want my DAM application to really shine at data tagging, searching, scripting, sharing images and working with users to tailor specific items to their workflow. I find Phd does some of these items well while falling short in many of these same areas. Its a step in the right direction and urges the competition to keep on their toes - all good things for consumer.
The best advice - take 100 images with your camera and keep them on the memory card. Download and install 4-5 DAM applications and then take each package through a sample workflow with those 100 images. Ask yourself some questions during the process: does the software allow me to rename my images during import, is the software flexible in adding metadata, how are tags stored in the catalog and database, what search options are available, what standards are followed for storing data, how well does the program allow you cull images (light table, multi-image compare, multi-image zoom)?, etc. etc...
|
|
|
And that's where the software can fall short.. a true DAM product will be able to handle most any file that you can throw at it - PNG's, PDF's, Fonts, etc. Sidecar files would be created for these "non-image" formats but the data would still be stored in the catalog and the sidecar file for searching - when you try to open these files, their externally linked program would open them for you.
Idimager can handle this with ease (even lets you setup your own file extensions for items it doesn't recognize) as can ACDSee Pro... if PhD cannot, this would be a major deal breaker for most - using multiple DAM products for various file types seems a bit silly... the ability to search is negated and the reason to use a DAM in the first place gets lost.
|
|
|
Interesting discussion.. as a non-professional photographer, I too am primarily interested in importing and then finding images at a later time. However, some things are quite important to me for "future-proofing" my images for other software down the road. As such, it is critical to me that keywords and other catalog data be made available to the image itself as well as the catalog - and be stored in the XMP block using established standards.
A long time ago, I moved from Thumbsplus (where I did basic IPTC kewording) to Idimager (where I do hierarchical XMP tagging). So many software packages today fail to support hierarchical tagging along with storage in the image XMP block.
My workflow example:
1 - Import images from memory card in Idimager
- auto file rename based on image exif data (camera model). Images stored on C:\photos\<year>-Month\ and copyright info and other minor metadata is added and stored to the database and image during import.
2 - Images are then rated, culled and tagged using hierarchical keywords. All data is stored in both the catalog and the image XMP and IPTC blocks automatically.
3 - Top images are then further tweaked using appropriate 3rd party software (photoshop/lightroom). For RAW files, the use of DNG allows me to re-embed an updated preview within the file so Idimager can display those edits when searching for the images.
The need for albums, folders and such seem to be geared toward folks that do "event" style photos... even then, a simple search using a keyword tag with the event is just as easy as creating these albums, etc..
The ability to search on specific XMP metadata is important as is the ability to create complex searches that can then be setup as "auto-searches" and saved for future use. For example, if I create a search for Flowers->Daisy->Yellow AND Places->Parks->Jobi, and save that search as an Auto Search, then everytime I add an image to the catalog with those 2 keywords, and then click this search, it will quickly show me those items without even having to search the catalog (the searches are kept in memory and updated as the tags are applied). Kinda like Albums... but more flexible.
Anyway - hope this workflow helps!
|
|
|
|
Interesting review Bob.. but I think you are missing so many functions that ASP has and gets right versus phD... renaming an image for instance.. and XMP block support.
|
|
|
|
but it's not obvious!
It's not obvious because there IS NO WAY to do so... you are right.. a basic function that wasn't added.. Same for XMP support.. IPTC only? So 90's...
|
