• Welcome to the Lightroom Queen Forums! We're a friendly bunch, so please feel free to register and join in the conversation. If you're not familiar with forums, you'll find step by step instructions on how to post your first thread under Help at the bottom of the page. You're also welcome to download our free Lightroom Quick Start eBooks and explore our other FAQ resources.
  • Stop struggling with Lightroom! There's no need to spend hours hunting for the answers to your Lightroom Classic questions. All the information you need is in Adobe Lightroom Classic - The Missing FAQ!

    To help you get started, there's a series of easy tutorials to guide you through a simple workflow. As you grow in confidence, the book switches to a conversational FAQ format, so you can quickly find answers to advanced questions. And better still, the eBooks are updated for every release, so it's always up to date.
  • 21 February 2024 It's Lightroom update time again! See What’s New in Lightroom Classic 13.2, Mobile & Desktop (February 2024)? for all the update news. It's mainly new cameras, new lenses and loads of bug fixes in this release.

Sync Fresh migration into Lr Classic from Lr Desktop/Cloud

ml_lrcl

New Member
Premium Classic Member
Joined
Feb 8, 2024
Messages
19
Location
USA
Lightroom Experience
Intermediate
Lightroom Version
Cloud Service
Lightroom Version Number
Lightroom Classic version: 13.1
Operating System
  1. macOS 14 Sonoma
Hi all - I'm contemplating a move from full Lightroom Desktop/mobile Cloud to Lightroom Classic just due to the feature set differences on the desktop applications. I would still use mobile for image capture (then sync via the cloud down into Classic); I would also use mobile also for editing of some synced collections out of Lightroom Classic. I had some questions/things I want to confirm, and help would be appreciated. I can’t find the exact answer to these on other similar threads or in the Classic eBook re sync—apologies if I am just searching poorly!

I currently have about 13GB of images in the Lightroom Cloud. I’d be looking at a new/empty catalog to start with in Classic.

Priorities (in approx order) are maintaining:

- nondestructive edits on original files (i.e. a jpg isn’t re-rendered, and I can start where I left off on edits no matter the file type);
- exposure/camera/date-time and all GPS-related metadata (OK if city/state manually entered fields disappear);
- albums (I know album folders will not come over in any method);
- keywords;
- I know people recognition won't transfer; that's fine.

This is my understanding of the options and a quick summary of what I have gathered I’d get/lose with each, for my situation; please correct me if I’m wrong or losing anything else relevant:
  1. Lightroom Downloader. Nobody seems to really recommend this option.
  2. Export all images as Original + Settings from Lightroom Desktop into local folder(s). Import into Lightroom Classic. Use folder structure and/or keywords to re-create albums as collections in Classic. Only losing albums and album folders; no other metadata or anything else is lost.
  3. Create new blank Lr Classic catalog, turn on sync, and let all originals sync down from the cloud. Lose keywords and album folders . No other metadata is lost, and existing albums themselves do come through as synced collections. Copies of originals stay available in cloud unless manually removed (useful e.g. for mobile access to originals rather than just a smart preview).
Basically, if the sync works properly in #3 (see below), it seems like it comes down to choosing #2 for keyword preservation, or #3 for album preservation and leaving originals accessible in the cloud.

Questions:

1 - Any reason in my case to consider Downloader?

2a - Once everything is in local folders for Lightroom Classic import, would I need to erase the cloud via Lightroom Web before turning on sync in Lightroom Classic to avoid a nightmare of duplicates?

2c - Assuming 2a is yes... am I correct that I lose the ability for mobile devices to access/export images based on the originals? I.e. they can only access potentially lower resolution smart previews as a starting point for export and sharing, and there's no real way of pushing the original back into the cloud once it's gone. (I realize this is different for images captured on mobile devices, where the originals end up in the cloud/accessible.)

3a - Are Cloud-applied keywords still visible/modifiable in Cloud products (mobile, web)? I.e. I won't totally lose them on the initial sync—they just don’t come down into the Classic catalog data.

