Start a new catalog or continue this one?

<p>My one and only Lightroom's catalog has now near 85,000 pictures.<br>

What should I do starting this new year?<br>

Continue this one, or start a new one?<br>

Many thanks.<br>

J-P Dupre</p>

<p>Continue with the same catalog. </p>

I believe the other answer would then be: start a new one.<br><br>I don't know why. But i also don't know why Andrew's answer is to continue with the one you already have. If only there was a way to find out... ;-)<br>Andrew, could you explain?

<p>Andrew will probably chime in at some point, but in the meantime,maybe these might help:</p>

<p>http://lightroomkillertips.com/should-you-create-multiple-catalogs-in-lightroom/<br>

https://www.slrlounge.com/school/singles-multiples-two-recommended-lightroom-catalog-workflows-2/<br>

http://www.lightroomqueen.com/articles-page/use-one-big-catalog-multiple-smaller-catalogs/</p>

<p>As long as your system does not slow down there is no reason to start a new catalog but it also depends on your work/your demands. LR can handle it. What benefits do you see in splitting your catalog in two?</p>

<p>There are significant advantages to one catalog and a number of disadvantages of multiple catalogs. Unless you <strong>must</strong> split libraries, don't do so. </p>

<p>How is your computer handling this catalog? Lightroom can bog down. If it handles the load I would recommend keeping it as one. You can search and organize all of your photos much easier in one large catalog. Once it slows, you may want to start a new one.</p>

<p>Many thanks to all, for your comments or references.<br>

I will continue with this "one and only" catalog.</p>

<p>In case you're concerned, I have 345,020 images in my one catalog. Never had a problem.</p>

Still curious though: what are those advantages and disadvantages?

<p>One catalog, everything in one place. You can then break down using keywords, smart collections etc. Why go into a library with two card catalogs when you could search one? Some of this is proprietary too, meaning you're placing LR specific data in multiple places which may be out of sync. Dumb collections come to mind. Proof and Virtual copies. History. <br>

You can kind of sync this by exporting one image from a catalog (<em>Export as Catalog)</em>. Then import other catalog(s) and you migrate all the catalog specific stuff with one image you can delete. You'll bring over keywords for example. But why? Keep one catalog, one catalog specific set of user defined attributes (<em>Store presets with this catalog</em>). <br>

Unless you've hit some kind of image limit, which as other's have mentioned are huge, keep everything in one catalog. Make lots of backups. You can break that down from there in dozens of ways. <br>

Curse of multiple catalogs: The image I want is in the <em>other</em> catalog. </p>

<p>The Lightroom catalog is a relational database with references to the image files (the images are not stored inside the database) so a few hundred-thousand records should not be a problem in most modern computer. </p>

<p>There might be valid reasons to have multiple catalogs depending on your workflow, but image quantity is not one of them.<br>

Have your catalog, previews and cache in a fast disk.<br>

Also, increase the camera raw cache if you have performance issues (and space available)</p>

 

<p>I think it would clear up a lot of confusion and catalog fears if there was a concise explanation in plain, simple language how LR's catalog system works. Or just an understanding of what it is and why it's needed.</p>

<p>Maybe describe it as a portable GUI type OS just for organizing images in a folder style directory. Why would one want multiple DAM operating systems to contend with? Keep it in one catalog for simplicity sake and move on.</p>

<p>How's that for a good explanation to ease LR catalog anxiety which I also suffer from. That was good therapy at least for me.</p>

How's that? Francisco did it much better just above your post, Tim.

<p>You can think of the LR catalog as a register of images which handles the following information:</p>

<p>- Where the original image file is located (Disk / folder / filename)<br>

- Development instructions, similar to a recipe<br>

- Information about the image (metadata, keywords, ratings etc)<br>

<br />Since it does not containg the image file itself, the size of each individual record is relatively small, so you can manage a large number of images in one single catalogue.</p>

<p>Further:<br>

