Photo replace bottle neck

[Sam]

Recently I shot an event and decided rather than process all the images and upload print ready images to upload basically proof jpgs and to process replace the proof images with final print images only upon an order.

While this does work....................replacing each print individually is really very inefficient. The upload / replace time is much longer than a simple upload time, and the necessity of doing this one at a time means I can't leave and do other things.

Is there any way to implement a batch replace type process? How are other event photographers dealing with this?

Sam

[aktse]

Is there any way to implement a batch replace type process? How are other event photographers dealing with this?
Not on Smuggy's end.... Buy Star*Explorer.

You upload with it (easier that way too) and then it has the ability to auto-replace with the newer files.

[jfriend]

I Agree. Use Star Explorer. You just check a preference that says when you're uploading a file of the same name as something you already uploaded, it should do a replace instead of an upload. You can do hundreds/thousands at once.

[Sam]

I Agree. Use Star Explorer. You just check a preference that says when you're uploading a file of the same name as something you already uploaded, it should do a replace instead of an upload. You can do hundreds/thousands at once.

OK, so can I replace multiple images with images having the same #, but with say PR added to the file name?

If I can't differentiate between the proof image and the print ready image, I wouldn't know how to handle that.

Sam

[jfriend]

OK, so can I replace multiple images with images having the same #, but with say PR added to the file name?

If I can't differentiate between the proof image and the print ready image, I wouldn't know how to handle that.

Sam I don't know exactly how the replace photo logic identifies whether you're uploading a new photo or a replacement photo (whether it's only filename or uses metadata). You can ask the author in the StarExplorer thread (http://www.dgrin.com/newreply.php?do=newreply&p=1117637).