3b - Any tips on avoiding issues on an initial download/sync at the outset? The last time I tried to work with Classic sync (~6mo ago), I similarly started with a lot of photos in the cloud to bring into Classic. The initial download/sync got stuck with unending syncs of metadata/edits up and down on some photos coming down from the cloud (and I wasn't making changes). Particularly seemed to be like an issue with photos with AI based masks. I did some troubleshooting but was unable to resolve, and it left a mess for mobile (or Lightroom Desktop) trying to access a good number of photos. Waiting for edits, or missing files/sync errors altogether. I gave up on a Classic based system, moved back to Cloud fully, and spent a some of time still clearing up the cloud issues the process had caused, one or two photos at a time.

3c - As a guard against getting mired in sync issues, and making it possible to give up/go back to Cloud-only easily, could a backup copy of the Lightroom Desktop .lrdata file serve as a snapshot to re-populate a freshly erased cloud? I have Lightroom Desktop set to store all originals locally, so everything is in there. I’m guessing this would not work, but maybe someone’s seen it happen. Otherwise, I know I'd need to use Downloader or export Originals + Settings ala #2 to get (an imperfect) local backup.

Thanks!
 
Your post deserves a somewhat lengthy answer which I don't have time for right now but will get to you later today unless someone else jumps in. However, some of your ascertations are correct and some are incorrect. Also your methodology is a bit flawed so hold off doing anything untill folks on this web site have a chance to chime in.
 
I'm not sure what @Califdan is seeing wrong with the proposed methodology, but no doubt he will explain in due course.

A brief set of answers to your questions:

1. Downloader.....don't even think about going there.

2a - that would be sensible, not doing that could result in every image in the LrC catalog getting a virtual copy, with the VC being synced and the masters unsynced. Not ideal, so cleaning out the cloud before starting to sync the LrC catalog would be best.

2c - yes, that would initially be the case (assuming you have re-synced all the LrC images back to the cloud, which puts Smart Previews in the cloud). You could, however, re-import all the LrC images back to the cloud (using LrD or LrW) after you've synced all the LrC images as SPs to the cloud, that will "upgrade" the cloud Smart Previews to full originals again, and LrC will be made aware of that.

3a - yes. You can also get the LrC keywords into the cloud if you save metadata to the images in LrC BEFORE you sync those LrC images to the cloud (that's a one-way, one-time thing).

3b - not really....I've used this procedure several times (750GB of cloud data), and it's always worked (though yes, it can be very frustratingly slow). If it bogs down completely, you should be able to trash the LrC catalog and start again.

3c - no, "saving" the local cloud catalog is a waste of time and disk space, AFAICT there is no way to restore a local library backup and have it replace the master catalog in the cloud. But you don't need to use the Downloader, the cloud catalog shouldn't be affected by syncing problems when trying to generate an LrC catalog from the cloud, as I said in 3b you should be able to reset and start again as many times as it takes to get the LrC catalog working.
 
Thanks for jumping in Jim. I must have read the intial post too quickly and was questioning the use of "Local", but in this methodology that is fine. I was contemplating a different strategy of bringing the images into LrC through the sync process which would automatically leave originals in the Cloud, would satisfy all of the OP's requements and would create LrC Collections from the LR albums which the OP didn't think was possible.

In your original post you indicate that the reason you'd like to incorporate LrC in your workflow is for additional features. Should I take this to mean that the amount of Adobe Cloud storage you are using) is not a factor in your thought process?

If cloud srorage is indeed not something you are concerned about then follow what @Jim Wilde said. or request instructions on the other method I mentioned.

In your comments you mention the desire for full size files in the Cloud app. What exactly are you doing in the Cloud apps that would require full size images?
 
My recommendation is Option 3. It may take a little longer since you are limited to internet bandwidth speed. WRT images and edits you lose nothing and all of your images remain in both places. While it is true "Folders" to not transfer to collection sets. You should be able to recreate the "Folders" as Collection Sets easy enough once the Albums have synced to become LrC Collections..

I use Lightroom and Lightroom Classic together (just not on the same machine) To do so, I only like the hierarchal keywords available in LrC and have ignored any keywords done in Lr Cloud. There is not a Sensei option or equivalent in LrC. I think the "local" feature in Lightroom is too immature to be included into any workflow that includes both Lr and LrC.
If you continue to import your new images into the Adobe Cloud and from there sync to LrC, you should have no problem having all of your full size images in the Adobe Cloud. I use Adobe Portfolio integrations which come easily from a Lightroom Album , Portfolio always brings the image into the Portfolio webspace as a Smart Preview. And 2560px on the long edge is more than adequate.

I have had zero sync issues using Lr Mobile as a front end for LrC. However the most I have needed to sync at one time is probably 2-300 48MP RAW images and I have gigabit ethernet speeds all the way into my Mac Studio.
 
Thanks for the detailed info and advice, all! It’s incredibly appreciated to make sure I have a very clear handle on this before I start, including the nitty gritty details. Just helps me know what I’m getting into.

First, to be clear, definitely not thinking about using the “local” tab in LrD - in my very brief time playing with it, I also found it pretty immature and wouldn’t use it. When I refer to “local” or “local files” I just mean the files sitting on the desktop SDD/HDD that LrC references for its catalog. Sorry for any confusion there.

Some follow-ups/clarifications based on your thoughts, if you don’t mind taking the time:

In your original post you indicate that the reason you'd like to incorporate LrC in your workflow is for additional features. Should I take this to mean that the amount of Adobe Cloud storage you are using) is not a factor in your thought process?

Space is not a general concern, no, and not at all the reason for considering this. It’s really just the LrC vs LrD overall feature set beyond the actual image processing/manipulation piece—even when it comes to just basic usability/interface items that ultimately are a reflection of LrC’s greater maturity.

In your comments you mention the desire for full size files in the Cloud app. What exactly are you doing in the Cloud apps that would require full size images?

Primarily export/sharing out of the mobile apps, in large part back into Apple Photos. Nearly everything I shoot lives in Photos to start, whether from Halide or Apple Camera. I pull select batches into Lr for editing, but usually want to get full res edited versions back into Photos even if I also retain them in Lr for further editing/preserving HDR work. The mobile apps export back into Photos more seamlessly than either LrC or LrD (which, AFAIK, both require export to disk/import into Photos). As part of that process, Photos also adds helpful Photos-specific metadata that automatically flags the app the images came from. Just overall, I’m generally on mobile a good deal.

I was contemplating a different strategy of bringing the images into LrC through the sync process which would automatically leave originals in the Cloud, would satisfy all of the OP's requements and would create LrC Collections from the LR albums which the OP didn't think was possible.

Is what you’re referencing here different than Option 3 in terms of how to approach the sync process?

2c - yes, that would initially be the case (assuming you have re-synced all the LrC images back to the cloud, which puts Smart Previews in the cloud). You could, however, re-import all the LrC images back to the cloud (using LrD or LrW) after you've synced all the LrC images as SPs to the cloud, that will "upgrade" the cloud Smart Previews to full originals again, and LrC will be made aware of that.

OK, I think that makes sense, and it is very good to hear it’s a possibility! Just to clarify the specifics of how this would/wouldn’t work, though:

- Would this only work properly if the SPs for images were already synced to the cloud from LrC? I.e. once LrC synced SPs for X images into the cloud, and they were thus visible in LrD, the process would be to import those original X image files into LrD(/LrW) via the normal “Add Images” functionality. LrD would recognize them and associate with the SP, not see them as duplicates. Then, LrC syncs. Again, rather than seeing the originals as either new images or duplicates (creating VCs), it just is aware the originals are there and doesn’t add anything to the LrC catalog. Is that understanding all correct?

- On the other hand, it sounds like importing originals into the cloud via LrD before SPs for those images are synced into the cloud by LrC does run the risk of duplicates/VCs, per the theory behind 2a.

3b - not really....I've used this procedure several times (750GB of cloud data), and it's always worked (though yes, it can be very frustratingly slow). If it bogs down completely, you should be able to trash the LrC catalog and start again.

I didn’t realize that trashing the LrC catalog and starting again was a reasonable option if this did happen—very good to know. I assume that trashing the catalog means it’s safe to trash the Mobile Downloads folder (or massive individual file) simultaneously to really start fresh. I’ll also keep in mind that it needs a really long time to work out the sync, perhaps beyond the initial apparent download of the original files themselves.



Finally, two other questions based on the above:

- Does the cloud-based facial recognition still work on the originals (or even SPs?) that Cloud apps have access to? It just won’t be possible to sync that categorization down to LrC in any way. I know LrC has its own facial recognition, but I haven’t had as good experience with it in past testing. (Obviously, since pretty much everything lives, there’s facial recognition there too.)

- If I did decide keywords were important to save from the current cloud, it sounds like #2 is the only option? There’s just no (reasonable, at least) workaround or additional step to get keywords down from the cloud into LrC initially/ever with #3.

Generally, though, it sounds like the consensus is #3, but do want to fully understand #2 (and generally, adding originals to the cloud) before making the final decision. Thank you for your time. Again, I know it’s a lot of super detailed stuff, but I’m much better going into something with a complete handle on things!

Michael
 
OK, I think that makes sense, and it is very good to hear it’s a possibility! Just to clarify the specifics of how this would/wouldn’t work, though:

- Would this only work properly if the SPs for images were already synced to the cloud from LrC? I.e. once LrC synced SPs for X images into the cloud, and they were thus visible in LrD, the process would be to import those original X image files into LrD(/LrW) via the normal “Add Images” functionality. LrD would recognize them and associate with the SP, not see them as duplicates. Then, LrC syncs. Again, rather than seeing the originals as either new images or duplicates (creating VCs), it just is aware the originals are there and doesn’t add anything to the LrC catalog. Is that understanding all correct?

Yes, that's all correct.

- On the other hand, it sounds like importing originals into the cloud via LrD before SPs for those images are synced into the cloud by LrC does run the risk of duplicates/VCs, per the theory behind 2a.

Yes, you've got that straight....basically, when originals in LrC have not been synced and those originals are added to the cloud vial one of the Lightroom apps, those originals will automatically be scheduled to sync down to LrC. However, LrC's standard duplicates detection process will kick in and, determining that the new sync files are duplicates of images already in the catalog, it automatically creates VCs of those originals (rather than overwrite the originals). It that situation it's the VCs that are flagged as the synced files in LrC, not the masters.

I didn’t realize that trashing the LrC catalog and starting again was a reasonable option if this did happen—very good to know. I assume that trashing the catalog means it’s safe to trash the Mobile Downloads folder (or massive individual file) simultaneously to really start fresh. I’ll also keep in mind that it needs a really long time to work out the sync, perhaps beyond the initial apparent download of the original files themselves.

The cloud doesn't know where the synced originals are stored in the LrC catalog. It just knows that it is currently syncing with catalog xxx and that so far nnn images are synced. At any given point you can tell Lightroom to sync a different catalog, so it will forget about the old catalog and what images were synced, and will instead start to download the entire cloud contents to the new catalog, which LrC will store in accordance with the existing LrC preferences. So if starting over, make sure you either set a new downloads location or, if planning to use the same location as previously, clear out the contents of that older location first before starting sync in the new catalog.

- Does the cloud-based facial recognition still work on the originals (or even SPs?) that Cloud apps have access to? It just won’t be possible to sync that categorization down to LrC in any way. I know LrC has its own facial recognition, but I haven’t had as good experience with it in past testing. (Obviously, since pretty much everything lives, there’s facial recognition there too.)

Yes, it will work on originals and SPs, but you are correct....it doesn't sync with LrC.

- If I did decide keywords were important to save from the current cloud, it sounds like #2 is the only option? There’s just no (reasonable, at least) workaround or additional step to get keywords down from the cloud into LrC initially/ever with #3.

Generally, though, it sounds like the consensus is #3, but do want to fully understand #2 (and generally, adding originals to the cloud) before making the final decision. Thank you for your time. Again, I know it’s a lot of super detailed stuff, but I’m much better going into something with a complete handle on things!

It is possible to get the existing keywords (and location data) down from the cloud into the new LrC catalog by using a combination of #2 and #3, but it initially doubles the amount of local disk space that would be needed. Basically, export using originals + settings from Lightroom to a single folder on a local hard drive. Then set a different folder to be the sync download location in the new LrC catalog (don't use the default location, set a new location but don't set one of the date-based folder structures), then enable sync. Once everything has downloaded, right-click on the folder containing the synced downloads, select "Update Folder Location" and in the resulting browser select the folder containing all the files exported from Lightroom. LrC switches to use the new folder, and as it contains all the same files there's no "missing" files issue. Then in LrC select all the synced files in the Library Grid and go to Metadata>Read Metadata from Files. That should read and catalog all the metadata, including keywords and location data.

Once that's done you might want to reorganise all the images in that single folder into smaller folders, and/or change the sync download preferences to sync new files into a date-based folder structure.

I'm a bit pressed for time right now, but I'll write more later on how I deal with the issue of maintaining originals in the cloud using a hybrid Lightroom/Lightroom Classic workflow.
 
I'm a bit pressed for time right now, but I'll write more later on how I deal with the issue of maintaining originals in the cloud using a hybrid Lightroom/Lightroom Classic workflow.

If you have time/desire to add more about how you maintain the hybrid workflow, that's amazing, but thank you—this is already incredibly helpful. I feel like I've got a much better grasp on things.
 
If you have time/desire to add more about how you maintain the hybrid workflow, that's amazing, but thank you—this is already incredibly helpful. I feel like I've got a much better grasp on things.
I'm not Jim, but I maintain a hybrid workflow.
Here's what I do. I was first a LrC only user. I sync'd a few collections to the Adobe Cloud. When I decided I wanted to see most of my full size images in the cloud, I increased my 20Gb plan to 1TB and used the migration function in Lr Desktop to migrate my master Catalog to the Adobe Cloud. This placed full size images in the cloud and replaced and Smart Previews that were already in the cloud.
Next, and syncing Collections became Lr Albums. For future imports I begin by importing camera card images into Lr using my iPadPro. In LrC all of my imagers are stored using one of the default date named folder schemes. In LrC preferences, on the Lightroom Sync tab, I set the sync destination to be these same date named folders. So no matter where the image originates, it lands in the right folder based on capture date.

In Lightroom, I may preliminarily edit some of the imported images, but I do not delete any rejected image until I can delete them immediately in LrC. Instead I mark them rejected (X). Because of the incompatibilities of Keywords in Lr and LrC, I don't add keywords to image in Lr. I wait until I can do that in my master LrC catalog.

While In Lr (usually while traveling) I may create new albums for sharing on Lightroom for the Web. I use Lr albums for easy integration into my Adobe Portfolio website.

My LrC workflow is driven by smart collections and color labels play a big part in determining the process state of images. My "To Be Worked" images are imported and assigned a purple label when imported into LrC using the import dialog. The are automatically assigned to a smart collection that collects images with a purple label. Lr does not support color labels. So image synced from the Adobe Cloud first appear in LrC with no label. I have had to amend my "To Be Worked" Smart Collection to include either purple labels or no Labels

Below is the Color Label Set that I use in my workflow.
Screenshot 2024-02-08 at 3.43.45 PM.png
 
Is what you’re referencing here different than Option 3 in terms of how to approach the sync process?
3) Create new blank Lr Classic catalog, turn on sync, and let all originals sync down from the cloud. Lose keywords and album folders . No other metadata is lost, and existing albums themselves do come through as synced collections. Copies of originals stay available in cloud unless manually removed (useful e.g. for mobile access to originals rather than just a smart preview).
Yes it is Option 3, Option 3 is based on letting the sync process copy originals from LR/Cloud to LR/Classic. This preserves most metadata as you mention, edits made in LR/Cloud and produces LrC Collections for each LR/Cloud Album. As you state, I don't believe that the LR/Cloud folders (parents of albums) become LrC Collection sets. You lose Keywords. This process in itself leaves originals in the cloud and has orginals on your local hard drive for LrC.
 
My LrC workflow is driven by smart collections and color labels play a big part in determining the process state of images. My "To Be Worked" images are imported and assigned a purple label when imported into LrC using the import dialog. The are automatically assigned to a smart collection that collects images with a purple label. Lr does not support color labels. So image synced from the Adobe Cloud first appear in LrC with no label. I have had to amend my "To Be Worked" Smart Collection to include either purple labels or no Labels

Thank you! It’s particularly helpful to have some good ideas about actually leveraging those features that I’m thinking about moving to LrC for as part of adapting to the workflow itself.

It sounds like you generally don’t add images to LrC directly anymore, but generally are going through LrM. If you do add something to your Lightroom ecosystem on the Mac, do you import to LrC, then add the original to LrD once the smart preview has synced up, as Jim helped outline earlier in the thread? Or, do you just add images to LrD on the Mac, thus starting with the original in the cloud as you do with LrM and getting the image dropped into the automatic LrC-organized dated folder in the LrC catalog?
 
It is possible to get the existing keywords (and location data) down from the cloud into the new LrC catalog by using a combination of #2 and #3, but it initially doubles the amount of local disk space that would be needed. Basically, export using originals + settings from Lightroom to a single folder on a local hard drive. Then set a different folder to be the sync download location in the new LrC catalog (don't use the default location, set a new location but don't set one of the date-based folder structures), then enable sync. Once everything has downloaded, right-click on the folder containing the synced downloads, select "Update Folder Location" and in the resulting browser select the folder containing all the files exported from Lightroom. LrC switches to use the new folder, and as it contains all the same files there's no "missing" files issue. Then in LrC select all the synced files in the Library Grid and go to Metadata>Read Metadata from Files. That should read and catalog all the metadata, including keywords and location data.

Once that's done you might want to reorganise all the images in that single folder into smaller folders, and/or change the sync download preferences to sync new files into a date-based folder structure.

Got it, this makes sense. I tested it with just a few local files successfully to make sure I understood (put originals in one folder, added to LrC, added some metadata, then put them in another). I think I'm OK on local disk space to handle this initially!
 
It sounds like you generally don’t add images to LrC directly anymore, but generally are going through LrM. If you do add something to your Lightroom ecosystem on the Mac, do you import to LrC, then add the original to LrD once the smart preview has synced up, as Jim helped outline earlier in the thread? Or, do you just add images to LrD on the Mac, thus starting with the original in the cloud as you do with LrM and getting the image dropped into the automatic LrC-organized dated folder in the LrC catalog?
Most of the time I use my iPadPro to import, even from home and always when traveling. I do this for images that I want to manage full size in the Adobe Cloud. My iPadPro is convenient downstairs and my MacStudio is upstairs in my office, I can import a camera card full of images on the iPadPro and by the time I am upstairs on my Mac Studio, the images are already catalog in LrC.

Recently, I imported directly into LrC some 50,000 images that were from my late wife's accumulated image collection efforts. Most of these I am reviewing only to delete. They were already on an external drive attached to the Mac Studio. A lot were duplicates or JPEG crops of the same photo. I really have no need for these images to be in the Adobe Cloud, so Importing using LrC was most practical. Since I started with LrC before adopting the Adobe Cloud, I chose not to put all of my older image into the cloud as full size. And my master LrC catalog file will always be my master source for full size images.
 
If you have time/desire to add more about how you maintain the hybrid workflow, that's amazing, but thank you—this is already incredibly helpful. I feel like I've got a much better grasp on things.
My version of the "Hybrid Cloud Workflow" differs somewhat to that used by Cletus, which isn't an issue. There's no standard hybrid methodology, it's up to all of us who venture into that space to figure it out for ourselves (and if you put 10 people into a room and asked them to define their preferred workflow, chances are you'd get 11 different answers!).

