P: Allow Catalog to be stored on a networked drive.

In fact, this made me realize that putting the catalog and the master files in an SCM like SVN or Git might just do the trick. As long as the master files are at the same place relative to the catalog it will work.

People check-in the catalog + the master files, other check them out...

But the catalog file is way too fat... Nah, won't work. If the catalog could be centralized, in a proper SQL server, that solution might have a future...

First, I explained what would be the dream system for me. I realize it may not happen or I may not be able to afford it, yet. But, I worked with many systems with such capabilities and more and there are open source SCM that do that, and more, for free. Commercial ones may be in the range of 20$ to 200$ per month per users. It may sound a lot but for a business it is justifiable if it saves you time.

It is not a complex system to develop, it is mostly a matter of building it. You seem to think it is complicated but it is not, really. If there is a market, it will sell. I would like it but my business is not at a scale large enough to justify it. At the same time, Adobe products are quite expensive, LR aside. In the great scheme of things it could be justifiable. In the mean time, I would take any significant improvement to the collaborative workflow. As of now, there is almost none.

I agree that not everybody needs collaborative tools. But it is more or less the norm now and the working environments tend to explode and you see more and more projects being done by geographically distributed teams. Maybe Adobe used to have single user centric products, but that was the same for all software companies. Most have adapted and Adobe is behind. They have to embrace the change or they risk to loose ground to competitors. That is just the way to world is going.

You ask to hear about "facilities" that require to access catalogs remotely? I am one, Axiom seem to be another and I work with a bunch of people that would benefit from that. Again, teams are not groups of individuals working in an office anymore. Companies have video conferencing, web enabled CMS', intranets, IM and all sorts of remote collaboration technologies. I don't see why photographers or digital creatives would be different. In fact, I meet so many people in the field doing just that while travelling. Why would they not like a collaborative environment for photos and any other type of digital assets for that matter.As a matter of fact they do, they use a combination of social media platforms, dropbox, emails, etc. to exchange data. There is just not integrated collaborative platform for digital creatives yet or, I should say, for Adobe customers.

P.S. As for LR 5, the biggest improvement, to me, is the irregular shaped spot removal. You can "paint" with the spot removal "cursor" (try it, click and drag). It is welcomed but never as powerful as PS. So if you already use PS or Gimp, it will only lower the quantity of images you have to edit out of LR but not eliminate them. As far as collaboration goes, they added Smart Previews, the capability to store compressed low-res DNG files in the catalog previews so the catalog can be shared, other users can edit the files without needing the master file. It is limited because of the low-res lossy compression nature of the previews...

