Do you use virtual copies as derivatives?

[jljonathan]

I'm just starting out with LR and had previously been using Expression Media for cataloging. In the past, when making derivative files ie. Masters, Print Masters etc., I would always "save as" or duplicate to a new "real" file which was cataloged in it's own Derivative catalog. Now, using LR, am I just supposed to make virtual copies for all these uses, and keep them in the one catalog? Or, does anyone actually duplicate files?
Thanks
Jonathan

 

[Denis Pagé]

Welcome to Lightroom forums Jonathan! ...and to Lightroom itself by the way.

Duplicating originals in Lightroom can be a hassle to manage. I mostly use Virtual Copies for B&W versions, different crops or different "effects".

 

[Brad Snyder]

Jonathan, welcome. Yes, that's the envisioned method. The main point of contention, is that VCs cannot currently be stored in an image's external XMP (i.e. sidecar or embedded), which is a deal breaker for some folks' workflows. They generally employ some sort of 'snapshot' workaround. Snapshots are saved in external XMP. If external XMP doesn't matter to you, then you'll be fine. If it does, you may have to keep your thinking cap on. Every time this question arises, we usually have a lively discussion of the pros and cons.

 

[jljonathan]

Brad
Can you give an example where external XMP would matter to someone, and where I would find a discussion of this item plus the sidecar workaround.
Thank you
Jonathan

 

[dj_paige]

[quote author=jljonathan link=topic=8414.msg56986#msg56986 date=1258478521]
am I just supposed to make virtual copies for all these uses, and keep them in the one catalog? Or, does anyone actually duplicate files?
[/quote]

The normal Lightroom workflow does not involve making copies. Normally you wouldn't duplicate a photo because Lightroom can show you both your original and the edited version.

The normal workflow in Lightroom is to edit your photos and not export the photos, until you need them for some non-Lightroom purpose.

Virtual copies are usually used for situations where you need multiple edits (e.g. crops, B&W version, high contrast version ,etc.) of a photo.

 

[Brad Snyder]

Jonathan,
Lr always stores changes to photos in its internal database. This includes both parametric image adjustments (the changes to the image) and changes to metadata, e.g. IPTC, keywords, ratings, labels. In addition Lr enables and tracks various collection membership, sort parameters, view management things like that. Basically, everything Lr can do is stored in that database.

A subset of those parameters (in Adobe's XMP data format) also can, optionally, be stored directly with the original image files. The implementation of this depends on the filetype of the original image file. Proprietary format camera raw files are treated as read-only, and the XMP data is stored in a per-image auxiliary file, termed a sidecar file. Standard file types, JPG, DNG, TIF, and PSD, have provisions for storing the XMP data internally in a standard format.

Principally this is important, because this optional storage method provides a safety net of associating important image data with the individual images. This will potentially permit recovery from a fubar situation where the Lr catalog database is corrupt and unrecoverable. In the future, it may also enhance interchangability of adjustment data between programs, but currently is only standardized amongst Adobe applications, principally Lr and the ACR component of Photoshop.

This practice is a perennial topic of debate among Lr enthusiasts. My general personal preference is to save XMP data, but I'm not fanatical about it. The primary points of contention are the complexity of managing extra files and a frequently noticeable performance hit due to the extra read/write disk activity involved in the process, particularly with large catalogs. (Large tends to be a fluid concept based on your particular system's CPU and I/O capabilities)

 

[jljonathan]

Brad
You stated: My general personal preference is to save XMP data, but I'm not fanatical about it. The primary points of contention are the complexity of managing extra files and a frequently noticeable performance hit due to the extra read/write disk activity involved in the process, particularly with large catalogs.
How does one do this? I will only be using standard files types in LR, so if I edit with only virtual files, then all the data for the file is only stored in the LR database. Is there a way to push this into the dngs? Or, how do you save the xmp data?
Thanks again
Jonathan

 

[MarkNicholas]

[quote author=jljonathan link=topic=8414.msg57'97#msg57'97 date=1258678328]
Brad
You stated: My general personal preference is to save XMP data, but I'm not fanatical about it. The primary points of contention are the complexity of managing extra files and a frequently noticeable performance hit due to the extra read/write disk activity involved in the process, particularly with large catalogs.
How does one do this? I will only be using standard files types in LR, so if I edit with only virtual files, then all the data for the file is only stored in the LR database. Is there a way to push this into the dngs? Or, how do you save the xmp data?
Thanks again
Jonathan
[/quote]

I only shoot RAW and do NOT use DNG files. If you use VC's and want them backed-up in an xmp file then you can save your VC as a snapshot. When you save the xmp file this snapshot is saved with the master (the VC itself is not saved and you would have to recreate it from the snapshot).

I understand that with DNG and Jpeg etc... the xmp data is stored within the DNG and Jpeg file itself and that a separate xmp file is not created.

You need to have the "write to xmp file" check box ticked in the preferences otherwise everything is just saved in LR's data base. When you create a new catalogue this option is unchecked by default !!

 

[Brad Snyder]

As Mark says, there's a check box in the Catalog Settings preference dialog to enable autowriting of the XMP. You can also trigger a manual write by selecting multiple images in Grid view, and press Crtl-S. There's a menu item for this operation as well, under the Library module > Metadata pull down.

If you select autowrite, expect a temporary performance hit as Lr starts working its way thru your entire catalog, initiating individual file writes. As I said above, depending on your system capacity, there may be an ongoing performance hit as well.