My own workflow has evolved over the years since the first introduction of the Adobe Cloud during the LR5 cycle., and it has changed as newer features were added to the cloud ecosystem. The problem for me is that I wanted some of those cloud features, but I also wanted to stick with LrClassic as my main image editor. In particular, I now want:

a) All images in my personal catalog to be available wherever I might be, on whatever device I had with me or had access to, with the least effort to achieve that. Prior to the advent of Adobe cloud I had used a lash-up of different solutions based on Publish Services and FTP to iPad/iPhone and large-scale exporting "for posterity", so I was keen to see if the Adobe cloud could be an effective solution, despite some apparent shortcomings.
b) I now want the images to be in the cloud in the original form, i.e. Smart Previews from LrC are of little interest. I want to be able to share/export at full resolution, and I also want to use the album sharing function whilst giving the end-user the option to download full resolution jpegs (not the small 2048px jpegs that are downloaded from Smart Previews).
c) I also want the end-user to be able to have access to my keywords and location data, as well as the usual EXIF and IPTC data.

Having originals in the cloud, with existing keywords and location data, would also allow me to consider using the cloud album sharing as a means to pass on my image collection to any members of my extended family that might be interested in them. I know there would be no interest in the original raw files, but some of my albums which they could download in full-resolution jpeg format, and which would include the keywords and location data, are likely to be of interest to some of my younger relatives.
The originals with all associated metadata in the cloud would also provide a useful Classic catalog and image recovery option (which indeed I have used in the past).


