Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/content/60/9972860/html/smf/Sources/Load.php(225) : runtime-created function on line 3

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/content/60/9972860/html/smf/Sources/Load.php(225) : runtime-created function on line 3
Does LR have an importation and management photos limit?
The DAM Forum
Welcome, Guest. Please login or register.
November 29, 2020, 06:02:30 AM

Login with username, password and session length
Search:     Advanced search
28033 Posts in 5147 Topics by 2903 Members
Latest Member: kbroch
* Home Help Search Login Register
+  The DAM Forum
|-+  Software Discussions
| |-+  Lightroom
| | |-+  Does LR have an importation and management photos limit?
« previous next »
Pages: [1] Print
Author Topic: Does LR have an importation and management photos limit?  (Read 9980 times)
Valeria Lages
Jr. Member
**
Posts: 72


View Profile Email
« on: April 15, 2008, 02:35:12 PM »

I'd like to know why so many photographers are using LR just for cataloging and developing photos and using Iview for definitely storage. Is it only because they had already their archive at Iview before LR has been created or there are some other important reasons that I should Know?
As I'm just starting to use LR and I've never used Iview, I wanna know if I really have to use both also or if I can use only LR in order to catalog, develop and storage my photos archive. I have some basic questions about that:

1) Is it true that LR gets slower, as time goes by, to develop images if there are millions of photos imported on it? Some photographers friends
of mine are using LR only to manage actual working images. After finishing edition process, they export the images definitely to Iview in order to storage them. They say LR is faster to process/develop images if it's light, with few number of photos imported on it, that's why they are using
Iview as their definitely storage software. LR, for them, is only for temporary work, while Iview is for storage and research forever. Do these informations make any sense?

2)  Does LR have a limited number or photos to import, catalog, develop, storage and manage or it can be done to millions and millions of images until the end of my days? I suppose there is a limit. But which is this?  I mean: how many photos can I manage at LR? I suppose this limit is higher at Iview, is this the reason why people are storing photos at Iview and not at LR? Which is the Iview limit of photos storage? And what will happen when my photos archive arrives at this software limit, even LR or Iview?  How would I increase my photos managing and storage process when I get to this software limit?

  I would really appreciate if someone answer me theses crucial questions...

  Thanks,

  Valeria
Logged
markpirozzi
Full Member
***
Posts: 179


View Profile
« Reply #1 on: April 15, 2008, 04:36:47 PM »

I think your basic assumptions are correct.  With iView you can have your catalog only create small thumbnails which means you can have a large number of photos before there is a size of catalog problem.  You can still access your originals through the thumbnails if the originals are available. No matter how small the thumbnails, you can manage and assign metadata.

The fewer catalogs you have, the less time it takes to search for a photo if you are searching by metadata.

Mark
Logged

Mac OSX 10.7, 2009 MacPro
johnbeardy
Administrator
Hero Member
*****
Posts: 1813


View Profile WWW
« Reply #2 on: April 16, 2008, 03:02:41 AM »

I think one reason is that there are no prizes for being an early adopter or for leaving the certainty of something which works. That's where I am, plus many photographers have needs for managing file types which Lightroom won't import but which are part of mainly-photographic jobs - eg sound or video clips from weddings. One could also add more purely photographic items like large stitched images or CMYK files.

The argument about "They say LR is faster to process/develop images if it's light" is also used by those who advocate breaking up their Lightroom catalogues into one per job or into one catalogue per themes such as one for wildlife or another for landscape. Apart from that idea being a fast track to duplicating work in more than one catalogue, or to other pictures slipping through the gaps and not being in any catalogue, the faster argument isn't really true. Its main speed constraints are not the total number of files in the database, but disk/network access and processing speed to those which are visible at the moment.

Adobe have published no upper limit. As a guide, I was looking at a catalogue with 120000 images and it was running just fine, growing at 3-600 a day. With so much value in one database, the photographer has strong backup routines and, with no other file types to worry about, he has decided it's too much trouble to maintain his iView catalogues too. Apart from anything else, the 2gb limit on iView catalogue file sizes means he has to break up his work artificially. My own test catalogue is now around 80000 and I'm not seeing anything that worries me.

John

ps I don't think anyone has written anything more persuasive than this on the subject of having one catalogue or many Wink
« Last Edit: July 14, 2008, 12:31:29 PM by johnbeardy » Logged
markpirozzi
Full Member
***
Posts: 179


View Profile
« Reply #3 on: April 16, 2008, 04:17:58 AM »

John,

Up until recently, I was "just tinkering" with LR.  I've recently brought all my camera originals (~20,000) into one catalog.  Mainly because I've started using II, having it convert to DNG and LR handles the updating of the DNGs in the background.

I settled on a keyword vocabulary that is logical for me and I was making the keywording uniform throughout catalog.  When I select upwards, of a 1000 photos LR seems to slow down in the "metadata gathering" process quite a bit and is much more prone to crashing.  I'm probably taking about 12,000 photos a year now, so I have concerns about the catalog handling a large number of files for the average person. I think Peter stated that one factor in performance was the amount of metadata added to files.  I've started an Inbox catalog and as the photos are processed, I will export to my main catalog.

Do you know a way to select only files that have their metadata out of date.  Auto writing to XMP doesn't update keywords and other metadata to files. 

