Lightroom Classic and CC: Allow Catalog to be stored on a networked drive.

  • 400
  • Idea
  • Updated 1 month ago
  • (Edited)
I'd love to make LR more multi-computer friendly. I have no doubt that there's probably database architecture issues and a host of other barriers... But I have to believe that the need for either multi-user or at at lease multi-computer use is widely desired. And yes, I know you can do the catalog import export thing but I find this less than ideal.
Photo of BenD

BenD

  • 25 Posts
  • 10 Reply Likes

Posted 8 years ago

  • 400
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
Did I say years, I can't remember, it was late. Anyway..It'll take more than a week for sure, and it would still be SQL based. Pointless in my opinion. There are so many better DB's out there for this kind of MAM work.

MySQL is well known for being a bit temperamental with wide search criteria, Fact. Anyway, we digress.

"There is no reason why the catalogue can't be shared on any "mainstream" network. "

Correct, i'm merely saying that with that comes caveats as long as your arm. Support becomes a nightmare and the program becomes something that needs specific knowledge to actually make work.

All LR needs to become more collaborative is a better workflow for exporting catalogs and relinking media. The rest is fine. You'd do better to address the main stream of thought as opposed jumping on a specific sentence
Photo of Axiom

Axiom

  • 111 Posts
  • 9 Reply Likes
wow
if you think exporting your "whatever" is an applicable workflow than there is nothing more I need to say.

Earlier, I mentioned that I have lcats for different aspects of work/play, etc. I had photos on my sd card that needed to be in two locations yesterday, so I imported into one catalogue, tagged, and then exported what I needed in the "other" lcat.

That process took 2 minutes to export, import and go back to the original lcat and delete. Each time having to "relaunch" lightroom into the other catalogue, foolishness.

And that was for 100 photos.
Those "two minutes" can occur upwards of ten times a day.

So I wholeheartedly disagree that to do this in a work environment with others having to do the same thing is a colossal waste of our time. And the drop box solution is also a bandaid without privacy, and if another person sharing the folder deletes something by mistake you all loose the file.

Additionally because lightroom is so underpowered, regardless of what database structure it is built on, it's simply impractical to have one massive lcat for anything - especially due to the band-aid approach of importing and exporting.

As for your "caveats of issues as long as my arm" in dealing with networking, again, you should examine the devices you can buy off the shelf at any staples, future shop or best buy - or swing a cat and pick another retail outlet - and you'll find though they all have different packaging, they all work on the same network platform - tcpip, smb, etc. Reinventing the wheel and going against the grain is exactly the issue here.

They built on a system that does not allow sharing, that was a bad design choice, and people are complaining because Lightroom was touted to be this, and instead it's that - but still sold as "this".

Lastly, if by so many other database platforms out there you mean less than ten - and half of which are SQL or based on SQL and the other half are platform specific, outdated or discontinued, then sure, there's a veritable plethora of alternative solutions out there.

Personally, I love Filemaker which is not based on SQL - but does play nice with some aspects of it through ODBC etcetera - but that is NOT mainstream and implementation would be difficult to make Lightroom run on that for all platforms, and it's whole internal structure would need to change rather than just a couple of syntax alterations - so no, proper SQL is the easiest "best fit" approach.
Photo of Andre Malenfant

Andre Malenfant

  • 65 Posts
  • 4 Reply Likes
You are basically adding to my point. I should have a tool to do that properly, not have to copy files around and do anything manually. The worst backup solutions are the manual ones. I should be able to import in LR, do my "creative work" and be reassured that LR is doing the backup part for me in the background. I can rely on Time Machine or other commercial tools for backing up, true. But that only takes care of the files and not the catalog information. Where is my solution for the catalog backup? The basic catalog-copy function that is called a backup solution is not really smart. It basically copies the catalog file to a new file. Does not keep deltas, does not help me when I moved files around, etc.

I travel a lot. I could buy hundreds of CF cards I suppose, but it would be far from a good solution. I need to import images from the card(s) and automatically backup the images elsewhere. I also need to backup my precious catalog information as a lot of stuff is in there. But, shoot, nothing exists in LR to do that simply...

The software industry had that problem for years and came up with Source Control Management solutions that are fantastic and I don't see why LR could not start taking ideas there. That is already existing technology, not rocket science...
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
LR probably isn't the best solution for you if you are dealing with such quick turnarounds when travelling. Sure, it may be worth while having a LR catalog based system in the office, but on-shoot.. Photo Mechanic? It's far quicker and easy to deal with when using it on a shoot
Photo of Andre Malenfant

Andre Malenfant

  • 65 Posts
  • 4 Reply Likes
LR is perfectly fine, it is great EXCEPT that it does not offer great capabilities for asset management.
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
what kind of capabilities do you need other than it being a shared check in / check out scenario
Photo of Andre Malenfant

Andre Malenfant

  • 65 Posts
  • 4 Reply Likes
This thread is becoming impossible to follow, we are shooting in all directions ;)

I addressed that in another comment... check-in, check-out, all including pulling/pushing master files to a central repository, while keeping the local database option for portability.
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
I believe you have wholeheartedly missed my point
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
I split my LR catalogs up into 'camera shot', i then have hard drive publish services for clients and other client based delivery types. I import to multiple drives at teh same time so I fairly do the same thing twice.

Some services publish over a network where I pick up a catalog from the published folders. There's some scripting in the middle to make new directories for back up purposes. I also have an archive which sends content onto tape after a given time, that then publishes through to keep current work, current. My catalogs don't then get huge.

with SSD's in my machines, swapping catalogs is a blink of an eye