What all that resulted in is a workflow that developed over a period of time. In order to achieve the goals listed above I needed to find a way to get my Classic and Cloud catalogs fully in sync, and then to keep them that way. To do that I currently use the following workflow:

1. In the main, I import all new images into Classic first, stored into a "holding" folder. All images in the main library are stored in one of the standard date-based folder schemes, and my LrC preferences for Lightroom Sync downloads is set to store the images into the same date-based folder scheme.
2. The new imports are processed in LrC (though I have the option to sync them as smart previews to the cloud if I want to do some work on an iPad outside my study/house). Fully processed as regards metadata: copyright, title, caption, keywords, GPS, location, etc.
3. Once the processing is done, I select the images and save metadata to XMP, then I convert the raw files to DNG. This DNG conversion is crucial (see later).
4. Then I remove the images in the "holding" folder completely from the LrC catalog (taking care not to delete from disk!), and import them into LrD or LrW.

Once imported and synced to the cloud, they automatically return to earth and are stored in my LrC library in the expected date-based folders, complete with all metadata including keywords and location data (and as I use a hierarchical keyword system in LrC, the keywords of the downloaded images are slotted into the correct place in the hierarchy). This is why I convert to DNG before removing the images from LrC in step 3 above. It wouldn't happen if I imported the original proprietary raw files into LrD, but because the metadata is embedded into the XMP portion of the DNG files, LrC reads and catalogs that data when downloading the files from the cloud. In addition, the fact that the images are DNG allows the end-user of shared albums to have the keywords and location data available to them when the album is downloaded....that wouldn't be the case if the images were proprietary raw, even if the keywords are in the cloud. And being DNG, a full catalog recovery is possible from the cloud.

