This content has been marked as final. Show 14 replies
A quote from Lighroom's help on Virtual Copies:
>Note: In Lightroom, you can have multiple versions of photos by applying different adjustment settings to virtual copies of the
original (master) photos. Virtual copies dont exist as actual photos, but are metadata in the catalog database that store the different sets of adjustments.
However, despite the fact that virtual copies only exist in the catalog, you can export a Virtual Copy and the export process will also create a sidecar file. (if the virtual copy is a raw file and you choose "Original" as the format in File Settings on the export screen)
I'd be interested to hear opinions on the best approach here. In order to have easy access via the library viewer to the original version of a photo, plus one or more edited versions, are virtual copies the best way to achieve this, or is there a better way that I'm not thinking of? If VC's ARE the best approach, do people simply rely on the library to keep their settings, or do they export, or ?
I'm slightly troubled by the idea that my edited version of a photo is not saved in a sidecar file, but rather that it is ONLY saved in the SINGLE library file. This strikes me as a bit dangerous in the long term compared to also having these edits in the sidecar file. Am I worrying over nothing? Is there a better approach? What do other people do in this regard?
Thanks for any further feedback and/or opinions on this.
I agree with you Larry that in the long run it's not a good idea to keep metadata only in the library. So I like to keep my metadata (including adjustments) both in the library and as XMP. I would also like to see the metadata for virtual copies stored to disk as a separate file, just as a backup. Of course the adjustment-info in XMP is only useful to Lightroom and Camera Raw, so we have to rely on Adobe anyway, but the image catalog will at least be more robust if the data is stored both in the database and as separate files.
What I don't understand is why LR doesn't just save the adjustment data for the virtual copies in the sidecar file along with all the other data. It's a negligible amount of data, and it seems like an utter no-brainer to me -- why would you "not" want this data to be saved to the sidecar file? It's data that applies to the original file just like adjustments made to the "original." It's simply a "snapshot" that you can actually LOOK at in the library viewer (as opposed to the develop module snapshots that you HAVE to be in the develop module to see, and that do not allow easy side by side comparisons like the virtual copies do.
I was actually really surprised to discover that the VC data was not in the sidecar -- I always assumed it was until I noticed it was not.
I think that one of the reasons for not having VC data in the sidecar of the original file is that the other metadata like keywords may differ between the original and the VC.
But I don't see any problems with having the VC as a XMP-file only.
> What I don't understand is why LR doesn't just save the adjustment data for the virtual copies in the sidecar file along with all the other data.
What side car should be used? You know, you can delete the master and still have the VC, which is tied to the original. If you do that, should LR delete the old side car and then create a new one? Should it create a separate side car for each VC? That would mean multiple side car files point to a single original file. I'm not sure any of that is allowed in the current xmp spec.
Well the sidecar does contain Develop information for multiple snapshots, so it could do so for VC's. It's just a matter of priorities.
Snapshots can't be separated from the master image the way VCs can.
There is no real reason why snapshots couldn't appear as independent items like VCs (that's effectively how Aperture tries to do it).
The thing is, if storing VC information in XMP was a priority, it could be done, but it would need work to lay out the data structure and do the coding. It just isn't really high priority. After all, Lightroom's partly about escaping from sidecar hell.
Not sure about that - snapshots weren't in sidecars in 1.0, and were added in 1.1. So the single-point of data we have indicates adding more functionality to the xmp data, not less. I may be the only one, but I don't use any LR functionality that isn't stored in the xmp data, as it's my means of syncing to other machines, and my main means of backing up the database.
What's so hard about Import and Export as Catalog? I regularly move work between my PC and my Mac and would be happy if I never saw another sidecar again.
> What's so hard about Import and Export as Catalog?
You have to know what needs syncing.
Sidecars for 2000 images that need syncing are a couple of meg. My main catalog is about 4 gig. I sync over wireless, so the difference between syncing a few meg and a few gig is huge (seconds versus hours).
This is another of several issues that could be solved(improved)if LR produced a proxy jpeg of user controlled size (small or working size)that contained the metadata automatically and paired it up with the RAW original, instead of sidecars, as LightZone does.
In Lightzone one can open the jpeg to continue or change development, or open the Raw and develop it differently, and have a second jpeg (3rd,4th, etc) with the metadata for that version automatically embedded. Virtually any application will see the developed jpeg proxies so they are immediately useful without the hassle of export. LightZone used sidecars in earlier versions, but moved to the jpeg proxies--a vast improvement from several perspectives.
Life with LightRoom would be improved by emulating LZ in this--and several other features, including selective color and regional masks.
>What side car should be used? You know, you can delete the master and still have the VC, which is tied to the original. If you do that, should LR delete the old side car and then create a new one? Should it create a separate side car for each VC? That would mean multiple side car files point to a single original file. I'm not sure any of that is allowed in the current xmp spec.
I'm not clear what the conflict would be. Couldn't the sidecar file be made to reference different "versions" of the same file? It would be a matter of having the sidecar file split up into multiple "sections," one being the "master," and a new, separate section being made for each virtual copy.
If you deleted the original, it would move simply remove the "master" section of the sidecar to reflect the fact that the master was no longer present, but the sections for any remaining VC files would remain.
I realize that it would take some coding, but in the scheme of things, it doesn't seem like all "that" complex of an issue.
Anyway -- those are just some thoughts on this. The bottom line is that the current paradigm seems unnecessarily limited to me.
Thanks for the discussion here,