No, i'm not a big corp picture house, but even so It's about using the tools to the best of their ability, adding better tools to pick up the slack, then with a bit of massaging and scripting to tie it all up.

But my point was, keeping a catalog local or a cache of, then sending that to a server is better than working directly off a server.
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
I don't personally use an iMac but I know lots of shooters that do, even taking them to shoots, shooting tethered. They are fairly small to lug around. I use a Mac Pro for my studio work and a Macbook Pro for location stuff. I tend to copy my catalog folder over to the Mac Pro after location work, then copy media and update the path.

This is where I do disagree with a lot of people, in that a program was never custom built for just one person, it wasn't built to serve my workflow anymore than it was to serve yours. Aside all the things you expect 'in the box' as far as photographic necessity, there are many things that just need to be custom built to serve the specific client needs.

Re: Flickr. Exactly, and I think that's what one has to do.

One thing we haven't touched on and as an idea. As far as Multiple person environments are concerned, have you tried to publish original format (DNG or other RAW) images onto shared Storage, then each person builds their own catalog? Ok, so you aren't sharing catalogs, but you are sharing media that has been designated to be shared. Each user can then build up their own catalogs and export them. Assuming you have all the media on shared storage, paths will be the same
Photo of Axiom

Axiom

  • 111 Posts
  • 9 Reply Likes
The method you describe of a shared folder of originals and moving the lcat folder and previews around is a basic form of sharing that we do at home - local lcat pointing to the shared folder.

For home use this is "fine" - in an I can yell at it but live with it kind of way, but it presents issues with the lcat folder being huge, and laptops being wireless and time being at a premium.

Plus, to move from her machine to mine, to the kids and everything in between, well it's a pain at the best of times.

Any develop edits made to the originals of course remain in the shared area, but to "see" what has been changed and access those on another machine, you have to load/copy/move that lcat folder to that machine. Or have two lcats and always "synchronize" which does not grab metadata unless you have sidecars.

Publishing is simply a "live export" folder and is great for final copies for, well, publishing, but not for live access tracking over multiple machines, nor do collections apply on independent lcats.

If the lcat folder could be read by multiple machines, then all the woes vanish, regardless of even where the photos are stored. (we are not dealing with cloud stuff here, just local access)

So whether you want multi users at once, or multi machine access incrementally, there's just simply no option but manual, migration, exporting, copying, and scripting.

Now if it's only ME using the lcat, then yeah, i can - and do all of the above to manage my crap - and I have extensive and private cloud access on my own servers, so I'm not worried about access for me when I'm out and about - but it's still insanely time consuming (and slow since you still need to transfer data).

And honestly, since i DO know better, I simply cannot remain quiet any more, because I'm so much more tired of being spoon fed by companies that dole out functionality bit by bit whilst advertising how awesome some "newly invented" basic function is (that everyone else has had for years) - when they finally release a tidbit in the "next" upgrade - when ever that is.

*cough* iphone cut and paste....

Try adding a collaborative environment where you have multiple editors trying to manage a client production, and you're simply out of luck - without bizarre and overly complicated workflows - so you're limited to harassing one guy on one machine.

CS6 is the last upgrade I'll be doing with Adobe until they start giving back. I've paid for the right to have competency, and I'm not seeing it.
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
The method you describe of a shared folder of originals and moving the lcat folder and previews around is a basic form of sharing that we do at home - local lcat pointing to the shared folder.

No, i mean create new catalogs per user, pointing to published originals. I do, do the above for quick and dirty
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
I guess it's about trying to keep a develop workflow up and running without having to publish
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
Try adding a collaborative environment where you have multiple editors trying to manage a client production, and you're simply out of luck - without bizarre and overly complicated workflows - so you're limited to harassing one guy on one machine.

I work with these guys

http://www.squarebox.com/

This is based on whatever flavour of SQL you want. It's fully server compliant and users query a DB with shared catalogs. Metadata can be added to the already 'baked in' metadata with the option to add 'user fields' to catalog tabs. It's mainly video workflow but does support XMP.
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
I wouldn't say it's a work around, I just choose to boost what I can. More RAM, an SSD. My LR cache also sits on the SSD. WIth a decent amount of RAM too catalogs are fine. Stuff never works out of the box, that's a myth :)

Network-ability is an obvious new feature request we could all do with, but I just wouldn't trust writing over network connection to both media and sidecar files. I would rather it be a local DB that pushed changes after it saved them.
Photo of Axiom

Axiom

  • 111 Posts
  • 9 Reply Likes
true, but one size should fit "most"
Lightroom only does so superficially.
All of my "arguing" has always and only been about the inherent core flaw of choosing SQLite. Changing that is rather easy as SQlite is based on mySQL so it's not a huge endeavour.

What I'm not interested in is asking for "one size should only fit me" as that's why we have other business to acquire "add ons" and "plugins" from... so I can customize - like you have.
But the core framework should be just awesome to build from initially.
With the cost of Adobe apps in general and recurring and "fundamental" issues being unaddressed, I can do little else but sit here and loose faith.
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
Sure, I see where you're coming from, but I have to produce, and waiting for Adobe to fix stuff, well. I'll be broke and homeless before they address a lot of the fundamental stuff. So, I have no option but to make it work
Photo of Axiom

Axiom

  • 111 Posts
  • 9 Reply Likes
I hear that... I'm familiar with mongo as well, and though I'm a staunch supporter of open source - to keep one size fitting all - and to not simply duplicate similar problems that have arisen by choosing the open source SQLite - it's best to stick with tried and true... Ya know?
It's like the devil you know - but with volumes of support options, fixes and forums... There will always be some thing perceived as better "for this reason or that" but it's the easiest path to take if adobe makes an effort.
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
It's like a kitchen: Buy an expensive Kitchen and install it yourself and it'll look ok, buy a cheap Kitchen and get an expert to install it, it'll look better than the kitchen worth 5 times as much. Bear with me ;)