There are obviously some things I need to adapt should I ingest images from LrM, but using my variation of JB's smart collection workflow it's easy to cater for such things. Tweaking keywords after the images have been synced to the cloud can be a PITA, so I do try to avoid major surgery....but adding/removing keywords is easy enough to do in both places. Also I need to remember to save metadata in LrC should I change images in any way (including edits) after syncing, which re-uploads the full original file again.

I'm only a hobby photographer, rarely do I import images in large volumes (airshows a few of times a year might run to 3000 per day, but that's about it), and I never have any deadline pressures apart from my own. So I can indulge myself in setting things up the way I want, and keeping them that way, but I obviously wouldn't recommend my method to anyone else.
 
This is again very helpful in understanding how different pieces fit together as I think through, as you say, what will end up probably being my own specific flow.

b) I now want the images to be in the cloud in the original form, i.e. Smart Previews from LrC are of little interest. I want to be able to share/export at full resolution, and I also want to use the album sharing function whilst giving the end-user the option to download full resolution jpegs (not the small 2048px jpegs that are downloaded from Smart Previews).
c) I also want the end-user to be able to have access to my keywords and location data, as well as the usual EXIF and IPTC data.

I think I'm a little unclear on which metadata gets exported/displayed in different sharing situations. From a quick bit of testing what comes out when, at least before LrC is in the mix, it seems like:

- Sharing/exporting out of Cloud software e.g. LrD exports the title/caption/keywords that I applied in LrD/Cloud.

- Downloading a full size jpg out of a Lightroom web album created via LrD does not seem to include keywords (or oddly title/caption—though the LrD-applied caption does appear in the web gallery interface).

I assume that means the web gallery download is going to use whatever's saved to the cloud original file metadata from LrC (and/or whatever's actually on the file in the first place when it's imported, as you describe with your DNG+XMP workflow). And, for a full restore from cloud, it's probably also just going to use what's written to the cloud original. So, that's why it's important to keep the metadata actually written to the cloud originals via LrC.

Is that all right?

Also I need to remember to save metadata in LrC should I change images in any way (including edits) after syncing, which re-uploads the full original file again.

I'm not 100% sure what you mean by the full original file getting uploaded again... Am I right in putting it this way:

Once the image is synced down into LrC, if you edit the metadata/keywords and then explicitly save those changes to the local original file, those changes get synced up (by uploading the original file again?). That means the cloud original has those metadata changes actually in the file itself. And, again, this is useful because the web gallery export and doing a full catalog recovery rely on the actual file metadata itself, rather than how LrD/LrM/Cloud stores/reads keywords.

As for edits—do you mean actual Lightroom adjustments to the image itself? I thought those did automatically sync to the cloud... but, perhaps they're not written to the file metadata fully and live in some other Cloud database. And you need them written to the file for cloud restore.

It wouldn't happen if I imported the original proprietary raw files into LrD, but because the metadata is embedded into the XMP portion of the DNG files, LrC reads and catalogs that data when downloading the files from the cloud.

Once imported and synced to the cloud, they automatically return to earth and are stored in my LrC library in the expected date-based folders, complete with all metadata including keywords and location data (and as I use a hierarchical keyword system in LrC, the keywords of the downloaded images are slotted into the correct place in the hierarchy). This is why I convert to DNG before removing the images from LrC in step 3 above. It wouldn't happen if I imported the original proprietary raw files into LrD, but because the metadata is embedded into the XMP portion of the DNG files, LrC reads and catalogs that data when downloading the files from the cloud. In addition, the fact that the images are DNG allows the end-user of shared albums to have the keywords and location data available to them when the album is downloaded....that wouldn't be the case if the images were proprietary raw, even if the keywords are in the cloud. And being DNG, a full catalog recovery is possible from the cloud.

