FWIW, here's a writeup I did on adapting Peter's DAM principles to ACDSee Pro 2:

http://blog.acdsee.com/2007/08/24/digital-asset-management-dam-with-acdsee-pro-2-part-15/

Given that you have CS3 already, the idea of using ACDSee as I do (it is my all-in-one RAW processing / cataloging solution) may not appeal to you, and if you use ACR for your RAW processing, you may find ACDSee's limited support for embedded DNG previews to be a big issue.  but since you say you are doing initial edits using ACDSee, perhaps you are actually shooting JPEG?  In which case, the suggestions I give for JPEG workflow might prove useful whether you use ACDSee or not.

Marc

I'd say that the hours you spend reading the book will pay for themselves countless times over in avoiding wasted work later.


Not at all.  But this is what could end up happening if you don't have a good strategy in place before you begin - and that's what "The DAM Book" will offer.  Without a good strategy in place before you begin, you'll constantly end up discovering things you wish you had been doing all along and having to re-do old organizing work, or else putting up with not being able to search/browse/access your images the way you would have, had you only had a *good* strategy in place from the beginning.  And you'd run the very real risk of someday having to switch cataloging applications and finding all your hard work having to be re-done because you didn't do it in a way that would transfer across applications.

This is what I mean about spending time with the book saving you *much* effort and aggravation later.  Sure, you'll spend a while *learning* to do it well.  But once you've learned how, the actual process need take only a few minutes per cardful of images, and you can feel confident that you've done all you will need to in order to search/browse/access those images months, years, or decades from now.


I wouldn't go *that* far - if this were so, there would be no need for forums to discuss the intricacies of implementing Peter's ideas :-)  But you'll have a much better idea of what the goals should be.  I personally skimp on quite a bit of the specifics of Peter's workflow because, like you, I'm far from a pro, and my needs are a bit simpler.  So I came up with a scheme based on his ideas, but focused on those ideas that really resonated with me, and adapted it all to work well with the software I chose (ACDSee Pro 2).  You're welcome to check out my writeup on that, but I don't think it's any substitute for reading "The DAM Book":

http://blog.acdsee.com/2007/08/24/digital-asset-management-dam-with-acdsee-pro-2-part-15/

Marc Sabatella

Many converters have code in them that checks to see what type of camera a RAW image is from, and if it's not on the approved list, it doesn't even *try* to decode the information in the file, because it is afraid it won't know how.  RAW converters assume that they are going to need to be tweaked for each new camera - new cameras might have different formats or different ways the image data needs to be interpreted.  But the reality is, the formats usually don't change significantly between models from a given manufacturer.  Which is why you can sometimes fool converters into dealing with new cameras from known manufacturers by simply using a binary editor to alter the magic field that identifies the type of camera.  Assuming you know enough about the raw format in question to know where this info is, of course, and most of us don't - but you'll often see such hacks posted to forums shortly after release of a new camera.  Eg, "here's a script that will fool RawConverterPro into thinking raw files from the new Canikontex X25 actually came from the old Canikontex X24".  With DNG, converters can take the RAW data at face value since the format is *known* to not change.  Sometimes they are a bit off on color, at least until they actually do learn about the new camera, unless they are able to make use of the color info Peter mentioned.  At least that's my understanding.

Marc Sabatella

I do pretty much the same thing.  My original DNG files live on an external HD, but I don't have room for all of of them on my laptop, and I don't particularly care to carry around an portable external HD and have to connect it every time I want to look at some pictures.

For me, the big realization was that I don't actually need the DNG files for the keepers on my laptop (and would likely run out of room even for those unless I kept upgrading my internal HD regularly).  Instead, I generate "proofs" - somewhat compressed JPEG files at 1200x1800 or so resolution.  These are just fine for satisfying my desire to see my images when away from home, and they are also fine for emailing to others, posting online, and even printing at 4x6, should I wish to email to them to someone else for printing.  So I tend to use these proofs for "most" things I do.with "most" images.  Anything else can wait until I get home.

So I assume the management nightmare you refer to has to do with the multiple versions.  The DAM software I use - ACDSee Pro 2 - doesn't have any built in version control, but my workflow is such that it isn't a huge deal to mange this myself.  In a nutshell, it looks like this:

- Import pictures, rate, adjust, add metadata, sync metadata to XMP (basically, everything Peter writes about).

- For the "keepers", generate proofs. These go onto my laptop internal HD in a folder called PROOF (with subfolders that correspond to the buckets containing the original).  These proofs inherit all metadata of the originals - both the private metadata and the IPTC fields.  They are named by appending "p" to the original.

- Any searches I do on keywords and so forth will of course hit both the original and the proof.  But a simple glance at the filename tells me which is which.  If there are enough hits that the duplication bugs me, I simply add "+PROOF" or "-PROOF" to my search criteria, to restrict my hits to either only the proofs or only the originals.  I could used virtual sets to keep my originals and proofs straight, but including the folder name as part of the search is actually less effort and just as effective most of the time.