I have a product up and running on Mongo, it's been in production at a big corp site for about a year. In fact, anything you watched of the Olympics last year was probably held in a mongo DB
Photo of Christopher Loffredo

Christopher Loffredo

  • 3 Posts
  • 0 Reply Likes
I still just looking for basic functionality from Lightroom. I'm a single user.
All photos are on home network, that I can access from multiple computers, laptop and desktop.

I just want to store Lightroom catalog on my network drive with photos.
This way access LR and photos and backups are easy.

Having to have Lightroom catalog on a portable drive and carrying it back and forth and doing separate backups is a pain.

I'm not a techie. I love a simple solution. Today my simple solution is I user Bridge much more than LR. I would not upgrade LR. The basic concept of a database is great. Databases sit on networks. I'm not a techie and I know this.

This is basic functionality. Have multiple users access LR simultaneously, is a different and more complex issue. Business need that for sure. The hobbyest like me, that way overkill.
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
I posted this the other week, http://www.squarebox.com/

I've put a few ideas into this software and I put it in a various facilities, SQL based whatever flavour, but it's very complex. LR could quite easily go this route, but for me, it's Pro's are the fact it's a simple GUI that is easy to follow
Photo of Andre Malenfant

Andre Malenfant

  • 65 Posts
  • 4 Reply Likes
GUI has nothing to do with catalog storage. All we are talking about is taking the data that is stored on the lrcat file and allow it to be stored in a remote SQL server, one that will allow for more advanced management of that data. The GUI would stay exactly the same.
Photo of Andre Malenfant

Andre Malenfant

  • 65 Posts
  • 4 Reply Likes
And about SQL being old. There is yet to be a replacement for it. There are a bunch of object database projects out there and some very advanced ideas for future DBMS models but SQL is still the current valid one. It is (relatively) old but still current, not obsolete.
Photo of Axiom

Axiom

  • 111 Posts
  • 9 Reply Likes
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.
Photo of Andre Malenfant

Andre Malenfant

  • 65 Posts
  • 4 Reply Likes
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...
Photo of Andre Malenfant

Andre Malenfant

  • 65 Posts
  • 4 Reply Likes
Would be a good improvement and may be a step forward in fixing the missing/poor replication/backup features. Lightroom is great to organize and catalog images but designed around the single computer environment (strangely, the database architecture opens a lot of option here but not used much).

I am happy to see people talking about moving to a proper SQL server (optional) as this would opened a world of possibilites in terms of features AND performance. A proper SQL server would improve performance immensely and allow for multi-user, multi-computer and proper backup solutions.

Lightroom would still require a master file backup/replication feature but that would be a great step ahead...

See my idea about backups. It may not look related at first, but if you think about the whole issue at a high level, it is pretty similar...

http://feedback.photoshop.com/photosh...
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
I could see a 'Share' tab being more useful than a collection or export based service, meaning that it's catalogue wide functionality and not just an 'as and when' function
Photo of Axiom

Axiom

  • 111 Posts
  • 9 Reply Likes
Thing is though Stuart, is that Adobe could do this now and make not only just as much money, but regain some of the old clout they used to have when they had innovative software. You know, when other developers tried to catch up to them.

Now it's Adobe is like a lame thoroughbred. Trying to catch up with all the trends, none of the functions.

I mean come on - who makes software built one a database platform without using any feature of the database but "search".

It's like they all sat around in the coffee room and were like
Hey?! bet we can write a program in BASIC and sell the snot out of it.

10 print "Hello Sucka's"
20 goto 10

Lightroom and aperture and capture one all "do" the same thing - they are like Canadian and US "big three" beer companies all making the same flavour beer and simply advertising it to death.

It used to be though that Adobe was the microbrewery making such awesome stuff we paid through the nose for.
Now? It's MySpace.

I have bought adobe since 1994. I've been faithful - for like evah.
Sure I've used corel, gimp, quark, blah blah

But in the end it was like we had software made by designers - for designers - and it was awesome.

I miss those days.
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
I hear ya!

I have an old copy of Quark 3 and PS 4 if you wanna go back to the good ol' days :)
Photo of Axiom

Axiom

  • 111 Posts
  • 9 Reply Likes
ha ha ha oh I have all the original disks...

Whats interesting about your offer though is the fact that aside from a few bells and whistles, the core features of even PS3 are more than adequate for today's productions - the only "advancements" are tools for use to be less a "designer" and more of a "filter user".

Sure we've had software advancements based on hardware advancements - but then again, case and point - the epic fail of LR being a full fledged DB software tool. Since the early 2000's we've had stable database solution for sharing, and yet here we are, 2013, no men on the moon, no flying cars, and no implementation of 13 year old database solutions.

My router has more guts than LR.
Even windows 3.1 had sharing right out of the box - and permissions.
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
Absolutely, I have only recently upgraded to CS5 because it was a proviso of a recent job
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
Yes, agreed this thread is becoming a nightmare to follow.. I need a drink..
Photo of Axiom

Axiom

  • 111 Posts
  • 9 Reply Likes
Topic replies vs comment replies is the issue...
If you find a comment to reply to, keep to that comment's idea thread

leaping to another comment thread to continue the points is what's causing the issue so let's recap :

LR needs some form of collaboration / multimachine use.
Other ideas came forth about merging LR and Bridge.
Hard drive usage is not at issue
Database implementation is easiest if kept in the same vein the originating engine is built upon.
Photo of Andre Malenfant