Do you know how important it is to go into LrD with a separate XMP + DNG outside of the case of starting with a proprietary raw?

E.g. I know that you can write both Lightroom edit settings and keywords to the metadata of other kinds of supported files (HEIC, JPG, or even a DNG that was shot as a DNG) without the separate XMP file, via LrD > export original + settings. If that file is imported into LrC from a local disk, LrC picks up the metadata/keywords and Lightroom adjustments properly.

So I would have assumed that with a supported format, any edit + keyword metadata could be properly read (on first sync/download) by LrC, written by LrC to originals in the cloud, and then downloaded from web gallery/cloud restore—all without starting off with a separate XMP.

But, I realize there may be something about how LrC has to write keyword + edit metadata to originals in the cloud that requires starting with that separate XMP. Or, maybe that specific XMP+DNG setup is just necessary in the case of starting from a proprietary raw, as you're doing.

Some of this I will probably just have to learn by testing and seeing what happens, too, which is OK!

Thank you again,

Michael
 
I think I'm a little unclear on which metadata gets exported/displayed in different sharing situations. From a quick bit of testing what comes out when, at least before LrC is in the mix, it seems like:

- Sharing/exporting out of Cloud software e.g. LrD exports the title/caption/keywords that I applied in LrD/Cloud.

- Downloading a full size jpg out of a Lightroom web album created via LrD does not seem to include keywords (or oddly title/caption—though the LrD-applied caption does appear in the web gallery interface).

I assume that means the web gallery download is going to use whatever's saved to the cloud original file metadata from LrC (and/or whatever's actually on the file in the first place when it's imported, as you describe with your DNG+XMP workflow). And, for a full restore from cloud, it's probably also just going to use what's written to the cloud original. So, that's why it's important to keep the metadata actually written to the cloud originals via LrC.

Is that all right?

