Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/content/60/9972860/html/smf/Sources/Load.php(225) : runtime-created function on line 3

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/content/60/9972860/html/smf/Sources/Load.php(225) : runtime-created function on line 3
DAM - the Lightroom way-revised 1.2
The DAM Forum
Welcome, Guest. Please login or register.
December 02, 2020, 02:14:55 AM

Login with username, password and session length
Search:     Advanced search
28033 Posts in 5147 Topics by 2903 Members
Latest Member: kbroch
* Home Help Search Login Register
+  The DAM Forum
|-+  Software Discussions
| |-+  Lightroom
| | |-+  DAM - the Lightroom way-revised 1.2
« previous next »
Pages: [1] Print
Author Topic: DAM - the Lightroom way-revised 1.2  (Read 6938 times)
DannyG
Newbie
*
Posts: 37


View Profile Email
« on: April 09, 2007, 07:30:25 AM »

After using LR for a little while I have found the need for a few revisions to my original flow chart. You may down load this at

http://homepage.mac.com/dannyg2/FileSharing5.html

Changes include;
1. Folder Names - I changed the bucket folders in LR with the prefix of "LR", using "RAW" for the bucket folders of the files that are saved on the initial LR import.
2. The other changes have to do with Derivatives...
Within LR...
Because nothing done to an image within LR is permanent, care must be taken to save images that you have worked on and you want a permanent copy. LR does not give you a "save as" or any other option that I know of that would allow for making a new file of an existing image. You must export the file and then re-import it into LR.
Outside of LR...
If you are going to work on an image outside of LR in a program such as Photoshop, I suggest that you export it and not use the PHOTO>Edit in Adobe Photoshop command as this will, in addition to exporting the file, make a copy and put it in the same folder as the original image. The problem with this is that it now adds a photo to a bucket that may already have been backed up or archived. You can always drag it out of that folder and put it in Derivative folder, but you have to remember to do this. I am finding it easier to just use the "Export" command and then bring it into Photoshop. Once work on it is completed, I then save it and import it into LR as a new file and place it in the appropriate Derivative folder.

METADATA - I'm reading of issues with LR and metadata. Especially how using something like Controlled Vocabulary really slows LR down. If images are just kept within LR, some key-wording is redundant to the Collections folders. For now my plan is to use basic key-wording in LR and for those images where I need extensive key-wording for something like stock photography, use an outside program. Hopefully Adobe will improve LR's metadata capabilities in the next revision. Please feel free to add your thoughts on this.

Again, let me say that this is all a work in progress and I share this not only so that others may benefit, but also because the exercise helps me to work out my own system. And the feedback that I have been getting from this forum has been invaluable. (Thanks Peter!) My goal is to use LR as a stand alone program for all my DAM needs. I prefer not to use multiple programs that have to be individually maintained and upgraded and what-ifs such as one of them being discontinued. Hopefully LR and I can evolve at the same time.

Please share you thoughts...

Dan
Logged
reidthaler
Newbie
*
Posts: 34


View Profile Email
« Reply #1 on: April 18, 2007, 09:53:17 PM »


Dan,

Sorry no one's responded to your post.  I too posted a question regarding placement of derivates see: http://thedambook.com/smf/index.php?topic=1987.0

I hope Peter and others will respond as to why not to keep derivatives created by LR in with the archive photos.  I understand your reasoning as to why to export the then open is PS as opposed to Photo edit in PS.  For me, I don't use buckets (gasp!)  I don't back up to DVD.  It just seems to be more time to sort in 6.4 GB (?) chunks, burn, label, catalog, and store files which have a questionable life span.  Instead, I back up to a 2nd internal drive, using SyncBack http://www.snapfiles.com/get/SyncBack.html and then once a week, I back up an external drive I keep offsite at my office.

Thoughts?

Thanks,

Reid
Logged
Niall Horley
Jr. Member
**
Posts: 71


View Profile WWW
« Reply #2 on: April 19, 2007, 03:05:21 AM »

Currently when I am processing files in 3rd party software, I have 2 copies of the derivative, the first is along side the Original which was exported from lightroom and a second copy is place in a derivatives directory. I am currently only importing the derivative which is alongside the original back into lightroom. I am doing this because currently lightroom will not allow images to be stacked across different folders. When Lightroom allows stacks to carry across directories I will change my work flow. Currently I would rather see my panoramic image in a stack with all the files which make up the image.

e.g.
Bucket1\2007\070403\File_3267.CRW
Bucket1\2007\070403\File_3267_PAN.JPG

Derivative1\2007\070403\File_3267_PAN.JPG

Niall


Logged

Niall Horley
www.lifeatf8.co.uk
peterkrogh
Administrator
Hero Member
*****
Posts: 5682


View Profile Email
« Reply #3 on: April 21, 2007, 05:08:05 AM »

Sorry to leave you guys on your own here, but there are a couple of issues.  First, I'm incredibly busy - generally working 7 days a week, 10-14 hours a day.
Second, I just see too many hoops to jump through to make LRv.1 a sound asset manager.  I'm not saying it can't work, just that I don't want to go through all the work to create a system when the application is likely to be on a much shorter update schedule than, say, Photoshop, and I have hopes that a future version will make a number of these workarounds unnecessary.

That said, I strongly caution against mixing old and new work in a directory structure.  It really complicates the backup and restoration procedure.

Of course you *can* use a mirroring software like Reid mentions.  But after recently encountering 3000 overlapped files, the idea of depending on mirroring for backups makes me very uneasy.  It's way too easy to propagate file corruption to your backups, overwriting god backups with more recent corrupted primary versions.

Peter
Logged
lllusion
Newbie
*
Posts: 9


View Profile
« Reply #4 on: June 04, 2007, 03:54:07 AM »

I wonder how stacks and database merging (when it arrives in LR) could be included Danny's workflow.

His workflow requires either file export to buckets/subfolders and re-import or moving the automatically created "_edit" files. It also means using explorer to keep an eye on bucket size.

I like Krogh's bucket idea from his book since it really lends itself to non-HD backup (DVD). But I'm still not sure how to implement it with LR. I'm thinking that my buckets might be:
1. RAW: these have LR refined RAWs
2. LR_Masters: these have raw files edited in LR's develop module
3. Edits: for the auto created "edit in PS files"
4. Output: for files resized and sharpened for printing, web etc..

How could collections and stacks fit in here??
Stacks: probably not at all until they can contain files in various folders. But I'd really like to keep the _edit files stacked with the raws but stored elsewhere.
Collections: I dunno. Thoughts?

Note 1: I like having the bucket subfolders as date ranges, i.e. :
070416-070423
  070416
  070417
  070418
  070419
  ...

Note 2: I've started using Michael Reichmann's suggestion of multiple LR databases--one for each shoot/trip that's stored in the master directory with all the images (sorted into subfolders by each day's date). I rename the database with the date range for the shoot/trip and the name of the trip. I'm not sure how best to back up these databases to DVD.

Yep, things could be easier once LR v1.1 is released but that doesn't take away my need for planning and current implementation.
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!