Andre Malenfant

  • 65 Posts
  • 4 Reply Likes
Right, thanks for the move...

About merging Bridge with LR. Bridge looks like it will stay alive as LR does not allow managing assets from other CS products and it is photographer centric and may not suit other creative designers but Bridge's sharing capabilities rely solely on sharing capabilities of the network and file system. Hardly a good solution for concurrent updates and performance. I say performance because bridge needs to scan files to grab the metadata. It caches the information but cannot compete with proper SQL engines for searches on a large volume of data. Concurrent updates because files systems do not have built-in support for concurrent updates, whereas SQL servers are pretty good at it...

Agreed, storage technologies have nothing to do with the topic...
Photo of Axiom

Axiom

  • 111 Posts
  • 9 Reply Likes
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...
Photo of Andre Malenfant

Andre Malenfant

  • 65 Posts
  • 4 Reply Likes
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?
Photo of Axiom

Axiom

  • 111 Posts
  • 9 Reply Likes
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.
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
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
Photo of Andre Malenfant

Andre Malenfant

  • 65 Posts
  • 4 Reply Likes
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...
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
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
Photo of Andre Malenfant

Andre Malenfant

  • 65 Posts
  • 4 Reply Likes
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 ;) )
Photo of Andre Malenfant

Andre Malenfant

  • 65 Posts
  • 4 Reply Likes
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...
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
Elvis, as in the DAM. http://www.woodwing.com/
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
I'm concentrating on the users that occupy an office as far as using a network system is concerned. That is more difficult to achieve with LR in it's current state.

I would argue that the 'Online' collaboration you speak of is already totally possible with LR. Ok, you may not have a check in/check out possibility, but publishing RAW files to a central location is more than possible.

You would then get into versioning these edits. A single FTP shared folder where RAW files pop in, you work on them and export them out, or publish an edit back to the FTP.

For anything more robust, you'd not be using LR in my opinion
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
"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, you've told me you want it, but you haven't really given me a reason why you need it. Can you describe a normal shoot and how you are handing files off to the other users, and how having LR in a 'remote' state would be beneficial.

Aside the obvious tracking of history, edit presets and filters from the LR GUI
Photo of Andre Malenfant

Andre Malenfant

  • 65 Posts
  • 4 Reply Likes
Any of my recent "normal" shoot. I did a lot of product shoots recently. I need to edit the photos to a degree, then share the results to my "client" (who happens to work with me) so he can rate and select the shots and maybe apply some tentative crops. Then I want the metadata to flow back into my catalog so I can work more on the photos. I have done many projects recently like that.

I am also working on a collective where we want to share images. We can share exports (jpegs, etc.) but it is nice to be able to see the actual dev settings to comment and collaborate on the processing approach.

The only viable way now is to export the files into a new catalog. Share that somehow via a network, a USB key or ftp, dropbox, etc. Then the other user opens that catalog and do his work. Then send me back that catalog and I "Import from Another Catalog" back into mine with the other user's change.

These are just two examples. I don't think I am alone in this situation. If I were, there would not be an export/import function to start with.

This works but has issues:

- The export/import process is a tedious, takes time and does not allow me to continue to work while the images are being changed by the other user. If I do, I either loose my work (it's still in the history but) or end up with a virtual copy on the side that I have to merge manually. If there was a way to import just the metadata or the dev settings independently, that alone would help. A proper merge screen would be great too. Should be possible considering a XMP file is just a "recipe", a list of operations "to do during export" and it would be great to select which steps to take or not from the import.

- The actual sharing of the exported catalog (and master files) has to be done manually outside of LR. I can use ftp, dropbox, etc. But it is still not integrated to LR. Exporting the catalog with the digital negatives help as the photos end up in the same folder as the exported catalog. Then it is just a matter of sharing that folder, no need to "gather" the master files. Still, I wish I could just allow a user to connect remotely to my catalog, browse, edit and see the changes appear instantaneously, without having to Export, copy/send, wait, Import...

I know how to deal with it within the current LR limitations. I don't contribute to that thread to have help on how to deal with LR shortcomings. I just wished there would be an integrated, easy way to collaborate with my team members. Something that would not force me into figuring out a compromise solution...

I realize I might have been spoiled by more robust collaborative systems in a previous life. I still think there is room for improvement...
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
OK, so I have got 3 users all being able to exchange XMP data, track edits and sync. Caveats being you have to create separate Catalogs on each machine and 'add' images to the library, not move, from a central location.

Ensure that you have write XMP data ticked in your catalog settings.

Create a new catalog locally. This brings into play the idea of backing up etc etc.
Point your catalog to the shared folder you need and add your images.

For added collaboration, export all filters and presets, plug ins and edit prefs. Importing into each LR user (easily done )

Do this for the users you need, ensuring you have XMP write data checked in catalog settings.

Any change made will update your image status either by importing settings from disk



or syncing the desired folder



I have tested this with 3 users on a LAN, ie my running round 3 machines. I can track all edits, track metadata, add and edit metadata, apply edits and export each version (to another server folder called Edits, for example)

The XMP isn't the quickest to update, but it's pretty instant.

Et voila!, LR on shared storage
Photo of Andre Malenfant

Andre Malenfant

  • 65 Posts
  • 4 Reply Likes
I come from a software industry background. So I realize that my views are biased by it. But if software companies had to manage source code the way LR and your workarounds do, it would be a catastrophic mess.

I see the photos + the metadata as source code for photographers and creative teams as team of developers (they are different but the workflow needs really intersect). The same collaborative needs. The software industry came up with great patterns that could definitely be reused for managing our assets.
Photo of Andre Malenfant

Andre Malenfant

  • 65 Posts
  • 4 Reply Likes
Axiom,

I get you, I was talking about Bridge in the context of photography, period. Bridge is meant to be, well, a bridge between components of CS. It is a specialized file browser for the Adobe products. I know it has a lot of features for that but, for photographers, there is nothing more in Bridge than in LR, in fact less since LR is better integrated with CR (the develop module is CR with some extra bells and whistles like the History, a very welcomed addition).

To continue in that direction, I would say that LR should be integrated to PS and not Bridge to LR. Maybe the PS functionality as a paying option but there is complete overlap in the CR part of PS and LR and PS could definitely have a face lift as far as asset management goes. But then it is Bridge's job... There is some reengineering to do at Adobe... Bridge is outdated and becoming obsolete for photographers (but not for other creatives) and photographers now wish for a tighter integration of LR and PS. Another subject, I guess...
Photo of Axiom

Axiom

  • 111 Posts
  • 9 Reply Likes
HI Andre...
okay, let's look at the system adobe has created - bridge: a file browser, LR - a photo browser, PS - a paint program, Ai - a vector program, In - a typography program, Fw - a web imagery program, Dw - a web coding program

Each of these things are what they are, except for two.
BR and LR are the same thing. It's why there are so many OOODLLEESSS of threads on the topic. Because they are totally different also.

PS has it's place for in depth actions against a pixel.
LR is not that - it is a lean mean cataloging machine with the BONUS of some rather awesome - but "tiny" editing tools to get your photo published NOW, not after days of "airbrushing"

Bridge, well, because adobe didn't make previews for our OS's windows, and stuff, we HAVE to have - or we buy other plugins for our systems.

The point is that LR should NOT be PS in any way - it's not cost effective for the end user and it muddies PS performance, and muddies LR's performance and you would have the worst of both worlds in one PhotoRoom and this thread would be way worse. lol

Really I guess Adobe needs to make a Multimedia Asset Management program.
You set up folders for all your crap - and then catalogue it all.
You then simply click your crap and it opens where you want it to for editing - being it LR as a lean editor - or PS for restorative stuff or raw creativity - or Ai for vector and so on.

But that's inventing a new and ground breaking thing and so I don't anticipate it coming out of adobe anytime soon.

Instead we HAVE LR which if you simply added recognition of other file types you have a ready made catalogue. That's half the battle. Ditching bridge then frees up resources for their coders.
So merge the two "little" players that duplicate tasks and be done with it. Then you can free up the ole bridge team to make it sharable.

I don't want to reinvent the wheel, I just want proper tires and not these stupid plastic "Big Wheel" things.
Photo of Axiom

Axiom

  • 111 Posts
  • 9 Reply Likes
:: adendum - as a photographer, there are times i'd like to fire up a related program and stuff a photo into it rather than export and find and place and man this is a waste of time...
But I have to close LR, find the document, open it, browse to place and man I could have been done by now.

We have nifty tools and none of them play nice - which is so bizarre cuz they all come from the same manufacturer.

my 2003 tv remote allows me to use my dvd player from a different manufacturer, so wtf?
Photo of Andre Malenfant

Andre Malenfant

  • 65 Posts
  • 4 Reply Likes
We essentially agree. Our backgrounds and needs are different but we are saying the same thing...

I like LR because it helps me avoid to use a bazooka when 60% of the time I only need a fly slapper. I could use the Bridge + CR combination but the LR GUI alone is enough to make me want to us LR.

But when I need to do heavy lifting, pixel based editing is needed.

You are suggesting to beaf up LR to also handle the other asset types and this can be a solution. The only thing is LR is really built with photographers in mind and that would mean to risk loosing the photographer focus. Maybe not. I haven't carefully thought about this option.

In any case, yes, Adobe needs asset management...
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
"My question now: why do you categorically refuse to talk about improvements? Why do you so badly want to prevent LR from moving forward with collaborative features? (aside from your previous arguments about stability, focus of the dev team on other things than image related feature)?
"

It's not that at all, I just can't see Adobe spending anytime on it, given what they push with Adobe drive, Revel etc. It would be great to see LR networked, built on SQL, but the coding has to be spot on otherwise we'll run into all kinds of Java errors, exceptions etc.

From LR 3 through to LR 5, what has actually happened? A new brush tool, smart previews and as I can see it, it now runs slower.

I love LR for it's ability to catalog, simply and with no fuss or custom forms. It does a few things very well and is cheap and negates the use of PS (as I use it)

Have you used Adobe prelude? It's more video related but it would be nice to see LR, the photo version of Prelude.
Photo of Andre Malenfant

Andre Malenfant

  • 65 Posts
  • 4 Reply Likes
Java errors?

Anyways... The performance degradation has all to do with the more powerful editing tool. The "recipe" approach has it's limit. But there is not reason why allowing to run the catalog on a dedicated SQL server would affect performance. The performance issues people are experiencing are mostly in the development module. To the contrary, allowing remote catalogs on proper SQL engines might speed up the Library module significantly.

"negates the use of PS (as I use it) "

That depends on your style of photography and the end product/client. There are many things that cannot be done in LR and Adobe would be fools to risk the PS revenues, considering the price tag difference.

"Have you used Adobe prelude?"

Heard about it but thanks for reminding me. Will look at it to have an opinion ;)
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
The only reason I use PS is when I'm editing images via one of the Nik plug ins. (or i have to do soem actual manipulation which is rare as I mostly shoot wildlife and portraits) LR's implementation using these plug ins is dire. So, I'm in LR, I edit via PS, add a layer, convert to a smart filters and add the plug in.