P.S. I am not Elvis, I assure you. ( I don't really get that sentence 😉 )

I'm curious to how much you would pay for LR if it did all this, if it gave you a check in/check out type environment. Obviously if you are on a network, you don't know who's working on what photo when, so you'll need a check in/check out system as they have with adobe drive.

I only just upgraded to LR 4 about 2 weeks ago, I've been using the beta of LR 5 but as you say, apart from the smart previews, I don't see a huge change. There is a new whizzy tool that lets you subtract effect from an image, similar to the 0 opacity tool in the Nik collection, which I have to say, I'm using far more than the LR edit tools.

I no longer use LR for keywording or IPTC, that is dealt with by Photo Mechanic (code replacements are very useful), so I'm left with the MAM, which i'm happy with so far.

I'm interested in how many people actually *need* network ability. Remember, there's need and there's want. I need a Ferrari, no, I want a Ferrari. I need a Nikon D4, no, I want a D4, y'know, there's loads of reasons why we want something, but i'd like to hear from facilities that have a actual requirement for LR being able to access lcats on shared storage and that lcat being opened by multiple people during the day, and what are the deliverables based on this functionality.

For example, would you not just be using Elvis if you're running press or some kind of news workflow, and therefore Photoshop being your editor.

Adobe are pretty well know for there single user approach on things, only recently have we seen 'collaborative' tools with adobe drive, etc etc

Well, to have a solid implementation, dealing with lrcat files over the network would not do. That is why a remote SQL would help. But it would still be relatively easy to implement. The LR "client" would need to have code added to deal with concurrent updates (add a check-out and lock mechanism or provide a mean to merge or simple prompt for overwrite or create a virtual copy).

But I still think that the master file concept and catalog have to be more tightly coupled from the user's perspective. If you just move to a centralized catalog in it's current incarnation or on an SQL server, you would still have to deal with moving master files around and making sure they are at the right place/fix locations when sharing photos. It only helps on the catalog aspect of sharing, not the master file aspect of sharing.

While I agree it is easier said than done, there are a lot of products doing just that on the market with either check-out and lock mechanism or merge (think source control or large CMS). Merging is not possible on images (that would definitely be a tough feature to implement for images!) but it could be as simple as only allowing adding images to the repo and never allowing updating a master file on the repo (from client to repo, I guess you would need to be able to replace repo master files somehow but that is very very rare with non-destructive editing). This would eliminate the need for a locking mechanism or update conflicts management. It would only go downstream to clients, if they need the master file.

In terms of the size of the data, I agree it can be quite large, but there are no differences between that and Export/Import/Copy over a network or removable drive, the way we have to do it today to have some semblance of collaboration. It would just be automated in LR so it can fetch the master file automatically, when needed. This could also be integrated with cloud storage to facilitate transfers over Internet...

LR5 Beta is just out and they added Smart Previews. It is basically the ability to "edit" photos in the develop module even without the master file being present. Not a big improvement, people are all cheering up. But what can you really do on a low-res preview in develop mode? It will be pretty limited. I can see it will help collaboration somewhat, but far from a great solution...

Presumably, if you edit your current back up settings, given that your media is on shared storage, this could almost be done now by changing the back up location of the lcat file

It's actually even easier to implement than that.

network location
The lcat file is the "repository" as is
a cache folder is beside it for the previews.

satellite location
a local cache for local rendering "developments"
- imports go straight to network lcat and it's image folder.
- grabs initial previews from network as needed
- writes and reads link back to the network lcat and cache with error checking.

SO
people simply use their LR to connect to the remote lcat like normal no matter where it is. LR sniffs for other users and checks in and out as needed.

No additional software required - just turning on the options in the engine.

Checking out files for "offline" use though may be more complicated as THAT has way more variables. To the point where you would need to have the full lcat and cache and so version of the original photos to mess with - and that might be gigs of data transfer, and would be much harder to implement with additional users who all may need to edit those same images.

So in this case if it's just "you", and you need to travel with the photos, just sync and go - import any new pics onto the laptop / edit whatever and sync upon return. The rest of the time you can sit on the couch with your laptop and edit wirelessly to your lcat on the desktop in the office with the "master files".

The concept of "offline files" is a pain to implement for multi users, and most companies try to avoid it. Single user access it doesn't do too badly, but..
Other users have had success with a variation of using drop box to store everything - but that can be excessively large.
- open account / create local drop box folder
- stuff lcat and stuff in there / it syncs
- laptop, add drop box and folder / sync down lcat and stuff
- lightroom - open lcat file in the local drop box folder
- make edits - they sync.
- at home, wait for sync / make edits.
and so on.

I like content aware 😉 But I agree that the book and map modules were basically a waste of developers time, relative to what photogs need...

that's why I thought they should make a "BrightRoom"
I posted about it earlier today.... in your "would be a good improvement" thread "three up" from this one...

Ok, in the spirit of adding to the concept and topic (and before calling it a day), here is my vision:

From the photographer's perspective, his data is his pictures. That includes the image data + the metadata (including dev settings). Both are interrelated and should be seen as one single object.

A great collaborative/multi-computer workflow would be:

- I import photos on my computer.
- I can push the photos (and metadata) to a central repository.
- I can check-in changes to that photo and metadata to the repository again if I made changes.
- Colleagues can "check-out" the photos + metadata (again, same entity) on their computer and eventually check-in changes to the central repository if need be. (check-outs would involve fetching the master file only if it does not exist and the same on the target computer)
- I can also check-out photos on my laptop and leave the "office" to work on them off-line and later, check-in my changes.
- There should be a way to back-up/replicate that central repository.

How is this implemented, I don't really care as long as it works. It will probably be two things:

- A centralized database of some sort
- A centralized file vault for the master files

Along with a version of LR that can orchestrate changes on both...

How about that?

I use apache for my webservers, that's old tech. Having reliability and quantifiable support options are not a sign of weakness.

Windows 8 still has dos command prompts.

Simply, I'd like to see a solution, Adobe has an option that is "easy" to implement. Building half-as*ed software is the current trend, and has been for years.

It's all about planned obsolescence. I will not upgrade further unless they start to shore up the platforms they "halfheartedly" design.

The features LR has now, like PS and all the rest, are mediocre updates with an addition of "some major feature" which itself is flawed - or for show only. LR at launch was unbelievable! - now it's unbelievable!?

If my tools cost me more to use and do less than they should, how long do you think it will take for me to simply get rid of the tool?

I never needed "content-aware" or "a book module" - I needed 64bit scalable multicore processing with gpu performance increases to match my 5 year old computer that had them.
But hey, sure, that had me upgrade to cs6. and now Ai cant use gpu well, has a 220px limit ?!@!!, PS is just weird to use since cs5, In, Dw and Fw are 32 bit, non similar interfaced crap running on javascripts. Adobe should be ashamed.
I can't even mention the 5.5 debacle other than to mention it. And cringe.
I sit here cringing.

LR doesn't even need an external server, it's all built right into the core.
It's just not able to be implemented cross platform, reliably.