The DAM Forum
Welcome, Guest. Please login or register.
May 18, 2013, 10:57:55 AM

Login with username, password and session length
Search:     Advanced search
Jan 9, 2012
John Beardsworth's new Lightroom site
Lightroom Solutions
27960 Posts in 5113 Topics by 2914 Members
Latest Member: imthedamstar
* Home Help Search Login Register
+  The DAM Forum
|-+  Workflow Discussions
| |-+  High Volume
| | |-+  Turnaround time for a large shoot
« previous next »
Pages: [1] Print
Author Topic: Turnaround time for a large shoot  (Read 4120 times)
andris
Full Member
***
Posts: 149


View Profile WWW
« on: November 13, 2007, 09:23:56 PM »

Can I ask you guys a simple question?  How long does it take you to turn around a high volume shoot?  I'm talking about 5000-8000 images from a day of shooting, and with a large percentage of those similar enough to batch adjust in camera raw.  What do your clients expect, what do you do when you have a rush job, and at what point do you tell them they're just going to have to wait?

Lately I'm feeling bogged down by my workflow.  I know the workflow is effective, and has certainly taken pressure off me to remember all the steps...but I feel like the turnaround time is suffering a bit.  I convert to DNG on the front end with IIP.  This generally isn't a big time suck...I usually manage to get it started the night after returning from a shoot, and it runs into the early morning when no one was going to touch the images anyway.  After that, though, I feel like I have three major delay steps:

1)  Building bridge caches - Man, this takes forever and isn't even predictable.  Bridge 2.1.100 sometimes appears to just stop building the cache, and won't continue without intervention.  Granted, these folders (one for each of the day's shots) are large:  400-800 images.  It's obviously important to look at a whole shot together when rating, so I can't think of a good way to subdivide for better performance.  We had to switch to Photo Mechanic to allow the photographer to rate at a reasonable speed...she's not one to be patient with a slow app, and tends to bang on keys.  I still have to build the cache before raw adjusting.

2)  Updating full size DNG previews - I don't see a lot of people talking about this, but this can take a long time when adjusting with ACR in batches of 20-40.  Really breaks up the flow...it's slow enough to make you want to do something else, but fast enough that you need to keep coming back to see if it's done.

3)  Importing into iView/XM - I love the benefit of churning out proofs from the embedded full size preview...super fast.  Still, to get to that point, I first have to import the whole shoot into iView.  This takes about 1.5 seconds per image, which adds up to another long wait.

All of this is fairly easy to accomplish over several days.  When the client calls and tells you the deadline has been bumped up and they need to see the shoot immediately, though, it's tough to rush the process.  In one case, I sucked the rated, but unadjusted full size previews out of the DNGs using Breeze Browser before even catalogging.  This works, but means the client gets unadjusted proofs in which case you probably would have been better shooting jpg.

sigh,

Andris
Logged
peterkrogh
Administrator
Hero Member
*****
Posts: 5682


View Profile
« Reply #1 on: November 14, 2007, 04:00:36 PM »

Andris,
My aproach to speed this up would be as follows:

• Don't convert to DNG on the front end.  This will speed the ingestion process, and make the ACR work much faster.

• Have IIP divide the images into subfolders of no more than 300 images per folder.  You can look at these all at once after an initial pass at ratings by using the filter panel.  This will speed up Bridge.

• As you convert to DNG after adjustment in ACR, you can set iView to auto-inport the files.  THis makes it a single batch process.

• Try RapidFixer for quick adjustments of a lot of images.

• If you only need to make batch adjustments of the images in Bridge/ACR (and not lots of individual adjustments), then you might consider doing your close examination in iView, since it gives a pretty speedy 1 to 1 view once the DNGs have been imported.

Peter
Logged
andris
Full Member
***
Posts: 149


View Profile WWW
« Reply #2 on: November 20, 2007, 12:57:01 PM »