Using the Nik plug ins directly from LR creates endless virtual copies which is a pain
Photo of Andre Malenfant

Andre Malenfant

  • 65 Posts
  • 4 Reply Likes
For anything other than light healing, PS or Gimp is required. If you do not do the kind of photography that requires it, LR does the job. Which is nice because you get a cheap solution, easier to use than PS for most. But at the end of the day, LR's editing features are just Camera Raw's, very limited.
Photo of Axiom

Axiom

  • 111 Posts
  • 9 Reply Likes
andre - negating PS 's place in production is limited to the scope of the scenario I painted for Stuart. When you're slapping articles together you don't need the bloat of a photo editing program like PS... LR is more than sufficient for a crop, perspective shift, and colour and light and tone balance.

Besides, I'm not going to hold up a $100 bit of code to a $1000 bit of code and say hey, how come this doesn't do this?
Photo of Andre Malenfant

Andre Malenfant

  • 65 Posts
  • 4 Reply Likes
agreed. PS and LR are different beasts. PS is an optional step in the LR workflow but not needed all the time. LR speeds up things considerably and I want to keep using it for that reason
Photo of Axiom

Axiom

  • 111 Posts
  • 9 Reply Likes
stuart - for speed, try moving the modules you don't use into a "disabled" subfolder - bet you see an improvement.
I haz a thread on that in here and elsewhere.
Photo of Mark Swink

Mark Swink

  • 20 Posts
  • 7 Reply Likes
Obviously multi-user is something that is of great concern and appears to be something Adobe plans to ignore. Workarounds are fine for temporary fixes but shouldn't have to be continued forever. They can keep the downgrades to LR5 if they can't add true multi-user support. There is already so much bloat in LR with all the shine that 99% will never use that the program is becoming something akin to the Emperors new clothes.
Photo of Mark Swink

Mark Swink

  • 20 Posts
  • 7 Reply Likes
BTW, the continuation of this discussion is pointless without recognition by Adobe that this is a needed feature they are working on. It only serves to further remind us of a fact we are well aware of and that is that LR is missing a core component present in almost every piece of software developed today.
Photo of Axiom

Axiom

  • 111 Posts
  • 9 Reply Likes
Hiya Mark,
I've actually found some informative stuff through this thread - you should tuck in with a hot coca and have a read lol
There are a few valid work arounds, that of course are beside the point but useful nonetheless.

I shall remain on the thread though as i have this soap box here, and it does require use *smiles*

Beside, if we give up... the Adobe wins.
Photo of Mark Swink

Mark Swink

  • 20 Posts
  • 7 Reply Likes
Adobe only wins if we continue buying version after version without the tools being added. If you want to win at a business game, you have to speak with your checkbook. If software upgrades don't include the core components they should then don't buy them until such time that the programmer realizes that the sales have stopped or considerably slowed because of the lack of implementation. As many have said; doing the same thing over and over again but expecting a different outcome is insanity.
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
I don't think it's a win or loose scenario, you buy their products to create and make money and with forums and idea rooms like this, those ideas can be sent over to developers and the guys who hold the purse - If they don;t impliment what you want, you jump ship.

The period when Apple bought out FCPX, Avid and Premier were biting at the bit to get users on board with new features and price cuts
Photo of Walker Blackwell

Walker Blackwell

  • 7 Posts
  • 4 Reply Likes
-->Bridge's sharing capabilities rely solely on sharing capabilities of the network and file system. Hardly a good solution for concurrent updates and performance.--

Not so. Since something like the second version of Bridge, premium customers have been able to implement a DAM server for bridge to check in and out files. Now it's called something like Adobe Drive. I used it back in the day.

What did this nifty software use for keeping everything version controlled and checked in and out? Yep. MYSQL.

---I say performance because bridge needs to scan files to grab the metadata. ---

LR does as well. Sidecars and some embedded xmp. Not all by any means. (All of this is limited by the FS IO speed.)

---It caches the information but cannot compete with proper SQL engines ---

see above statement. Locally, no, it can't.

---for searches on a large volume of data. Concurrent updates because files systems do not have built-in support for concurrent updates,---

sadly ZFS was killed in OS X. There are many concurrent-use algorithms and even file systems that can do this. Implementing a virtual file system sandbox would mess things up and slow things down though . . .

---whereas SQL servers are pretty good at it...

Agreed, storage technologies have nothing to do with the topic...---

Storage tech has everything to do with it. It's the reason why Adobe has not been able to implement good multi-user with almost any of their software. Too many different file systems and networking share protocols. It make it very hard to create a client-only type sharing situation (think iTunes) with multi-gigabyte sets of images and more than 100 concurrent transactions per second. But many applications already do this. It's not impossible.

Probably a client/server architecture is needed like Adobe Bridge, Indesign, and a slew of other Adobe products in use today.

A good primer on anyone on this list wanting to understand concurrent editing tech should read this:

http://www.waveprotocol.org/whitepape...

and this

http://en.wikipedia.org/wiki/Operatio...

Maybe some of the rants will simmer down a bit and people can start thinking critically.

--------------

What we are asking for on this forum is a pretty hefty amount of programing. Right now I can select and batch edit 100,000 images in one swipe on LR. Enabling something like this in a 50 person multi-user environment like the NY Times could be totally bonkers. There are some major and complex details to work out if concurrent or multi-user was implemented especially in a non checkin/checkout situation.

Does it mean that we shouldn't be asking for this feature? No. It's a really really needed thing, much more than better retouch tools or some nifty little button or other.

