I actually just upgraded to Vista x64 with a new desktop (pre-installed) a couple months ago. I've run into a few compatibility issues with older hardware and software, but nothing too serious. (The biggest bummer was the Nikon Coolscan V, but I still have my old desktop with XP, so no worries.) And with 6MB RAM available, Lightroom really zips along! Vista has been perfectly fine otherwise, and seems just as stable as XP -- I have no regrets upgrading.

-Martin

Since LR 2 will be 64-bit compatible, according to Adobe it will be able to access RAM >3GB (if running 64-bit Vista/XP with appropriate CPU) and give a good speed bump. So the real question is: will having >4GB speed up LR for your standard 6-12MP camera RAW files, or is 4GB (and thus 32-bit XP/Vista) enough? As far as I've found, the folks at Adobe don't mention anything about the 64-bit version being good just for extra large files. But maybe that's marketing.

Martin

Thanks for the replies. I knew I should have come here earlier -- would have saved me a couple weeks worth of hand-wringing!

The HP I'm considering comes with four internal bays, with the option of RAID 0 or 1 right out of the box (which I don't think I'll do), so I assume it can handle the load.

So as long as one had external backups of the internal drives, there's no reason to think that an archive structure started on internal drives was a bad idea? So no one would roll their eyes at, for example:

Computer:
1: programs and working files
2: archive_001
3: archive_002
4: archive_003

JBOD Box:
1: working files backup
2: archive_001 backup
3: archive_002 backup
4: archive_003 backup

+ the usual assortment of DVDs and externals living offsite.

Or, I suppose, to be even more safe:

Computer:
1: programs and working files
2: RAID mirror of 1
3: archive_001
4: archive_002

JBOD Box:
1: working files backup
2: boot drive backup
3: archive_001 backup
4: archive_002 backup

+ DVDs etc.

My head hurts.

Martin

Okay, this is going to sound like a real boneheaded question, so please go easy.

One advantage of having archive files on a separate HD is that the HD doesn't have to "spin up," reducing wear and tear and opportunities for drive failure. I've always imagined these "archive drives" to be external drives that were turned off when not in use.

But what about extra internal drives? Can they be safely used in a JBOD setup? Are these getting wear even when they're not actively being accessed, just because the computer is on? For example, would it be dumb to have a machine with four internal drives configured thusly:

C: programs and working files
D: archive_001
E: archive_002
F: archive_003

and then switching to externals (JBOD case or whatever) when F fills up? Or is it best to just keep archive files physically separated from the computer?

Thanks,
Martin

I'm actually going through the exact same agony at this moment. Except I'm thinking of pulling the trigger in the next day or two.

One of the great things about 64-bit Vista, Lightroom, etc. is that it allows you to access over 4GB RAM (up to 128GB, depending on the version). Being able to run Lightroom with 8GB RAM sure seems like a compelling reason in itself to make the switch.

Peter: are you suggesting that, working with 5-15MB DNGs etc., having >4 GB RAM wouldn't significantly speed things up in Lightroom? If that's the case, then sticking with 32-bit would certainly be easier (and I could still use my Nikon CoolScan). But if there's a chance of getting LR to really move. . . . It's so slow on my current system I can hardly stand it.

Martin

Thanks, Peter -- great suggestions. I initially resisted separate collections for just this reason -- not only easy to lose, but it also makes the entire catalog less portable. But using a keyword (in addition) might just do the trick -- hadn't thought about that before. And since Lightroom allows you to exclude specified keywords when exporting derivatives, there's no keyword pollution, to boot. Bonus.

Use of the Rights Usage field would be good to just "stamp" the image, although I'm not sure how that would help in a DAM sense (at least in LR).

Thanks,
Martin

Thanks for the replies. Glad to hear RM vs. RF "discussions" don't creep in here -- you never know these days!

I'm currently using Lightroom (switched over from an Access database), but I haven't yet had to manage the two types of images -- I've only dealt with RM in the past. (So I haven't dealt with this at all, let alone as part of a DAM solution.) I'd like to add some RF to the mix (for real generic stuff), but got stymied when I started thinking about the DAM stuff, and keeping track of which was which. I suppose I could use a separate LR catalog for each, but that seems cumbersome, and of course doesn't allow me to manage everything at once.

John -- so maybe in LR, one might simply have a RF collection and a RM collection? It might be nice -- heck, it *would* be nice -- if I could just look at an image (or its metadata) and if it was RF or RM, rather than see what collection it was in. Hmmm. . . .

-Martin

Hi Everyone,