- In order to speed up the visualization of images, LR builds previews of the images + recipe, which are stored separately and can be regenerated at any time.<br>

- In order to speed up the develompent process, LR uses a "Camera Raw Cache". Usually increasing the size of this cache or buffer, may improve the performance when you manage a large collection of images.</p>

<p>I've been using LR since version 2 and have never needed a second catalog for my own photography. I do maintain another catalog for a photographer whose event photos I manage, but the primary reason is that I deliver the catalog and the processed images. I can't really think of any reason to manage my own photos in multiple catalogs.</p>

<blockquote>

<p>How's that? Francisco did it much better just above your post, Tim.</p>

</blockquote>

<p>Couldn't understand a word he said, nor did it ease my fears as to why a catalog system is required for LR while other apps that similarly organize tons of images for easy retrieval don't require this.</p>

<p>Import? Export? Why? Why not a simple double click for "open" just like the computer OS and Adobe Bridge.</p>

<p>I explained it with one important word...portability. Why does LR have a multiple choice preference dialog box for optimization of the catalog? Why does a catalog need optimization while other directory registries like a computer's doesn't? What is it about LR that requires coddling the catalog in this way? It just raises too many questions like the ones I'm asking.</p>

<p>I didn't get those questions answered clearly from Francisco's explanation. You do realize LR's User's Guide is now over 200 pages for an app that just organizes and edits images. Why? It's just a picture.</p>

<blockquote>

<p>- In order to speed up the develompent process, LR uses a "Camera Raw Cache". Usually increasing the size of this cache or buffer, may improve the performance when you manage a large collection of images.</p>

 

</blockquote>

<p>There's a thread over at LuLa that suggests there's more to it than that going by posters complaining about slow performance after long editing and processing of many images. They found quitting LR and restarting gave back the performance they had before. Optimizing the catalog didn't do anything.</p>

<p>What's that all about? </p>

<blockquote>

<p>There's a thread over at LuLa that suggests there's more to it than that going by posters complaining about slow performance after long editing and processing of many images. They found quitting LR and restarting gave back the performance they had before. Optimizing the catalog didn't do anything.</p>

 

</blockquote>

<p>I know that thread and have contributed to it.</p>

<p>First, the catalog and the cache are two different things (the cache is just a temporary storage area, usually configured on a fast drive).</p>

<p>If you have performance issues that get solved by restarting the application, it is likely due to a cache or a memory leak issue, and has nothing to do with the catalog.</p>

<p>If the issue were due to the catalog not being optimised, the problem would not be solved by restarting the application. Unfortunately none of the posters that experienced the issue tried (or reported) increasing and/or rebuilding the cache.</p>

<p> </p>

<blockquote>

<p>Import? Export? Why? Why not a simple double click for "open" just like the computer OS and Adobe Bridge.</p>

</blockquote>

<p>Because LR workflow is based on a register or catalogue. Importing an image is just the process of creating the record in the register.</p>

<p>Think of it as a library compared to your personal book collection. If you buy a book for yourself, you might just put it in an available space in your bookshelf after you read it.<br>

A library instead, will go to a process of creating an entry in the catalog before it is available to the public.</p>

<blockquote>

<p>Because LR workflow is based on a register or catalogue. Importing an image is just the process of creating the record in the register.</p>

</blockquote>

<p>But what is the advantage over just clicking to open?</p>

<p>It appears creating a record of registry by importing is similar to creating an alias that points to an actual file that resides on a hard drive which seems like a setup for errors to occur if and when a catalog gets moved to another hard drive for clients and/or other post processing workstations to work on or view images across multiple platforms. </p>

<p>I don't use LR that way anyway, but I've read that's part of LR's advantage, the portability of its catalog over Bridge's way of keeping track of large collections of images. LR's catalog just collects the registry of the images which are organized in their own folder structure using the computer's OS GUI.</p>

