100% Cloud Ready!

ebook ad big

Digital Asset Management – The X-Equals Way – Part 2 of 4

Wed, Dec 17, 2008

Lightroom, Tutorials, Workflow, X=Series

folder_files_insert4

Continuing on from Part 1 of our series, we’ll use our data definitions and storage considerations set forth in Part 1 to build a flexible and easy to manage folder structure …

We’ll also get into some of the file naming conventions that we put in place for naming folders, although we’ll be getting into more detail on these conventions in Part 3.

For future reference, you can bookmark the +FOLDERS AND FILENAMES – A PRELUDE post for a nice clean table of contents for all 4 posts in the series.

{note: for complete details on any features described herein please download the Lightroom 2.0 manual or use the Lightroom 2.0 Adobe Live Docs Repository – we love them both! And remember, all tool, panel and module references are always in BOLD for easy reference as you map our workflow to Lightroom}

No More Than 5 Levels Deep

This was a big requirement for our system. We don’t want to, and our clients don’t want to, comb through folder after folder to get to a file. Coming from the root level of any drive resource, nothing should be allocated more than 5 folders deep.

One important point to keep in mind: we HATE spaces, but_we_LOVE_underscores. It’s a basic rule – use an underscore when you feel the urge to use a space. We also won’t allow any fancy folder or filename sequences with things like camera type or Xx and Yy style demarcations that are usually best tucked into the metadata.

So let’s get right into the meat and potatoes. We’ll just build this out as we go – starting with folders first.

First we’ll make our two main folders that are located on every production and archival system:


{figure 1}

archive – includes Lightroom Catalogs and RAW files

The archive folder houses files that would be akin to a box of negatives along with specific collections of negatives that in the past would have been placed into slip sheets for organization. A Lightroom catalog with RAW images is the present day paradigm shift based loosely on this type of system.

dev – includes production (otherwise known as derivative) files (JPG, PSD, etc.) created from content originated in the archive folder

If we were to lose our entire dev folder for whatever reason, we could recreate that content from originals in the archive folder – especially since XMP and or DNG metadata will hold our non-destructive edits.

Next we’ll create a minimal set of folders within the archive folder based on our definition above:


{figure 2}

cat – includes all Lightroom catalogs, based on organizational or storage space needs

dng – includes all original RAW files in DNG format

{note: If you shoot NEF, CR2, etc., a corresponding folder would be added in for each RAW format.}

In addition to the cat and dng folder, as this data grows we have found that we need to include some folders to break down the contents. The easiest rule to apply to this (and many others areas of organization) is to use a basic identifier for your folder. We always stick to using these types of identifiers:

  1. Who
  2. What
  3. When
  4. Where

When it comes to datestamping I prefer YYYYMMDD format which turns October 25th, 2008 into: 20081025. The primary sort for this would be year, and the secondary month, and so on. We’ll dig deeper into automating this in Lightroom in Part 3.

Here is a sample of how we would use these elements for various projects (ie. Lightroom Catalogs) stored in the archive folder:


{figure 3}

2008 - approximately 75% of clients we work with break down their work by year, and it’s a natural time period for breaking up large on-going projects

cat_2008 – many photographers like to keep all their images in one large catalog that grows over the course of the year

cat_20080302_zoe_rae_birthday – breaking out a catalog for a specific occasion is another approach we see for one-off projects on a smaller scale (less than 1,000 images)

cat_20080801_new_york – separating catalogs based on geography is another approach to keeping order for many traveling photographers

cat_20081001_prada_fall_campaign – for fashion, advertising, or commercial photographers, we have seen this approach work very well for client-centric projects

{note: don’t like breaking down by year? No problem! Drop the 2008 folder, and move all the cat_ folders to the root of cat, or substitute 2008 for your favorite who, what, when, and/or where identifier}

That does it for the cat folder. Now let’s turn our focus to the source image folders. Our preferred source image (RAW) format is DNG, although one can easily substitute NEF, CR2, etc. as required. You’ll see a lot of similarities in the structure of the dng folder as it relates to the cat folder(s):


{figure 4}

2008 - same as with catalogs, breaking down by year is a natural time period for breaking down source images

{note: don’t like breaking down by year? No problem! Drop the 2008 folder, and move all the dng_ folders to the root of dng, or substitute 2008 for your favorite who, what, when, and/or where identifier}