Sorry to take so long to get back to this...been too busy lately.  I'll have to do some real world timings, and see which works better/is less frustrating.  I had originally decided to convert to DNG on the front end because it seems like not taking advantage of that first night after the shoot where the images are just sitting untouched seems like a shame.  If I can leave our server chunking away converting to DNG all night it seems like a good use of time.

Also, given that our camera raw defaults often make it possible to batch out proofs with no further adjustments I think converting to DNG first may still be saving us a little time in the end.  I would love to place IIP -> DNG -> iView in one big automatic step on the front end that all happens the first night after the shoot.  I could then have the photographer do the rating in iView.  Problem is, she hates having to hold down ALT to apply star ratings.  We currently have her working in PhotoMechanic.   If she rates after the images have already been cataloged, I have to sync the annotations into the catalog...which is surprisingly time consuming.  Seemed almost as time consuming per image as importing.

With bridge performance, have you found that viewing multiple subfolders with a total number of images >300 is faster than viewing a single folder containing the same images?  If so, this is great: I hadn't thought to try that.

I've thought about RapidFixer, and may give it a shot...does it rebuild the full size previews?  If so, does it allow you to continue working on more images while it's rebuilding others?

Re: Batch adjustments via iView:  This is a great way to work, as long as I can remember to rebuild the items after adjusting.  I've had some problems with strange out of memory errors.  I usually work in batches of 20-30 images and choose 'Open in Photoshop CS3' from the right click menu. 

When I start working for the day, clicking 'done' in ACR after each batch and waiting for the full size previews to rebuild works great.  After working for a half day or so, though, I'll suddenly get a 'There is not enough memory to complete this operation' error after clicking 'done,' and ACR just quits.  This causes me to lose my raw tweaks for that batch.  I had thought there was some memory leak in the way iView was passing files to Photoshop/ACR.  I get the error on all subsequent batches until I restart the system.  Is this out of memory issue unique to my setup?

Thanks again for the advice,

Andris
Logged
peterkrogh
Administrator
Hero Member
*****
Posts: 5682


View Profile
« Reply #3 on: November 21, 2007, 10:33:12 AM »

Andris,
>With bridge performance, have you found that viewing multiple subfolders with a total number of images >300 is faster than viewing a single folder containing the same images?  If so, this is great: I hadn't thought to try that.

Not sure if this will help.  Give it a try and report back.

>I've thought about RapidFixer, and may give it a shot...does it rebuild the full size previews?  If so, does it allow you to continue working on more images while it's rebuilding others?

When I use RapidFixer on DNG, I switch off rebuild preview in ACR preferences.  Otherwise it rebuilds on each click.  Very slow.

>After working for a half day or so, though, I'll suddenly get a 'There is not enough memory to complete this operation' error after clicking 'done,' and ACR just quits.  This causes me to lose my raw tweaks for that batch.  I had thought there was some memory leak in the way iView was passing files to Photoshop/ACR.

Hmmm, I would not expect a memory leak in the passing.  This might be an ACR cache issue.
Do you use task manager (PC) or Activity monitor (Mac) to check on resource allocation? I'm finding a strange memory problem on my MacPro.  The RAM usage for both Photoshop and Bridge will spike to 16 million terabytes, which is more memory than I though I had in the machine.

Peter
Logged
danaltick
Hero Member
*****
Posts: 1616


View Profile WWW
« Reply #4 on: November 28, 2007, 09:34:53 PM »

Peter,

Wow!  16 million terabytes!  I think that may be more memory than exists on the planet..LOL!

Couldnt' resist that one ;-).

Dan
Logged

WindowsXP, ImageIngester Pro, RapidFixer, IVMP 3, ACR4, Photoshop CS4, Controlled Keyword Catalog, Canon EOS50D
andris
Full Member
***
Posts: 149


View Profile WWW
« Reply #5 on: November 28, 2007, 11:50:17 PM »

Yeah, I noticed that too.  I just figured that's how Peter stays so far ahead in the DAM business:  16 million terabytes of RAM.

Andris
Logged
Pages: [1] Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!