Is lightroom serious? (how to delete images)

<p>I now have over 30,000 wedding photos in my lightroom catalog. Apparently that's too many and it won't let me import any more. But the only way to delete the photos is to backspace each photo then hit delete? Does that mean I have to do that 30,000 times? Is there an easier way?</p>

<p>yes, you can select multiple images and delete them all at the same time.<br>

you might also want to rethink the way you are using lightroom... having 30k images in 1 catalog is just madness</p>

<p>You can also break the 30K images into smaller catalogs. I personally make a catalog for each wedding.</p>

<p>Kay,</p>

<p>in the library grid view, right click the folder you want to delete, and select "remove". It will double check with you before it continues, then remove entire folders from its catalogue. That is how you keep the program running effeciently too.</p>

<p>I don't keep ANY LR catalogues. Just imoprt, process, export, remove.</p>

<p>I have multiple catalogs of 150k+, 90k+ and 36k images respectively. There's no 30k limit.</p>

<p>I had this issue with LR just the other day - you can click on a folder and then press the (-) key at the folder site to remove folders... sometimes this is a limitation of the room on your hard drive.</p>

<p>I used to have everything in one catalog, it was a pain. Just make a catalog per event, it makes you life much easier that way. </p>

<p>Missy, the first thing you need to do is find out why your system is not handling a 30k image catalog. My "working" catalog is twice that size, and I've run "test catalogs" over 200k images. And, amazingly enough, the working catalog still burns to one CD, so all that work with keywording and editing is safe.</p>

<p>You really do want to work with just one catalog, when possible. In general, I find that people who recommend breaking lightroom catalogs down into smaller chunks simply have not mastered (or even attempted) organizing files to any decent extent using keywords and the basic use of filters. There is just so much you can do with instant access to everything. Tag a good image or two from each wedding, and you can filter that to see what you'll be using in the next revision of your website or other advertising. Try that with "a catalog per event" and suddenly "life" is not "much easier that way".</p>

<blockquote>

<p>In general, I find that people who recommend breaking lightroom catalogs down into smaller chunks simply have not mastered (or even attempted) organizing files to any decent extent using keywords and the basic use of filters</p>

</blockquote>

<p>There are many reasons why multiple catalogs is preferred over 1 catalog and vice versa.... depending on your working environment you may pick one over the other.</p>

<p>Right click on a folder in the left menu and choose remove, it will delete the folder in lightroom, but not the files. Make sure you only choose remove and not delete unless you want to delete the file.<br>

Kenz</p>

<p>Catalogs are like categories; different completely to tags and filters.<br>

The categories/catalogs are general issues. It's best to have a few, to easily access a particular wedding, event, portait session, etc. quickly and without the hassle of other photos.<br>

Then the tags link something similar, so if you want to have photos to make a theme-based montage, that's quickly done.<br>

Then the filters are used to filter good, better, bad, worst, etc. shots. There can be colour filters, or star-rated filters...<br>

<br /> Which is why breaking things down into smaller catalogs is not stupid.</p>

 

<blockquote>

<p>You really do want to work with just one catalog, when possible. In general, I find that people who recommend breaking lightroom catalogs down into smaller chunks simply have not mastered (or even attempted) organizing files to any decent extent using keywords and the basic use of filters.</p>

</blockquote>

<p>I'm sorry, Joseph - that's very poor advice, IMHO.</p>

<p>The principle reasons to avoid large catalogs are to (i) reduce risk of catalog corruption; (ii) make back-ups quicker; (iii) make disaster recovery easier; (iv) make indexing faster; (v) make preview rendering faster; (vi) avoid growing the catalog to a size where it cannot be backed up safely.</p>

<p>It's got nothing to do with whether someone understands how to use filters. It's to do with how much they understand how to manage storage, and the risk of storage.</p>

<p>Let see: I have multiple catalogs because .... it suits me! Yes, I actually <strong>want</strong> to! I didn't realise I needed anyone's permission?</p>

<blockquote>

<p>I'm sorry, Joseph - that's very poor advice, IMHO.</p>

</blockquote>

<p>I'm sorry, Neil, but it isn't.</p>

<blockquote>

<p>The principle reasons to avoid large catalogs are to (i) reduce risk of catalog corruption;</p>

</blockquote>

<p>That's the principle reason to avoid small catalogs. Your risk to data for a well constructed database is about O(log(n)). Cut a large catalog in half, and you've now got 2(log(n/2)), which is about double log(n) when n>>base of the log. So, yes, if you have a database with 10 records, you may have a little less risk by dividing it into two 5 record databases. But if you've got a 10,000 record database, you double the risk dividing it into two 5,000 record databases.</p>

<blockquote>

<p>(ii) make back-ups quicker;</p>

</blockquote>

<p>Individually, but the cumulative time is as much, and probably a little more, to account for juggling multiple files.</p>

<blockquote>

<p>(iii) make disaster recovery easier;</p>

</blockquote>

<p>If you have multiple catalogs, the disaster recovery for one of them is going to involve checking all the images to find out if they belong in the catalog you're reconstructing or one of the other catalogs. Seems like disaster recovery complexity increases exponentially with the number of catalogs.</p>