Does anyone have a DAM strategy for keeping track of which images in their stock catalog are rights-managed vs. royalty-free? Obviously one could hijack IPTC fields such as labels or ratings, but that's less than ideal. Any thoughts?

Thanks,
Martin

P.S. Let's PLEASE not turn this into a RM vs. RF debate -- both are out there, and have strong places in the market. Let's admit that and move on. 

Hi All,

So I'm refining my CV, trying to make it as logical and easy to deal with as possible. One of the areas that I'm struggling with, though, is including enough keywords to maintain a logical (and easy to use) CV without "polluting" the field with keywords that may not be relevant to others. (All of the keywords in my IPTC keywords field are used both by my website and other stock agencies for anonymous searching, so everything that goes in there is (or should be) relevant.)

Here's a perfect example: plant and animals. Organisms are already set up with a hierarchy which would be easy to use in a CV: Family, Genus, Species. So one could imagine the following hierarchy:

--plants
----Cactaceae [family name]
--------Carnegiea gigantea, saguaro [species]
--------Opuntia bigelovii, teddy bear cholla
----Polemoniaceae
--------Phlox diffusa, spreading phlox

So adding the family name aids tremendously in organizing species in the CV, but does including the family name -- which most people would never use for searching -- constitute keyword pollution? Is this unnecessarily obsessing over things that really don't matter much? (I've been known to do that.)

Your thoughts?

Thanks!
Martin

Okay, I got it -- I hadn't considered looking for images outside of an asset manager; that would definitely change things, and I can see your point. I shoot stock, and usually the only way I look for images is by file name or keywords. I'll have to think about it some more, but that probably won't be much of an issue in my case.

Thanks!
Martin

Thanks for the responses, everyone.


Peter, I'm not sure I follow you here -- why would you need a 10 digit number as a trailing unique identifier? If I didn't plan on shooting more than 10,000 images/day, wouldn't a four digit number suffice?

Thanks again,
Martin

Hi Folks,

I’m in the renaming stage of my DAM set-up, and no matter how many times I re-work it, it seems like Peter’s method is the most universal, and overall best solution. Except, perhaps, for one aspect.

For me, the complicated nature of the file names (lots of numbers) seems like it could easily lead to errors if you (or a client) aren't careful. One way to simplify the name would be to use a sequential number at the end (re-started each day), rather than the camera-generated number:

Beebee_070314_2567.dng

becomes

Beebee_070314_0001.dng.

To me, the latter name seems easier to read and work with. Yes, as Peter points out in the book, that will lead to a large number of files with _0001 as the trailing number. But is that so bad? Since the name incorporates the date, it remains unique. The name also gains some semantic value (albeit marginally useful), in that it tells you that Beebee_070314_0023.dng was the 23rd image shot on March 14, 2007 – the camera-generated number has no inherent meaning.

So what do you think? Is there something I’m missing, or does this seem like an equally good naming scheme?

Thanks!
Martin

Hi Peter,

I fill out the IPTC location fields (as appropriate), but I also include detailed location info in the keywords field to allow for anonymous searches (on my website, and other stock websites).

Interesting thought about just copying the info from the location fields themselves, though -- that would potentially save a step, depending on how specific one wanted to be.

Martin

Hi Folks,

So I’m refining my controlled vocabulary, and came across something that I’m spending way too much time trying to decide how to approach. (This is probably going to be for Lightroom, but that shouldn't matter.)

For locations (I shoot stock), say I have a shot from Yosemite National Park, and I’d like to include the keyword phrase “U.S. national parks.” So the full keyword set (for location) would be: "Yosemite National Park, U.S. national parks, California, USA." Here are two potential hierarchies for the CV:

(A)
USA
   California
      U.S. national parks
         Yosemite National Park

(B)
USA
   California
U.S. national parks
   Yosemite National Park

Hierarchy (A) benefits from having everything nice and tidy together; on the downside, the phrase “U.S. national parks” would have to be repeated under every state, bloating the CV a bit.

Hierarchy (B) benefits by having all the parks together, thus avoiding replicating the “U.S. national parks” phrase; on the downside, the specific location is fractured – I can’t just pull in the entire location at once.

So what do you think? A or B? Or is there a C that you think might be even better?

Thanks!
Martin

Hmmm. Bummer about Bridge scripting. My VB skills are non-existent, and there are no xmp files (I've been using a workflow that didn't involve xmp sidecars -- Nikon Scan/Capture directly to Photoshop). I guess I'll have to look for another solution, such as ExifTool, but that's going to require learning perl. . . .

Thanks anyway,
Martin