[br.davidson]

I use Lightroom, so moving files around on my harddrive after import can be a minefield. My current organization scheme is "My Pictures / Year / [Date] - [Description]" with RAW files and JPEG's all in the same folder. This works great for Lightroom, but not so great for Picasa or other services that "scan" my hard drive looking for photos. I'd rather use Lightroom only for RAW files and use other software for JPEGs.

I want to change the file structure to be "My Pictures / RAW / Year / [Date] - [Description]" with only RAW files and another "My Pictures / JPEG / Year / [Date] - [Description]"

The problem is if I move the files around, the changes in Lightroom will be lost and that's many many hours of work down the drain. Any suggestions for a clean / efficient way to make this change? If my question doesn't make sense, let me know.

[jatrax]

Changes will not be lost. The changes are in the database. After you move the files you will need to go into Lightroom and reconnect them. LR is fairly intelligent about that but it can still be tedious. But it will work, I have done it. You can also move the files from within LR if that is easier. Just go to the directory panel and add your new directory and move from there.

Also, just in case, write out any metadata changes to the files before moving them. That keeps the keywords, tags and title etc with the files then as well as in the LR catalog.

[br.davidson]

Thanks for the reply. How do I write out the metadata changes to the files?

Also, if I do write out the metadata changes, do they stick with the RAW file (I'm using .dng format) no matter what?

[alohadave]

The problem is if I move the files around, the changes in Lightroom will be lost and that's many many hours of work down the drain. Any suggestions for a clean / efficient way to make this change? If my question doesn't make sense, let me know.

Move the files from inside Lightroom. It will track the new locations and no additional work is required.

[jatrax]

Thanks for the reply. How do I write out the metadata changes to the files?

Also, if I do write out the metadata changes, do they stick with the RAW file (I'm using .dng format) no matter what?

I think the command is ctrl-S but there is also a menu item METADATA>SAVE METADATA to FILE. Select all the files and hit Ctrl-S. Be prepared to take a nap if you have a lot of files.

If you use DNG, the metadata is saved into the file, other RAW formats it saves it as a "sidecar" file. Which is a file with the same name that contains the metadata. This was the primary reason I decided to use DNG, no sidecar files.

[emalvick]

If you save metadata changes to the DNG's, you also have the option of updating the preview (or perhaps it is automatic with the metadata update). Regardless, the actual settings will stick with the DNG files, but you'd only really be able to use that information in Lightroom and/or ACR in the future. Other software can't (or should I say won't) read the develop settings from the metadata and put them to use.

[br.davidson]

Thanks for the replies, everyone. I think with a mix of saving sidecar files (for non-DNG raw files) and moving the files within Lightroom I should be able to get things organized the way I want.

[dmfw]

Why use Picasa for JPG only? Picasa will read my RAW & JPEG files, even if they are mixed in a single folder.

Also, I use LR and I only use Picasa to only fast view or upload files. LR is nice but slow vs. Picasa. Stay in LR for your editing of RAW & JPG.

[br.davidson]

@dmfw: Picasa is just an example, but for web stuff and backups I'd like to separate my JPEGs and RAWs.

[Marc Sabatella]

I think it important to make a distinction here. I find nothing even remotely interesting about separately RAW files from JPEG files per se. There is no inherent advantage whatsoever in doing that. What *is* valuable is separating *camera original files* (which may often happen to be RAW) from *derivatives generated from those camera original files* (which may often happen to be JPEG). That is indeed valuable.

[emalvick]

I think it important to make a distinction here. I find nothing even remotely interesting about separately RAW files from JPEG files per se. There is no inherent advantage whatsoever in doing that. What *is* valuable is separating *camera original files* (which may often happen to be RAW) from *derivatives generated from those camera original files* (which may often happen to be JPEG). That is indeed valuable.

That tends to be a matter of preference and DAM strategy. I agree with what you state being potentially valuable, but I think the biggest value is being ABLE to distinguish originals from derivatives if you want to separate them. Otherwise, I have confidence in my DAM and file naming convention that I can easily split things up as I need to. However, as far as my DAM goes, it works most efficiently if originals and derivatives are stored together (software and usage benefit).

[br.davidson]

That tends to be a matter of preference and DAM strategy. I agree with what you state being potentially valuable, but I think the biggest value is being ABLE to distinguish originals from derivatives if you want to separate them. Otherwise, I have confidence in my DAM and file naming convention that I can easily split things up as I need to. However, as far as my DAM goes, it works most efficiently if originals and derivatives are stored together (software and usage benefit).

I think I just have too many DAM files The distinction RAW vs original is interesting since I did not always have a camera that saved RAW files so JPEGs can be originals too.

Here's an exact use case example: I have ~80GB of photos, but only about 10GB of that are JPEGs. I back up my whole drive, but I'd like to upload only the JPEGs to a cloud service such as Google Drive, DropBox, SkyDrive, etc. The cloud updaters "watch" certain directories, but they don't have file filters to only work with JPEGs. If I have a split in my directory structure under ../Pictures/ for ../Originals/ and ../JPEG/ then I can point my backup software to ../Pictures/ and my cloud service to ../Pictures/JPEG/

Could you explain your DAM strategy and why it's more efficient for the originals and derivatives to be stored together? I keep mine together right now too, but I'm seeing limitations to that strategy.

[emalvick]

Could you explain your DAM strategy and why it's more efficient for the originals and derivatives to be stored together? I keep mine together right now too, but I'm seeing limitations to that strategy.

It's a matter of software, I think. The program I have has a versioning mechanism built into it as does Lightroom. The software is flexible enough that derivatives can be stored anywhere if you tell it that. However, if you have the derivatives in the same folder, you can tell it that is the setup and it will save itself from looking in all possible folders. The result is that when it looks for derivatives, it only has to look through a limited group of photos instead of all photos. In most operations having derivatives elsewhere wouldn't matter too much, but everytime files are added or updated, the software checks to see whether the new files are versions or originals to other files. It's a bit faster if the derivatives are kept in the same folder... Actually, the software is still fast if you keep derivatives in subfolders, too.

I believe LR works similarly, although I don't use it for DAM, so I'm not sure exactly.

More technically, my original images all have a similar file name scheme regardless of the camera and extension. They tend to have something like YYYYMMDD_CAMID_####.EXT The #### is the file number from the original camera file name and the CAMID is a fixed 5 character section to identify the camera it came from and the date comes from the EXIF date time original field. The derivative files are similar but the end of the file name has some ####-V##.EXT type field where V is actually a variety of characters to help identify the version (A = typical shot, B = black and white, C = heavily cropped, H = Hdr, P = Panorama, etc). As a result, I can instantly find all photos that are versions by the "-V01" file name and originals don't have that. My DAM software could also go by date and time, but I find that to be a bit slow and problem ridden as some software can change EXIF date and times, and reading EXIF for each and every file is a little more computational power than just reading the file names.

I do see why separating the files could be important to your setup. I don't use a cloud service, so that may make me rethink my system. That was why I made the earlier reply about being ABLE to separate originals from derivatives. In my case, I could use a file renaming utility that can handle regular expressions to select all files with a "-V00" type pattern and move them into a new folder scheme. You are essentially looking to use the same folders as before but rather add one level at the top. A good advanced file renamer should be able to grab all of your jpeg files and "rename them" such as

JPG\Orig_Folder_Tree\File_Name.jpg

You just need to find one that works and put a little bit of time into making it work for you. It seems the more features in such a utility, the more difficult they are to use.

[br.davidson]

Thanks for the info, emalvick. I'm impressed at your organizational skillZ. I have my folders well organized, but I haven't done much to keep my filenames consistent. The benefit of your naming convention is pretty obvious even without the "bonus" info about cropping and HDR. It's easy to implement a new convention from now on, but going back and changing existing files is scary and tedious. I guess that what backups are for, though. Thanks again for the advice.

[Marc Sabatella]

That tends to be a matter of preference and DAM strategy. I agree with what you state being potentially valuable, but I think the biggest value is being ABLE to distinguish originals from derivatives if you want to separate them.

Right, I didn't mean to imply I thought one must do this, just that *if* one is going to perform a separation, it's original versus derivative that has more value than raw versus JPEG. It only happens that original versus derivative may turn out to be raw versus JPEG in practice.

BTW, the main advantage as I see it to doing this separation isn't lessened by any sort of version control. It's a simple backup issue. By keeping originals separate from derivatives, it means you can More easily back up your originals and never have to update those backups, as the folders containing those originals will never change even if you subsequently generate or regenerate derivatives.