<blockquote>

<p>(iv) make indexing faster;</p>

</blockquote>

<p>Again, unless indexing is broken, you've moved from log(n) to X log(n/X), where X = the number of databases, and that means that you're increasing indexing time. The individual catalogs don't index any quicker, but there are now X of them.</p>

<blockquote>

<p>(v) make preview rendering faster;</p>

</blockquote>

<p>Previews are individual files, the only thing that makes rendering them "faster" is locating them better on the hard drive, or improving drive performance.</p>

<blockquote>

<p>(vi) avoid growing the catalog to a size where it cannot be backed up safely.</p>

</blockquote>

<p>A heavily keyworded catalog runs about 10k per entry, and is highly compressible (about 15:1 by simple LWZ). Any decent backup program will *safely* put a 900,000 entry lightroom catalog on a single CD.</p>

<blockquote>

<p>It's got nothing to do with whether someone understands how to use filters.</p>

</blockquote>

<p>I'd say you've got that totally wrong.</p>

<blockquote>

<p>It's to do with how much they understand how to manage storage, and the risk of storage.</p>

</blockquote>

<p>That is quite correct. Nothing personal, but it appears, from your misconceptions in that area, that you are the one offering the "very poor advice", IMHO.</p>

<p>Joseph - interesting comments. All incorrect though :-)</p>

<p>Actually, the reason they're incorrect is merely one of context, as I suspect our assumptions are different. The only way your figures stack up is if you consider a catalog to be separate and distinct from the files within it, and if you are discounting the storage of previews. Otherwise your predictions of scale would be nonsense.</p>

<p>The last job I shot has around 2,200 images. The size of the catalog is 6 GB including previews and XMP files. It does not contain any embedded RAW files. Quite a long way from the 'single CD' you mention. And previews are not compressible.</p>

<p>The storage space of my catalogs over the last two years runs to 13 TB. Short of purchasing a SAN and implementing a network storage system, it would be difficult - if not impossible - to store it anywhere, if I insisted on keeping it all in a single catalog. But since I have a multiple catalog strategy they're offline, backed up in multiple locations on inexpensive disks.</p>

<p>Contrary to popular misconception, corruption in catalogs is a product of their volatility, not their size. A catalog that remains unchanged is at no risk of corruption except data on disk being overwritten. Conversely, a catalog that is read, indexed, reindexed, and written to disk every session is at much higher risk, and that risk increases every time the size of the catalog increases. An interruption (or even a bit flip) to any I/O action will corrupt the catalog, quite possibly beyond repair. (More about this in a closing anecdote).</p>

<p>A catalog that is archived is at no risk at all providing the underlying media is backed up. But it's impossible to archive a catalog if you keep adding images to it. Hence, in your model you can never reach a point where your catalog is at zero risk. By contrast, all of mine are at near zero risk except the one I'm working on.</p>

<p>A professional photographer typically has no interest in maintaining a catalog of all images they ever shot. Far more important is a catalog per client or job. This makes storage management super easy - in fact, much easier than even your best case scenario. Even in the event of total and absolute catalog failure, as long as the underlying images are available, the catalog can be reconstructed simply. Made easier, of course, because all the metadata will share common values. Even better, when the job is finished the catalog and files can be archived together.</p>

<p>And the anecdote....</p>

<p>I was working on some personal work I'd shot in Italy about 2 months ago. My cat was walking round my office and decided to chase a spider, taking her down the back of my desk where she trod on the power button of my extension block. Immediately the computer and connected drives lost all power - and I was in the middle of editing an image. When I powered it back up I'd lost the entire catalog - LR refused to read it and was unable to repair it.</p>

<p>But, my total downside was limited to the 300 images in the catalog at the time and it took me about ten minutes to build a brand new catalog, and pick out all the XMP files from the old one using a bash script, and reimport them. And it was at that time that I was thankful I had a modular catalog strategy, not a monolithic one. If that had been all the images I'd ever shot it would have been disastrous.</p>

<p>BTW - I make it a rule to never offer advice except if I know from personal experience that it works ;-)</p>

<p>Why anyone would want to use a keyword system, however well maintained, to search through my 150 weddings in the last 3 years, roughly 1200 images per. Stretches my belief. btw roughly 8TB every wedding season of RAW images, so that's a bit more than what would fit on a CD, though if I understand what J is proposing is that the catalog ISN'T the images merely the DB for reference.<br>

Missy, if you are a professional, or even a serious amateur, your workflow should make things easier. For J, it seems his workflow revolves around keywords, so he doesn't see the total number of images as a deterrent, kind of like iTunes. However for myself, Neil, and most wedding photographers who want to put their product out quickly and well. Individual catalogues make our workflow much simpler.<br>

Best of luck.<br>

Daniel</p>

<p>not to mention that having everything in 1 catalog makes it only 1 person able to work on the catalog at the same time.<br /> i store my catalog/pics in a central file server location and access it via remote stations... my partner and i work on different weddings at the same time. if i only had 1 catalog, that means only 1 person can do work at any given time... splitting it to separate ones makes it able for her to work on 1 event while i work on another at the same time.</p>