BTW, for me, 3 stars is roughly the equivalent of Peter's 1; 2 stars is like Peter's none, and 1 star are the ones that are really just plain bad and will probably be deleted is disk space ever becomes a major issue.  So it's my 3 star and above images that get proofs - these are the "keepers".

I should also note that my "current" bucket always lives on my laptop as well.  So even when away from home, I can go back over the last few days / weeks of shots and access the originals, to further tweak the RAW adjustment, metadata, or whatever.  Only when the current bucket fills do I move it to my main external HD (I do backup the current bucket to a different external HD, along with my "working" files.

Marc Sabatella

I've been using the basic version of II happily for the past year or so.  I hadn't been trying to add metadata because I found it easy enough to do so in my cataloging program.  But I have come to realize the advantages of getting bulk metadata in there sooner rather than later, and while I can automate this in my cataloging program, it *is* a separate step, and in order to be most efficient, it also requires me to have II *not* convert to DNG and to do that from within my cataloging program after the bulk metadata is added (in the form of temporary sidecars).  So that's a little more manual interaction than I'd prefer.

I'd like to use II to add the bulk metadata.  For my purposes, static templates seem like they would be fine, *except* I don't know how to create one or where to put it.  My read of the manual suggests these are perhaps just XMP files with the appropriate metadata added, and I can certainly create one of those, but don't know where to put it to get II to see it.  Any chance of me getting this going, or do I need Pro in order to do metadata at all, given that I don't have Photoshop installed?

Marc Sabatella

I too am an artist taking pictures of my own paintings.  Occasionally in-progress, but mostly just to document the finished product.  I used to separate these from my normal workflow for various reasons that no longer seem particularly important.  At some point, I got tired of maintaining two separate processes, and I've been adopting my regular photography workflow to my paintings and finding it makes my life *much* easier.  I suppose the distinction is not unlike professionals wanting to separate job-related and personal work.  At most, it seems that using the same workflow but perhaps separate catalogs if your software supports that would be OK.  For me, it's easier to keep a single catalog.  The only real concessions I am making to the different types of work are:

- Whereas I don't always generate a high quality conversion of my "regular" photos, I always do for my paintings.
- Because I am using the derivatives for a very specific purpose independent from the rest of my photography, these go in a separate directory with the rest of my art-related stuff, not in a general-purpose "derivatives" directory.  there's not that many of them (I don't complete more than a painting or two per week, generally) so I don't mind the need for separate backup, et.  The original DNG's remain with my other photos, however.
- I will rename these with the title of the painting, because titles are more fundamentally important to my painting than my photography.  The originak title remains in the IPTC info.


My assumption is that the *photos* of my paintings are all top-quality, otherwise, I delete then and do them again until I get it right.  I keep one photo per painting, and my ratings have more to do with my feelings about the painting than about the photo.  This idea extends to other metadata, too.  For instance, all my photos of my paintings are shot at my home, but the paintings themselves are generally painted on location all around the region.  I use the location of the painting as the IPTC location.  Keywords are similarly based on the content of the painting., with no real distinction to say it is a painting except that there will be a keywords "paintings" - the same I would use if I were taking pictures in a museum.  I use the equivalent "catalog sets" to track the fact that these are *my* paintings.  I also have a catalog set for the reference photos I took while paintings, and if I do in-progress photos, they could also get a catalog set, although I have actually bothered with that yet.

Marc Sabatella

Sorry it took a while to get back you.  In my experience, Pro 2 is quite sable, in the sense that it doesn't crash any more than any other application I use heavily (which is to say, it has crashed, but very rarely).  If you check out the forums on the ACDSee site, you'll see there are some pretty specific problems identified that some seem affected by.  A minor update has been announced and is expected in the next week or two.  There is a trial (full version, just with a special time-limited license code) available so it is easy enough to try it for oneself.  30 days should be more than long enough to get a sense of how well it suits ones needs, and since the update is expected soon, there is no reason not to go for it.

I still don't understand the situation completely, but I can now verify that the DNG converter *is* changing the EXIF timestamp info.  Specifically, it is adding EXIF fields to the XMP area, copying the time unaltered from the original EXIF fields, but appending timezone info taken from one's Windows settings to the time/date digitized.  And this is causing some XMP-aware utilities (including, but not limited, to, ACDSee) to *report* the time in GMT equivalent instead of local time.  To what extent that is reasonable is another matter, but apparently, there is not as much standardization as one would hope for in terms of how time zone information is handled with EXIF.  So for now, I'm content to chalk this up to different manufacturers interpreting things differently, and as long as I can get the tools to produce the results I want - and the workaround I mentioned does seem to do this - I'm not going to worry about it.

But for anyone else using the DNG Converter - and perhaps other Adobe products - you might want to be aware of this.  The upshot is that the timezone of the computer on which you generate the DNG gets hardcoded into the file.  I suspect that would allow some utilities to do clever things like display the EXIF info in *local* time, but it would be based on offset from the time zone of the computer on which you converter to DNG, not on any notion of where you actually took the picture.

Marc Sabatella

Just a quick heads-up that ACDSee Pro 2 has now been released (with the feature set as already described; no last minute changes):