You're not the only one who's unclear about what metadata gets exported/displayed in different situations, it's a minefield. Exporting out of cloud software is generally OK, but downloading out of LrWeb is a mess (and seems to change in various ways between testing efforts, not helped by the fact that many times changes are made without announcement). Also not helped by the fact that there are two LrWeb "portals" that are used, depending on whether viewing through one's own LrWeb account portal, or viewing through the "shared album" portal that non-account holders get.....the results are often different (e.g. viewing in the user's own portal allows keywords to be viewed, but not if viewed through a shared album portal). Latest testing is showing me that NO user-added metadata (titles, captions, keywords, etc.) is included when downloading from LrWeb (even when it shows in the online portal).

So that's why I convert raw files to DNG, so that all the user-added metadata is always going to be included in downloads from LrWeb, and when download syncing into LrC. And that's why I save post-syncing changes back to the file in LrC so that it uploads the file back to the cloud.

I'm not 100% sure what you mean by the full original file getting uploaded again... Am I right in putting it this way:

Once the image is synced down into LrC, if you edit the metadata/keywords and then explicitly save those changes to the local original file, those changes get synced up (by uploading the original file again?). That means the cloud original has those metadata changes actually in the file itself. And, again, this is useful because the web gallery export and doing a full catalog recovery rely on the actual file metadata itself, rather than how LrD/LrM/Cloud stores/reads keywords.

As for edits—do you mean actual Lightroom adjustments to the image itself? I thought those did automatically sync to the cloud... but, perhaps they're not written to the file metadata fully and live in some other Cloud database. And you need them written to the file for cloud restore.

Yes, you've got it right.

Regarding edits, yes they do sync so my saving back to XMP after making edits is a bit of a redundancy, but it's still reassuring to know that the original files are up to date in all respects, just in case I need them imported into a different catalog.

Do you know how important it is to go into LrD with a separate XMP + DNG outside of the case of starting with a proprietary raw?

E.g. I know that you can write both Lightroom edit settings and keywords to the metadata of other kinds of supported files (HEIC, JPG, or even a DNG that was shot as a DNG) without the separate XMP file, via LrD > export original + settings. If that file is imported into LrC from a local disk, LrC picks up the metadata/keywords and Lightroom adjustments properly.

So I would have assumed that with a supported format, any edit + keyword metadata could be properly read (on first sync/download) by LrC, written by LrC to originals in the cloud, and then downloaded from web gallery/cloud restore—all without starting off with a separate XMP.

But, I realize there may be something about how LrC has to write keyword + edit metadata to originals in the cloud that requires starting with that separate XMP. Or, maybe that specific XMP+DNG setup is just necessary in the case of starting from a proprietary raw, as you're doing.
I'm afraid you've rather lost me on the bit that I've highlighted in italics. Can you try different wording so that I can better understand what you are asking? Sorry if I'm being rather dense.....it's becoming my default state!
 
You're not the only one who's unclear about what metadata gets exported/displayed in different situations, it's a minefield. Exporting out of cloud software is generally OK, but downloading out of LrWeb is a mess (and seems to change in various ways between testing efforts, not helped by the fact that many times changes are made without announcement). Also not helped by the fact that there are two LrWeb "portals" that are used, depending on whether viewing through one's own LrWeb account portal, or viewing through the "shared album" portal that non-account holders get.....the results are often different (e.g. viewing in the user's own portal allows keywords to be viewed, but not if viewed through a shared album portal). Latest testing is showing me that NO user-added metadata (titles, captions, keywords, etc.) is included when downloading from LrWeb (even when it shows in the online portal).

So that's why I convert raw files to DNG, so that all the user-added metadata is always going to be included in downloads from LrWeb, and when download syncing into LrC. And that's why I save post-syncing changes back to the file in LrC so that it uploads the file back to the cloud.

Oh good, I'm glad they've got it sorted out so well...

However, I think a missing link for me on this was the fact that you can download the actual cloud original file with its (not-LrD-applied) metadata + edits from the logged-in portal. I didn't realize that, and it makes more sense to me now in terms of the usefulness of keeping that cloud original updated from LrC.

I'm afraid you've rather lost me on the bit that I've highlighted in italics. Can you try different wording so that I can better understand what you are asking? Sorry if I'm being rather dense.....it's becoming my default state!

You're going up against my ability to poorly explain my thoughts without having a great handle on what I'm talking about, which is itself formidable.

Basically, do you have a sense of how much LrC's ability to write keywords and edits to the cloud original file is dependent on starting by importing a DNG+XMP as the cloud original via LrD? As opposed to starting by importing a different Lightroom-supported file type (e.g. JPG/HEIC/TIFF) without a sidecar XMP.

I know LrC could write both keyword and image edit changes to the metadata of a standalone JPG catalog original on local disk—I have seen it do that. But, I don't know if LrC's abilities to then update the cloud original's metadata with those keyword/image edits are restricted if the cloud/catalog originals aren't DNG+XMP.

I think the question, and probably my inability to ask it with any coherence, goes to a poor understanding of what exactly LrC does to update the cloud original's metadata. If it just uploads a completely new original image file with updated metadata, it probably doesn't matter what file type it is. If it's altering it more surgically/taking less bandwidth, then the question might come into play. Or I may be overthinking it.

I hope that makes more sense? And again, this may be just a "who knows—try and see when you get there and alter strategy accordingly if needed" thing. Which is all good!

Thanks for bearing with me.

Michael
 
Oh good, I'm glad they've got it sorted out so well...

However, I think a missing link for me on this was the fact that you can download the actual cloud original file with its (not-LrD-applied) metadata + edits from the logged-in portal. I didn't realize that, and it makes more sense to me now in terms of the usefulness of keeping that cloud original updated from LrC.

Another thing to understand that downloading from a logged-in portal is different than downloading from a logged-out portal. For one thing, the logged-in portal has no album download option, but does have more options for downloading individual images. The logged-out portal has a full album download option, but no control over the type of download for album or individual images. The metadata content of the downloaded files is, I think, the same in both portals.

I think the question, and probably my inability to ask it with any coherence, goes to a poor understanding of what exactly LrC does to update the cloud original's metadata. If it just uploads a completely new original image file with updated metadata, it probably doesn't matter what file type it is. If it's altering it more surgically/taking less bandwidth, then the question might come into play. Or I may be overthinking it.

"Metadata" can cover both edits and user-added/changed data (titles, captions, keywords, etc.). In terms of images synced between LrC and the cloud, some metadata syncs, some doesn't {keywords and location data are main things that do not sync), however it IS possible to initially transfer existing keywords and location data when first syncing images from LrC, but this is a one-time, one-way deal and any changes after that made in either LrC or Cloud will not sync. That limitation applies even when (as in my case) originals are loaded into the cloud and then sync down to LrC. Making changes in LrC, then saving those changes to XMP, will have no affect on the cloud catalog, i.e. the changes made in LrC to keywords and location data will not be visible when viewing those images in a cloud app.
However, and to the point of your question, if the images that are seen in LrC are originals in the cloud, any physical change to the original in LrC (such as adding keywords then saving to XMP) will trigger an upload of that new original to the cloud, replacing the previous version. Changing metadata without saving to XMP will only upload the changed metadata (apart from keywords and location data). So when a changed original re-uploads to the cloud. any newly added keywords would not appear in the keywords panel in any of the cloud apps, but they WILL be included in the derivative if the image is exported from LrD with metadata included. Another wrinkle in that when downloading from LrWeb, any keywords that are seen in the keywords panel that have been added in a cloud app will NOT be included on download (but LrC added and saved keywords will). All of these "wrinkles" are why I go the extra mile to make sure that the metadata that I want included is saved to the DNG in LrC and thus syncs to the cloud and is thus always seen when downloading/exporting.

It doesn't have to be just DNG files, the same applies to any other non-proprietary file type (Jpeg, Tiff, PSD) that is loaded into the cloud and syncs into LrC. Proprietary Raws may be different.....saving changes to XMP will only update the XMP sidecar file but from the testing I've done so far it does not seem that the XMP sidecar is used as part of the export or download functions from the cloud.

One thing that is important to know is that there is no option in any of the cloud apps to "save changes to XMP".....if there was such an option it might make things a lot easier!
 
All makes sense. Thank you so much, Jim, I really appreciate the time on all the explanation.
 
Back
Top