Best,
Walker Blackwell
--
Black Point Editions, Founder
Latitude, Co-Founder
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
However, Avid have used proprietary storage for years and only recently have 3rd party manufacturers been able to 'get hold' of the file system goodness.

This is something i envisage Adobe trying their hand at, and so building adobe file storage based on Adobe drive and therefore making a file system that just works with adobe products. No, i'm not talking about psd's or stuff like that, but using it like Avid have used ISIS. You want to use our products, you use our file system. In a similar way they have gone down the 'apple app store' route with their products, cutting resellers and everybody else out of the chain.
Photo of Andre Malenfant

Andre Malenfant

  • 65 Posts
  • 4 Reply Likes
Walter, thanks for the clarifications on Bridge's potential integration with a DAM server, I was not aware of that. Something I will look into.

"LR does as well. Sidecars and some embedded xmp. Not all by any means. (All of this is limited by the FS IO speed.)"

yes an no, the metadata is stored in the catalog and LR does not scan the XMP files when searching in the Library module. It will only pull it if the user refreshes the metadata manually. It uses it's SQL lite relational database. Bridge (when not connected to a DAM server at least) has to scan XMP files to build a metadata cache to allow searching. My point was that a proper SQL server would speed things up compared to SQL lite and certainly compared to scanning tons of little files on the file system (and worst on network storage for archives). Database servers are optimized to do that kind of thing with high performance caching, memory management and storage management to overcome the FS limitations while digging in relational data.
Photo of Andre Malenfant

Andre Malenfant

  • 65 Posts
  • 4 Reply Likes
"What we are asking for on this forum is a pretty hefty amount of programming."

If Adobe would use current proven technologies to accomplish that and not re-invent the wheel, that would not be that big of an effort. Sure, it will take time and engineering but it's not like we are asking to build something that does not exist. There are environments with much much more complex concurrency problems at a much bigger scale today. The tools and patterns are already there and waiting to be used.

"Does it mean that we shouldn't be asking for this feature? No. It's a really really needed thing, much more than better retouch tools or some nifty little button or other. "

Cannot agree more. :) At least we can talk about it, maybe dream a little, no harm in that.
Photo of Andre Malenfant

Andre Malenfant

  • 65 Posts
  • 4 Reply Likes
Following the ideas on that thread, what we need it Adobe Drive integration with LR. That would open the door to much more powerful collaboration features...
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
That makes sense, given that all other Adobe CS apps have that integration. This also gives us check in/check out
Photo of Andre Malenfant

Andre Malenfant

  • 65 Posts
  • 4 Reply Likes
I refreshed my knowledge of Adobe's offering yesterday...

Adobe does have DAM capabilities through Drive, but only in a few selected products like Photoshop and Bridge and this does not include LR. Drive is only a connector to third-party DAM servers or CQ DAM (Experience Manager), Adobe's proprietary solution (formerly Day) that looks more like a CMS with check-in/check-out functionalities.

The marketing material is not utterly clear and there is no pricing information. It looks like an Enterprise system that is not meant for small teams and must cost quite a bit. It also looks like the same solution behind the Adobe Creative Cloud for teams.

Their Cloud solution looks interesting but only works for relatively small (or few) assets since checking-in/out RAW files over the Internet does not make much sense. Plus, it would not cover archiving as you are limited by the cloud storage space and we would still need to keep local archives.

Adobe seems more preoccupied by moving "to the cloud" and selling software as a service through subscription. It makes sense financially but does not cover all the needs. Let's hope LR will eventually support Drive and that we can connect Drive to an open source or relatively cheap solution...
Photo of Andre Malenfant

Andre Malenfant

  • 65 Posts
  • 4 Reply Likes
Indeed, it seems that that there is a market...

http://daminion.net/

Client-server solution, they call it the DAM for small teams. The client is free (at least the RC) and the server is between 210$ and 350$ per user depending on the number of users (perpetual license, 1 year support).

But it's a Windows only solution :(
Photo of Mark Swink

Mark Swink

  • 20 Posts
  • 7 Reply Likes
I will have to look into this. Looks like it may be a LR replacement with the network support that Adobe refuses to add.
Photo of cavlabs

cavlabs

  • 1 Post
  • 2 Reply Likes
@adobe
I had a look at the new features of LR5 and it looks cool. It's not too massive, so I expect it all to work fine. But why do you still ignore the simple fact that using the local machine as one and only storage for images is neither logic nor secure? There is still officially no support of network drives (though it works already with previous versions). But to make it worse, there is still no support for sharing a catalog. We are in 2013, people work together and you even have folks like me with more than one machine to develop images on. Reading thru the discussion, I'm not the only one. So why are you ignoring this feature constantly? SQLite is always given as the limiting factor. But if you folks are not able to implement a SQLite based solution that works properly, then simply change it. There are other ways to create a catalog and keep it consistent. It's not rocket science anymore, it's 2013.
Besides, I love LightRoom and use it daily. Just please add this little but important feature that is most likely useful for many (semi)professional users, not just me. Or just drop me a line if you need help defining a solution ;-)

Thanks!
Stefan
Photo of Mark Swink

Mark Swink

  • 20 Posts
  • 7 Reply Likes
Works for me. You couldn't pay me to put a mac in my house. Once I get rid of this iPhone later this year, I will once again be Apple free and plan to stay that way. I like cold boots in less than 10 seconds, compatibility with a multitude of professional software, and not being burdened with constant changes to connectors for every updated computer that comes out.
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
Whatever your view of Adobe, you'd risk 20 years of industry knowledge, based on what?

DamionRGB, nah. Hasn't got the same ring to it.

Better the devil you know as far as i'm concerned
Photo of Axiom