http://www.acdsee.com/

Again, I don't work for them, but I have been participating in the public beta and helping moderate their forums.  I am trying to be careful not to come off as a "shill" but rather as someone with some insight into the product, and its DAM capabilities in particular - and I do as much promoting of "The DAM Book" in ACDSee-land as I do of ACDSee here :-)

Marc Sabatella

Not having used the recent versions of IDimager, I can't comment on how they compare to ACDSee Pro 2.  But I can verify that Pro 2 does what I think you are asking about - giving you easy ways of viewing, for example, all photos shot at ISO 200.  There is a search facility for more complex types of operations, but the "Auto Categories" facility does what you describe very simply - the interface looks very much like what was posted for IDimager.

Whether ACDSee Pro 2 makes more sense than IDimager is going to depend on how you intend to integrate the tool into your workflow.  From what I have seen on these forums, IDimager has been at the forefront of providing features specifically designed to work well in conjunction with Bridge and Photoshop in implementing the DAM Book workflow.  On the other hand, ACDSee Pro 2 was designed to provide more of an all-in-one RAW processing, cataloging, and image editing environment a la Lightroom.  So while they might comparable in many ways, the right choice will probably depend on how you plan on using the tool in your DAM strategy.

Marc Sabatella

I'm having trouble finding anyone else with the same problem, so it does make me suspect there is some sort of setting I have that is messing things up, but so far, I've been unablet o find a way to actually correct the problem.  But I *have* managed to figure out something of a workaround.  It turns out if I first generate XMP sidecar files for my RAW files, and those XMP files contain the correct EXIF timestamps, the DNG converter will use those rather than then the ones embedded in the image file.  My adaptation of the DAM Book workflow for ACDSee Pro 2 had me converting to DNG during the image ingestion phase, because ACDSee's use model was such that it made more sense to do this before entering any metadata.  So what I am doing now is entering the location and copyright/contact information (only) immediately after ingestion on my proprietary RAWs.  This generates XMP sidecars that includes EXIF timestamps, so I can then then convert to DNG and get accurate timestamps.

Has anyone else experienced issues with the standalone Adobe DNG Converter changing the EXIF date in your images?  I just discovered that it has been doing this to my images for the last several months (ie, as long as I've been using it).  I saw a reference to some sort of time zone bug in the Adobe forums, but I am having trouble accessing them.

Marc Sabatella

I'm working on it :-)  Like I said, they do seem to be catching on to the value of this DAM stuff.  While I agree that it is a shame that Pro 2 is missing these features that would have made it an interesting choice for folks looking to use it in conjunction with other software, I do think it is at the point where it is a very interesting choice for those considering an integrated solution like Lightroom.  Of course, even folks using an integrated solution may eventually wish they could embed previews in their DNG's.  But ACDSee Pro 2 is thankfully much less of a "closed loop" than Pro 1 was, and I think it is quite usable as is.  At least, if you don't need those embedded previews *right now* - that is, if ACDSee itself is sufficient for doing the sort of things you might otherwiise have used the embedded preview for.

Marc

I have.  I pointed this out very early in the beta period, but as it was, getting the ability to write XMP metadata (including IPTC and raw processing parameters) to the DNG file was all they were able to get in for the release.  I think my workflow writeup is going to help - they seem quite interested in it (more so than I was ever able to get them in "The DAM Book" itself).


I've never used iView, so I can't say.  ACDSee definitely caches previews for files it converts itself.  Not sure about files for which it uses the embedded preview.


Pro 2 is by all accounts "better" than Pro 1 in terms of output quality, but I'm not really the best judge here.  I can say there are more controls that Pro 1 had - highlight recovery, fill light, local contrast enhancement, cropping.  But more important, the workflow is *much* improved.  More work is done via background processing so there is less waiting, and there are new features to allow settings to be copied and pasted from image to image, etc.

The public beta is still available for downlaod as far as I know - www.acdseepro.com.  However, it does not include the DNG writing support.

I'm not sure what you are asking here.  RAW processing in ACDSee Pro 2 is RAW processing - it operates on the RAW data itself, just like any other RAW processor.  It might have to convert that data internally in order to display it, but it isn't "operating" on the converted data in the sense that would seem to imply.  You can choose to save a converted version of your processed image, but as with programs like Lightroom, you don't *need* to.  ACDSee generates its own internal preview that it will show you whenever you view the image (you can control whether it keeps all these previews, or whether it caches them and regenerates them as necessary).  More importantly - again, like most other RAW processors one might be considering - ACDSee remembers the settings you used in your RAW processing (in the case of DNG, these are written directly to the DNG file as XMP metadata).

As I mentioned, ACDSee *will* display an embedded preview generated by another program, but that's all it will do - display it.  ACDSee is capable of doing a number of other things with your images, including editing, printing, emailing, etc.  But it will not use the embedded preview for this - it will do its own RAW processing, which is almost certainly not what you want. That's why I said those who might want to use ACDSee for cataloging only might be disappointed - unless they have yet another program that can use the embedded preview to handle printing, emailing, etc