P: Include additional metadata in XMP (flags, collections, VC's, etc.)

@705730: This is exactly the problem. Or more, it is a bunch of problems.

First: it is _one_ file. So you always run into the collission problem for the whole export and not just for single pictures.

Second: it is an _additional_ file. I do not just have my file system tree of pictures, I also get a large heap of these export files, which I have to keep in order and organized.

Third: It requires manual interaction and thus causes lots of overheads. File tree syncing is cheap and automated, I'll to it anyways, and most business machines do it automatically without the need of user interaction. In contrast, a Lightroom export does not do anything at all automatically. Someone must sit in front of a Windows machine, start it, use the mouse, and must do the import manually.

Fourth: It's foolproof. If you have two machines with the same files, you know they are synchronized (or you can see, where they are not). If you have to machines with Lightroom databases, you never know whether they are in the same state or where they differ. Even if you have exactly the same contents, database files are never similar.

Sixth: It is not about accomplishing my objectives "without too much trouble using catalog export/import" I need to accomplish my objectives without the need to start Windows, run Lightroom manually, check all that things, and never be sure as if everyhting happend as expected, just for my daily notebook sync/update.

Don't you understand that the idea of having Windows as an operating System and Lightroom as an interactive program be started and operated with the mouse for every single synchronisation itself is the misconcept, no matter how smart it might be?

You need a way to synchronize
a) automatically without user interaction
b) reliably and in a way that can be verified
c) fast and over cheap/low traffic lines
d) without mid-air collissions and conflicts if several people (or just me working at home and on my notebook) change different files
e) work with dumb storage like hard disks, USB sticks, online storage without the need to have running instances of Windows and Lightroom

That whole concept of needing a proprietary, user interactive, license bound program depending on a graphical interface and human interaction to just synchronize machines, even worsened by the fact that Lightroom does not allow catalogs on network shares, is broken by design.

Furthermore, it is based on the obsolete idea of fast PCs or Workstations, but today we have a client/server/central storage/distributed work model.

And the more comments I read in this thread, the more I suspect that this is made intentional to increase the number of Lightroom licences customers need.

And for those who want to tell me that this is wrong or would not work: Why does it work so well with Bibble5 then?

I don't see much difference in sending someone "complete" xmp files to read into a foreign catalog versus sending them a catalog fragment to import into a foreign catalog - theoretically it would be the same info in a different wrapper. But some options for what goes out and what comes back in doesn't seem like such a bad idea, in either case...

Hadmut - it does sound like you may not fully appreciate how to use Catalog Export / Import. Its just one file, not a bunch of files and could essentially contain all the changes you'd have made on the road, as example, not a whole catalog, and no photo files... I'm a big proponent of complete xmp for all+virtual, for a variety of reasons, including the ones you've brought up. But it may still be possible for you to accomplish your objectives without too much trouble using catalog export / import. I recommend making sure you do understand how that works before making your final judgement... I mean, I'm not vested either way, and I'm not an Adobe/Lightroom defender, and I don't always see eye-to-eye with John Beardsworth, to make an understatement, but I do think in this case he's brought up some points worthy of a bit more consideration.

In relation to distributed or concurrent working, they sure are!

The same arguments that we covered in that thread apply here - these are areas where if the FR is ever implemented, users need control over each chunk of data that's being saved out. For example, if I sent pictures to another Lightroom user would I always want them to see my collections structure, revealing how I organise my work or other confidential information? And would they want to have my collections appear in their well-organised catalogue? The same would apply to stacking or what virtual copies I've made. So you need write and read options - or be happy with the unintended consequences.

@Hadmut - I'm not using technical terms or jargon, and your reply is really too long to go through countering or agreeing with every single point.

Note, I am not talking about simple Export/Import but specifically used the terms "Export as Catalog" and "Import from Catalog". These don't need to generate additional originals - they can, if wanted, but don't need to.

"I would additionally have to deal with all those exported files and to keep track with them." No, Export as Catalog/Import from Catalog can work without passing extra copies of the file back and forth. The process just needs a slightly more user-friendly appearance / metaphor / name to help people appreciate its elegance.

"Second problem...". Is Win + Mac only really a problem? Not sure what you're on about here, but a database is a huge advantage, not a "severe failure".

"Third problem..." Export/Import is actually a lot smarter than you seem to think! In your example I just do a smart collection based on the edit date, export those items as a catalogue (without the originals), and import that to the master. But there are a few easy ways to do it without playing with sidecars.

I just don't think your concurrent/distributed workflow is a reason for the FR. LR offers better ways to work.

John

Hadmut - You may not be able to convince everyone, but you've convinced me.