<p>What's not clear to me is if one moves the catalog to another hard drive not connected to the computer where the catalog originally resided, how does the catalog know where the images are? The images have to come along for the ride as well but still the catalog has to now know where they are on the other computer, so I'm assuming there's some type of refreshing involved for the catalog to reconnect with the moved images. I just don't understand how a catalog can keep that all straight.</p>

<blockquote>

<p>What's not clear to me is if one moves the catalog to another hard drive not connected to the computer where the catalog originally resided, how does the catalog know where the images are? The images have to come along for the ride as well but still the catalog has to now know where they are on the other computer, so I'm assuming there's some type of refreshing involved for the catalog to reconnect with the moved images. I just don't understand how a catalog can keep that all straight.</p>

</blockquote>

<p>It doesn't matter where the catalog resides, you can open Lightroom from the catalog. If the images have moved, Lightroom will show that it can't find the images. You then point Lightroom at the image folder(s) and it is instantly fixed.</p>

 

<blockquote>

<p>But what is the advantage over just clicking to open?</p>

</blockquote>

<p> <br>

If your shoots typically have only one or two images, nothing. With more than that, you can look at a whole shoot, a selection, a cross-section of various shoots that have some relationship you've specified, etc. I rarely open one image and I wouldn't want to click to open each of 200 images after a shoot.</p>

<blockquote>

<p>But what is the advantage over just clicking to open?</p>

</blockquote>

<p>It is a different approach, not necessarily better or worse, and it depends on your needs and your desired workflow. Lightroom is just a single-user digital assets management solution.</p>

 

<blockquote>

<p>It appears creating a record of registry by importing is similar to creating an alias that points to an actual file that resides on a hard drive which seems like a setup for errors to occur if and when a catalog gets moved to another hard drive for clients and/or other post processing workstations to work on or view images across multiple platforms.</p>

</blockquote>

<p>When you use LR, you need to have a catalog-centric approach in order to avoid problems.<br>

A few ways to work with other parties or workstations:</p>

<p>- Use the sidecar files (.xmp): A record in the LR database is equivalent to a sidecar file. The good thing is that you can create and/or syncronize information between the LR catalog and the sidecar files in both ways.<br>

Example: Create the xmp file from LR, then edit the image in ACR (which will store the edits in the xmp) and finally back to LR where you have the option to update the catalog with the new content in the xmp.</p>

<p>- Export the desired images from LR "as catalog": LR creates a folder with a catalog, images and previews than you can move to another workstation. You can performs edit in this catalog and then import back the changes to your original catalog.<br>

An additional advantage is that you might not need to export or distribute the original image files but only previews and work with them in other workstations saving a lot of space. If you use smart-previews you can even edit the images.<br>

Same as before, you can then import back those changes to your original catalog</p>

 

<p>Very concise outline on how to make the catalog and LR edited images portable for other people to work on on other workstations, Francisco.</p>

<p>I embed all xmp edit sidecars in the image in LR as I do in ACR in case something happens to the catalog. I've tested it by dragging a copy of the image into Bridge and the xmp sidecar symbol and the edits are retained.</p>

<p>Just curious to know what can go wrong in reference to your statement of needing a catalog-centric approach in order to avoid problems. I'm guessing preventing images from getting lost or corrupted.</p>

<p>Thanks, Jeff and Francisco for your explanations. Very helpful.</p>

<p>Thanks for your comments Tim,</p>

<blockquote>

<p>Just curious to know what can go wrong in reference to your statement of needing a catalog-centric approach in order to avoid problems. I'm guessing preventing images from getting lost or corrupted.</p>

</blockquote>

<p><br />In order to keep integrity of your image collection, the "catalog" must be aware of all changes you perform in the images. If you edit or make changes with ACR then you need to update the catalog using the information in the xmp files. If you need to move folders / images to another location, you should do it from inside LR so the references get updated.<br>

An important thing to remember is that LR does not merge the catalog information with the xmp files. It either overwrites the catalog with the xmp files or overwrites the xmp with the catalog info.</p>