Axiom

  • 111 Posts
  • 9 Reply Likes
for a mac to pc change... i truly hate to say this but....
Hi, my name's john, and i've been a mac user since the dawn of macs.
I have finally quit macs because they no longer offer a unique platform for the technically minded - and here's kind of why... aside from "flash" they offer weaker performance (hardware) then a pc computer (custom built) for half the price. My pc's are tools, so I don't game and stuff, I use the web, and adobe (and the like), and thazit. Rarely am I in the "windows world" even though I'm using win8.

Additionally, for reasons we see here with SQLite - they do not network nicely with mainstream equipment in general. ALL manufacturers of highend output gear are PC first, and mac maybe. *cough* summa, epson, mimaki.

So that means my top of the line mac tower here cannot run my 60" epson printer. But an HP laptop I bought 5 years ago does just fine.

So I switched to PC, and my world had more money for play. Now listen, I know there are mac things that are better, but we pay more for form than we do for function, and that's literally what we are doing here with Adobe.

man CS6 is sexy. and I can completely get better performance from Capture One. I tried it. Blew me away - and frustrated me because it simply has a crap UI.

So I'm back to lightroom, because it's "easier" to live with the crawl with pretty than it is to be ugly and fast.

I'm ashamed of myself.

But. I am losing my patience, and I'm horrified LR5 has "nothing" i actually NEED.

I guess Adobe is making my mind up for me, because really, lightroom NOW has all I need, and it plays nice with win8, so I'm good with what I have me thinks. If it ain't broke right?
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
I also have used Macs for, well since I started using photoshop on a bondi blue imac running OS 8.6.

Would I use PS on a PC, depends where I worked and who for. I certainly wouldn't put them in for a client.

Macs have a legacy in graphics and for the younger generation coming into the industry, would be a shame not to carry on this legacy.

Same for Video and Audio. It's not just a statement that you see graphics, audio and video houses running macs, it's an application choice. It is as simple as that.

I used Capture one for a short time, and I did love certain aspects of it, although I actually prefer LR's RAW conversions ad as you say, the UI just isn;t as fluid as LR.
Photo of Andre Malenfant

Andre Malenfant

  • 65 Posts
  • 4 Reply Likes
Yes, Daminion, aside from having a weird name, only works on PC. I asked them if they had any plans to port to OSX and there are none at this point.

Anyways, interoperability with PS is important and I don't know how well it plays with other Adobe products...

The main point was to show that there is a need, a market and solutions that do what we talked about, for a reasonable price...
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
Non of my catalogs, previews, images, or XMP data, including my back up catalogs sit on my local machine.

I did post a solution (depending on your needs) a few days back which does work when connected to SAN storage, it still requires you to create a local catalog.

My local data resides on eSata based Raid 5 G tech drives.
Photo of Andre Malenfant

Andre Malenfant

  • 65 Posts
  • 4 Reply Likes
eSata drives may not be connected to your computer's internal SATA bus but they still qualify as local drives. A SAN would be limited to a Gigabit network, roughly the performance of USB2 when properly tuned. It is not exactly great performance...
Photo of stuartpeckphoto

stuartpeckphoto

  • 226 Posts
  • 2 Reply Likes
And therefore they are more secure than data that resides on a drive that also holds one's system data, functionally exactly the same except eSATA drives connected with either a Gtech or ATTO Raid card are faster, a lot faster.

The only single difference being the sharing mountable options with IP SAN storage.

There are many solutions out there now that mount thunderbolt, USB and eSATA as iSCSI mount points.

Apart from the steps I posted a few days back which was a quick and dirty solution. I have solved sharing catalogs and previews on shared storage.

Essentially wrapping the catalogs up and viewing them inside a GUI that I have been helping develop. I have had this working with all adobe products on shared SAN storage.

Alas, it's not quite an out of the box system as yet, as it requires a schema to be pre built but i've been testing all adobe products and with success so far.
Photo of Todd Weselake

Todd Weselake

  • 2 Posts
  • 0 Reply Likes
It would be great to be able to share a catalog over the network, with the ability to have multiple editors working on a shoot.

This reply was created from a merged topic originally titled
lightroom shared catalogs.
Photo of Bob Dole

Bob Dole

  • 6 Posts
  • 6 Reply Likes
There are workarounds to be able to do this. This would be for the case where you want to put your catalogs on a shared server so, as in my case, my wife and I can go through them to tag and rate our photos.

On windows you create a symbolic link using the mklink command.

mklink /d "c:\Photos" "\\yourserver\Photos"

Bob's your uncle.

It is just as easy in Linux and therefore Mac to do the same thing. Just search online.

I don't recommend two people opening up the same catalog at the same time, this is more for the use case where two people want to have access to the same file data.

Jim
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 386 Reply Likes
So, you *are* having your catalog on the net, using this method?

If so, I (and others, no doubt) have two questions for you:
1. have you ever had your catalog become corrupt? (more than once?...).
2. Have you noticed a performance penalty? (if so, in which context(s)).

This work-around has been known for a long time, but most Adobe advocates discourage it, so most users are too scared to do it.

?
Photo of Bob Dole

Bob Dole

  • 6 Posts
  • 6 Reply Likes
Performance, yes it will be slower, how much slower depends on a lot of things and what you are doing. For me, I just want to give my wife the ability to tag and rate photos. The other way to do this is to export a part of a catalog then integrate it later.

I wouldn't try and do Develop work this way, unless you really know what you are doing on the backend, perhaps NAS over fiber.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 386 Reply Likes
Thanks Jim, but how do you *not* do develop work this way if your catalog is on the network? Do you have local *and* shared catalogs...?