Networked Lr with true-sync... - may be a while off, but syncing via xmp would be a short reach.

I'm hoping Adobe will remedy come Lr4, or at least augment the SDK so a plugin author could implement the solution (its "almost" doable now as plugin but would be severely limited due to omissions...)

Is this really a deal breaker for you?

Rule 5.2 - Enjoy other software if Lightroom not quite cutting it...

Rob

@john beardsworth: That's pure nonsense, and it does not get any better by using technical terms not understood by everyone in this forum.

Export/Import do provably not maintain a proper and synchronized data structure. A first problem is, that they generate additional data sets, i.e. the exported files. So besides the heap of pictures I have, I would additionally have to deal with all those exported files and to keep track with them. This will definitely fail (and waste additional disk space I might not have when on the trip).

A second problem is that Lightroom works under Windows and MacOS only. It requires someone to sit in front of the computer and move a mouse, and to have that particular computer with Lightroom installed turned on and someone logged in. This is a nightmare. It does not work with a central repository. E.g. there are lots of free/cheap disk space/backup providers out there, but there is no one providing a free online version of Lightroom. The requirement to have a central database entity operated manually by a human through a graphical interface is a severe failure in design.

A third problem is that this method does not deal with change sets. Imagine that I am at home at my personal network, and do synchronize my heap of 100,000 travel pictures onto my notebook computer. Then I am on a 3 weeks trip with lots of time to spend in trains and airplains, and I do some corrections, b&w conversions, add keywords and so on. How would I export from the database all settings that I have changed and not just all the 100,000 ? And how do I import them into my central database when I am away from home and thus from my central database?

Lightrooms structure of dancing around a central database on a Windows machine that forces users to operate it centrally with a human graphical interface and mouse is based on assumptions that do not hold true.

I've changed the term from concurrent to the more precise special case of distributed, since someone in the comments above reduced "concurrent" to the special case, where all concurrent entities have high-speed low-cost access to a central database. Photography is not centralized work. Not anymore. It used to be in the old days, when we had chemical labs. But today we have notebooks and mobile phones, and we leave our office for taking pictures and communicate with others.

Geeks: Using one of the common tools to keep a directory tree of regular files in sync between computers (or computers and online storage providers) is definitely more simple, comprehensible, fool proof and robust than dealing with an unstructured collection of exports, that require manual interaction and most probably lots of manul corrections and collision solving.

That discussion sounds, btw., somewhat silly, because Lightroom basically already has the required functions, i.e. writing xmp files and reading them in through synchronizing directories with the database. So what's the point of this discussion? Denying that Lightroom already has it? It's just that it is incomplete, inconsistent, not complete, and poorly implemented.

But I think we can stop discussion right here. I think I'd rather stay with Bibble5 instead of turning to Lightroom and felting my work through inconsistent databases. The guys from Bibble Labs have realized, addressed, and solved the problem. The guys from Lightroom don't. Bibble5 solves the problem, Lightroom doesn't. Sorry to say that, but it's really that simple.

Hadmut, FWIW, I don't see you making any straw man arguments at all. I think your proposal makes perfect sense. I suggested something similar a while ago: I believe that XMP files or metadata in DNG files should retain edit histories. Dan Tull was supportive of the general idea and regards complete XMP files as a distributed catalogue backup.

You really are deploying some straw man arguments! And if you want to change the goalposts from concurrent working (the phrase you originally used) to distributed working, Export/Import are equally suitable and provide the level of controllability that's needed. Your Heath Robinson / Rube Goldberg workflow processes may work for geeks and can be made to work by normal users, but they're still ugly and still involve manual processes and knowing which files you're working on. Lightroom should be about doing the right thing.

Hadmut - I know most everybody who cares about the issues you have raised (not everybody does) wants Adobe to solve this problem in a native fashion, including me. But, this could also be solved by plugin - mostly solving the problem of missing data in xmp, and providing xmp sidecars for all file types & virtual copies, and also providing a simple synchronization option to avoid the issues with using catalogs for this purpose, which you have raised. Obviously the plugin solution would be Lightroom-only.

I won't go into details, but suffices to say the plugin-based solution would address most of the issues you've raised, including filling in most of the missing data (some but not all stuff that is not in xmp *is* accessible via plugin), and catalog synchronization - for those willing to use the plugin, that is.

My hopes in order of preference:
-------------------------------------------
1. Adobe addresses this natively.
2. Some other plugin author addresses this.
3. I find time to address this by writing a plugin.

Final thoughts:
===========
For those beginning to worry about a plugin adding data to Adobe-written xmp files, I imagine a separate file would be written to keep it clean, with a different extension.

-R