Mark
Logged

Mac OSX 10.7, 2009 MacPro
johnbeardy
Administrator
Hero Member
*****
Posts: 1813


View Profile WWW
« Reply #4 on: April 16, 2008, 06:57:53 AM »

Do you know a way to select only files that have their metadata out of date.  Auto writing to XMP doesn't update keywords and other metadata to files.

No, we badly need these sorts of global controls rather than the badges which are OK (if you remember what they mean) for individual images but unhelpful if you'd managing groups of images. I'm trying to encourage Adobe to implement such things via LR2 smart collections or filters.

John
Logged
Photo_op
Guest
« Reply #5 on: April 16, 2008, 07:07:32 AM »


No, we badly need these sorts of global controls rather than the badges which are OK (if you remember what they mean) for individual images but unhelpful if you'd managing groups of images. I'm trying to encourage Adobe to implement such things via LR2 smart collections or filters.

John

John-....PLEASE...continue to encourage Adobe re..."implement such things via LR2 smart collections or filters". I'm assuming   Smiley  this is not a programming nightmare. For those of us who don't use automatic update, anything of this variety would be welcomed!

Dave B
Logged
johnbeardy
Administrator
Hero Member
*****
Posts: 1813


View Profile WWW
« Reply #6 on: April 16, 2008, 08:32:15 AM »

It's the sort of thing I always bang on about! from my old life, a decade or so working in business management and reporting (nice euphemism for accounting and financial IT), one lesson always stood out when specifying systems - prioritizing which fields to make available is a thorough waste of energy with a database-powered application. Once some data is in the system, someone somewhere will have a powerful and persuasive reason to query on it. So I always insisted that developers I commissioned would not just make the most likely fields more readily accessible, but would make available, somehow, all data fields that might conceivably be useful, and many that were not.

In Lightroom, many important items are stored in individual fields - I think this is true of metadata status - and all that's required is hooking up a SQL query and interface. Other potentially useful data has sadly been stored in unparsed blocks of data, rather than being broken into individual fields. No blob data was always another of my ironclad rules - once a clever developer had dumped information in one of these blobs, it would always be a struggle to remember/persuade/budget for it to be handled properly in the next revision and would more likely result in half-baked solutions. But this data is still readily available, unencrypted - and database application coding is so much easier than the image programming that Adobe are really good at.

Crikey, quite a rant - and I'm not even down the pub today.

John
Logged
samdring
Newbie
*
Posts: 39


View Profile
« Reply #7 on: April 16, 2008, 08:48:43 AM »

Mark
I know this is not key to the thread but
Quote
Auto writing to XMP doesn't update keywords and other metadata to files.
Mine certainly auto-updates keywords but what metadata does it miss please?

Sam
Logged
johnbeardy
Administrator
Hero Member
*****
Posts: 1813


View Profile WWW
« Reply #8 on: April 16, 2008, 09:01:07 AM »

History, virtual copies, stacking, collections - don't get written. I thought keywords did though.

John
Logged
markpirozzi
Full Member
***
Posts: 179


View Profile
« Reply #9 on: April 16, 2008, 04:13:58 PM »

John, Sam,

I'll retest.  I didn't think keywords were written without saving.  I would change a keyword within LR and then go outside of LR and copy the file to another folder.  The copy didn't not reflect keyword change.

I'll recheck all the settings.

Mark
Logged

Mac OSX 10.7, 2009 MacPro
markpirozzi
Full Member
***
Posts: 179


View Profile
« Reply #10 on: April 16, 2008, 06:08:52 PM »

Strange behavior to report from testing writing metadata.

I tested my new "Inbox" LR catalog.  I checked the setting to automatically write to XMP and it wasn't checked.   The metadata status badges seemed to be the the down variety.  I activated the option to write. LR worked a little while and then the badges disappeared.  I added a keyword to a file, copied the file, Bridge indicated the keyword was written.

I opened my main catalog. It was already set to automatically write to XMP.  All the files had metadata status badges and they were the 2 directions variety.  Newly added keywords would not automatically write to the files unless I selected write metadata to file from the Metadata menu.  Different behavior between the two catalogs.  I didn't think to uncheck the auto write option and then turn it back on.

Mark

Logged

Mac OSX 10.7, 2009 MacPro
markpirozzi
Full Member
***
Posts: 179


View Profile
« Reply #11 on: April 17, 2008, 04:46:23 PM »

I tried turning off and then turning on write to files on my main catalog.  This did not trigger writing keywords to files like it did on my other catalog.  After closing LR and relaunching, writing keywords to files was working on my main catalog.

Mark
Logged

Mac OSX 10.7, 2009 MacPro
gusmahler
Newbie
*
Posts: 16


View Profile
« Reply #12 on: July 14, 2008, 12:29:08 PM »

ps I don't think anyone has written anything more persuasive than this on the subject of having one catalogue or many Wink


Link doesn't seem to work. This one does, though:

http://www.beardsworth.co.uk/news/index.php?id=P1071

Gus
Logged
johnbeardy
Administrator
Hero Member
*****
Posts: 1813


View Profile WWW
« Reply #13 on: July 14, 2008, 12:34:49 PM »

Sorry, Gus, I changed the name of that comments page to throw off automated spamming - it's here now (worth reading the comments)

John
Logged
Pages: [1] Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!