The remaining folders represent individual shoots based on a datestamp and identifier. In our example above we broke down each days shoot into its own folder. For jobs that stretch over more than one day, you would take a single day’s shoot such as:

dng_20081001_prada_fall_campaign

and extend that to be:

dng_20081001_20081025_prada_fall_campaign

At this point, we’ve completed all setup work for both catalogs and RAW source images in the archive folder.

Let’s move on to the dev folder where we organize all our production files (otherwise known as derivative files) created from, or related to, content located in the archive folder(s). There isn’t much change in how we set up the dev folder, because its structure closely mimics the dng folder. Remember, simplicity and scalability are our goal.

The dev folder {figure 1} functions in much the same was as our archive folder, with the important difference that our dev folder holds production data – project (PSD, TIFF, JPEG, Lightroom Catalogs) and/or image files (RAW, NEF, CR2, XMP, DNG, etc.) that require immediate access on an ongoing basis.

Let’s look at a fully populated dev folder {figure 5} and how it relates to the projects we setup in the archive folder:


{figure 5}

As we can see above, all derivative files created from, or based on, our source images will have corresponding folders for easy reference in the dev folder. Whether you create jpg’s for your online gallery system, tif’s for your pre-press job, or psd’s for your multi-layered masterpiece – there’s something for everyone in this structure.

What’s next … ?

In our next installment, we’ll walk through an example workflow using our folder structure(s) and an easy to use file naming scheme which we’ll anchor into Lighroom.

Tuck our RSS Feed into your favorite reader for IMMEDIATE updates, or, if email is more your style, signup to receive the x=blog directly in your inbox.

|Brandon Oelling
x=photography+consulting – technology. leadership. commitment.

Check out some related posts!

  1. Preset Maintenance – staying organized and secure
  2. Good to the last Drop – Photoshop Droplets
  3. Film to Digital – Scanning Essentials 101 – Part 2 of 2
  4. Digital Asset Management – The X-Equals Way – Part 4 of 4
  5. Digital Asset Management – The X-Equals Way – Part 3 of 4
  6. Digital Asset Management – The X-Equals Way – Part 1 of 4
  7. Digital Asset Management – The X-Equals Way – A Prelude
  8. Total Workflow – Your one-stop source
  9. Have XMP, will travel
  10. Virtual Copies … making the commitment

, , , , , ,

100% Cloud Ready!

ebook ad big

4 Comments For This Post

  1. Erik Says:

    Just want to say this tutorial / overview is great! I can’t wait for the next chapters.

  2. Brandon Oelling Says:

    Thanks for staying tuned … things get REAL interesting once we anchor Lightroom’s Import dialog into the structures!

  3. Mark Levison Says:

    Very interesting series but why break things into folder by filetype? Modern operating systems have search and sort that should be fast to allow you to filter on JPG vs PSD vs TIFF. This would mean that folders could be used for something with more semantic meaning.

    It would also mean that you don’t have to maintain parallel folder structures which as we in the software development world know is right pain to keep in sync.

  4. Brandon Oelling Says:

    We have found that when we do go to the archive it’s for a specific job where we know which files and client we need to retrieve. Adding the file type prefix on the folder takes any guesswork out of this type of search.

    I have attempted to point an indexing tool at my network drive to Amazon S3 but the indexing of that mount point is so slow it’s rendered unusable.

    Perhaps there is a metadata indexing tool I am not aware of for S3 but it would also need to access the Adobe DNG metadata tucked into my RAW files for it to be usable.

    For local searches of our Production Data, we might use OS-level searching but when you point any of those tools at 500,000+ files they fall apart IMHO. Since metadata is tucked into all the work semantic searches would and are done outside (ie. Bridge, Lightroom, etc.) of any sort of OS provided tool. I personally think Windows and OSX’s native search tools are miserable both from a performance and result management standpoint.

    We don’t maintain any parallel folder structures per se. They mainly exist as repositories for the required formats we deliver to clients (PSD, JPEG, etc.) Well over 90% of our production is in Lightroom – the derivative folders are just targets for our exports from LR.

    Lastly, I agree with you in the world of software development this is an issue – but not applicable here. We’re working in a much different model. I have yet to go the a PSD or JPEG folder for the purposes of syncing, etc.

    Thanks for you thoughts Mark … !

Leave a Reply

100% Cloud Ready!

ebook ad big

Camera gear we love ...
Studio Essentials ...