# Export as a Catalog: Virtual copies problem



## Nortonian (Nov 5, 2017)

Operating System:Windows 10
Exact Lightroom Version (Help menu > System Info):LR Classic CC 7.0.1
Thanks to the guys on here I finally settled on a workflow for using my main computer (desktop) and my laptop. I had been trying with all my photos and my catalog on an external HDD, but when it decides to go a bit flaky, there are some really hairy Adobe messages appear, and with your support I have changed all that to:
Desktop has ALL photos, Catalog and (new to me) Smart Previews. I also upgraded to Classic all round.
Laptop has Smart Previews plus whichever part of my main catalog I have exported from desktop/imported to laptop. After editing on laptop, I have done the Export/Import thing again, in reverse. (Note: I only copy lrcat, not any previews of either kind!)

However, on checking the numbers of files shown in LR's Library, I noticed discrepancies, and it looks to me that any Virtual Copies that I have created don't get shunted across. Is this an error on my part (probably will be!), or is that how it is? Victoria's book lists a long list of pros and cons, but doesn't warn about this (or at least I haven't found it if she has!). I don't really want to export each virtual copy to be a jpeg, as that sort of defeats the object of shoehorning this onto a laptop.

Is it me, or the software?

Thanks in advance
Ian


----------



## Gnits (Nov 6, 2017)

I lost a lot of images in the distant past, because I did not fully understand how Virtual copies worked. If you are using a laptop for travel, create virtual copies and then just copy the folder of your images back to your main computer, then none of your virtual copies will be copied over.  You have to use the import Catalog feature to get both your images an virtual images into your main catalog.

This may not be the case for your, but check your workflow and see if this comment is relevant.

In my personal view the design of the virtual copies is flawed or incomplete, in that it should be possible that the xmp files hold the virtual copies as well or that there is an xmp file for each virtual copy. I am not optimistic that this will change anytime soon, so I have stopped using virtual copies.


----------



## Johan Elzenga (Nov 6, 2017)

The question is indeed how you get the images across. If you use 'Import from Another Catalog' and select the laptop catalog (or a catalog you exported from the laptop), then your virtual copies should come across just fine.


----------



## Wernfried (Nov 6, 2017)

The XMP file has to have the same base name as the image, i.e. the RAW file. Since RAW file is not copied for Virtual Copy you cannot create an additional XMP File.

I think it is the main intention of a *Virtual* Copy that you do not make any physical copy of you image.


----------



## Gnits (Nov 6, 2017)

Wernfried said:


> The XMP file has to have the same base name as the image



Adobe designed the schema.  They could easily have accommodated a design which catered for the original plus any number of Virtual copies.  Having said that, I cannot see them re-visiting this aspect any time soon.



Wernfried said:


> I think it is the main intention of a *Virtual* Copy that you do not make any physical copy of you image.



Possibly, but by having sight of multiple xmps per image the user will be aware there are virtual images to be considered as well as the original raw.

Also, Adobe could have designed the internal schema of the xmp layout to accommodate multiple virtual versions (within a single xmp file). This would have been the best way to go (and may still be possible if Adobe wanted to complete the Virtual Copy functionality with Lr).


----------



## Wernfried (Nov 6, 2017)

XMP is an ISO standard (not Adobe proprietary) and the standard says: "For applications that need to find external XMP files, look in the same directory for a file with the same name as the main document but with an .xmp extension." I don't think the standard supports multiple main documents for one XMP.


----------



## johnbeardy (Nov 6, 2017)

The x in xmp stands for Extensible, and Adobe could certainly have done it. But the key is that the xmp is about communicating with other apps. VCs don't have a clear meaning outside Lightroom and are not written to xmp, while Snapshots are, because they correspond to Bridge/ACR snasphots. 

There is a plugin called Snapshotter than converts VCs to Snapshots.

John


----------



## Gnits (Nov 6, 2017)

johnbeardy said:


> There is a plugin called Snapshotter than converts VCs to Snapshots.



Thanks for the info.  I have designed XML schemas for transferring data between large systems. It was a shock to the mainframe guys at the time to be using what looked like such an inefficient structure. I have traced and removed all Virtual images from my catalog, so no longer have to think about virtual copies. The underlying idea is good and maybe I can return some day as a means of interfacing to other apps of my choice.


----------



## Nortonian (Nov 6, 2017)

From the various thoughts and theories discussed above, it seems this could be a much deeper problem than I realised. I have NEVER seen any warnings about the use of Virtual Copies, from such as Victoria, Laura Shoe, Kelby, Kloskowski - they just seemed a great and simple way of trying out different development methods without needing a degree in software design to use them. Some of you have obviously lost your trust in Adobe, and to be honest, I feel myself going that way too.

However, could it be anything to do with the fact that my laptop only uses the Smart Previews, not the original files? Many of you are mentioning sidecar files and their association with the original photo file - I've never actually looked at at the "form" of a Smart Preview filename, but I'd be surprised if it looked anything like the filename of a photograph.

Thanks for your efforts so far,

Ian


----------



## PhilBurton (Nov 6, 2017)

Gnits said:


> Adobe designed the schema.  They could easily have accommodated a design which catered for the original plus any number of Virtual copies.  Having said that, I cannot see them re-visiting this aspect any time soon.



XMP stands for *Extensible *Metadata Platform.  Adobe could easily add additional metadata fields to support virtual copies.


----------



## Johan Elzenga (Nov 6, 2017)

I believe we're going a bit off topic here. Virtual copies have nothing to do with XMP *files*. They only exist in Lightroom and so it makes sense that they are not written to an XMP file, but only to the catalog. They should come across when you use 'Import from another Catalog', which was the original question.


----------



## clee01l (Nov 6, 2017)

Nortonian said:


> From the various thoughts and theories discussed above, it seems this could be a much deeper problem than I realised...Some of you have obviously lost your trust in Adobe, and to be honest, I feel myself going that way too


Note Johan's comment above #11.  There is nothing wrong with creating and using Lightroom within the Lightroom framework as it was intended. Adobe utilizes XMP files for the exchange of Adobe data between Adobe apps.  Too many people want to use XMP files as an insurance against losing data in the Lightroom Catalogs.  It was never intended to be used this way.


----------



## PhilBurton (Nov 7, 2017)

clee01l said:


> Note Johan's comment above #11.   Too many people want to use XMP files as an insurance against losing data in the Lightroom Catalogs.  It was never intended to be used this way.



Clee,

Is that desire to use XMP as insurance not a valid need, that should be addressed?  With additional information written into the XMP file, it could serve that purpose quite well.  Since XMP is now an ISO standard, it is used by many applications other than Adobe.  See the XMP column here Comparison of metadata editors - Wikipedia

Phil


----------



## clee01l (Nov 7, 2017)

PhilBurton said:


> Is that desire to use XMP as insurance not a valid need, that should be addressed?


All of the information in ALL of the XMP files is in the LR catalog and every catalog backup.  Only some of the metadata about the cataloged images is captured in the XMP. Even disregarding the missing Virtual Copy develop cdata, there are many more elements that are only found in the LR catalog file.  It is far easier to make and keep Catalog backups than it is to make, update and keep up  with thousands of tiny XMP files scattered all over the filesystem. That desire for insurance is misappropriated when applied to the XMP.


----------



## Johan Elzenga (Nov 7, 2017)

PhilBurton said:


> Is that desire to use XMP as insurance not a valid need, that should be addressed?


No, I don't think so. It's better to educate people than to facilitate improper use of XMP. People who use XMP files as a backup strategy may be inclined not to make catalog backups, or less frequently. That's going into the wrong direction. XMP is never going to include _everything_ that's in the catalog, because some things (collections, smart collections, publishing services) are catalog-based, not image-based. Why try to use XMP rather than simply make a backup of the real thing?


----------



## Gnits (Nov 7, 2017)

The original post was in relation to virtual copies. Fundamentally, virtual copies are a good idea, but be aware of their limitations. If you use virtual copies on say a travel laptop, then your folder of images will not contain any virtual images. Backing up your catalog is the only way to protect your virtual images. You can export your virtual images, but then (ahem) they are no longer virtual.

I suggest discussing the detail of the xmp files should be another thread.  I do not plan to start such a discussion unless the current architecture changes.


----------

