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

In case this point hasn't sufficiently landed:

Many of us would *really* like an xmp sidecar option for all file-types, as well as virtual copies.

...the completer the better...

The way you describe it, it does not sound as if the database was Lightroom's great strength, but the dependency of a central database it's major weakness.

Exporting a Catalog does not work that way because it implies that the one working on the database knows exactly which pictures are to be exported.

E.g. I can easily synchronize a part of the tree from my server onto my notebook when I am at home, can then be on the road and do some changes, and then do a fast sync of the changed XMP files over UMTS. e.g. use the time for working when sitting in the train or at the airport.

Argueing that my mentioning would not be right does not make sense, because that's how I am working right now with Bibble5. Perfectly fulfills my needs.

Therefore, it would not be much of a problem to transmit the larger originals in the first place. It's about not having to transmit them again once done with the work.

It is also not about concurrent working (which can basically be done with a central database), it is about distributed working (which requires better synchronization methods than a central database or import/export of whole databases) and data exchange.

Just have an example:

Let's have a database with pictures A,B,C,D. And two workers with notebooks on the road. (Or myself with two distinct notebooks.) One changes A and B, the other works on C and D.

With import/export you get an extreme mess of files and versions. With those sidecar files and a regular file synchroniser you solve the problem fast and easy. And you solve it automatically, without having to manually (!) import and export files.

The database is Lightroom's great strength. When a network isn't available, offline workflows are addressed by File > Export as Catalog and Import from Catalog which does things like replicate file structures and has intelligent ways of roundtripping work.

Your mentioning of sidecars for emailing isn't right on three counts. You could send a catalogue just as easily, fortunately not all file types have sidecars - eg DNG, TIF, JPEG, - and thirdly you'd have to transmit the much larger originals in the first place.

So while I agree with your basic request, concurrent working isn't a justification for it.

First of all, having all relevant data in the XMP file is what gives the XMP file it's sense.

In contrast, having multi-user network access to the database does not always make sense. You're assuming that there is a high speed and low cost local network, which is not always the case.

It must be possible e.g. to take a notebook computer with a copy of the file system tree with pictures (or part of it) onto a trip, maybe in foreign countries without mobile coverage, and to work on pictures.

Then, it should be enough to synchronize just the xmp files (oder send them by email) over expensive or low bandwidth lines.

It should also be possible to send some pictures together with all settings to other people (e.g. by email) without having to completely export and import a Lightroom catalog. Or letting other people do the work of image processing and adding keywords and other stuff, and just send/sync back the xmp files.

This boils down to the central problem, that Lightroom is based on the assumption of one central database, that's always online and available. This hold's true for people sitting in agencies, but not for people travelling around (or preferring other operating systems) or participating in distributed working structures (e.g. freelancer).

Writing more metadata back to the XMP is desirable, and I'd also add custom fields' metadata. However, I wouldn't justify the request on the basis of concurrent working over a network. Rather than a file system kludge, better to have multi-user network access to the database.

Yes, I'd like to see metadata about collections and stacks (and their order) stored in the xmp files.

Whether this is a bug report or a wishlist depends on the point of view, i.e. the formal specs of the xmp file (if there is a precise specification).

If the xmp file is intended to contain _all_ information about an picture file, including all work, then this is a bug.

If the xmp file is supposed to contain only some parts of it (why?), then this is a wish.

The reason I am asking: I am currently (still) preferring Bibble5 over Lightroom, because Bibble5 runs under Linux as well and has several functions missing in Lightroom. On the other hand, Lightroom seems to produce more reliable results and to have a more complete workflow. I do consider changing to Lightroom (have a license).

A major problem of lightroom seems to be that it is based on a central database that cannot be stored on a network share. This makes it impossible to concurrently work on a large collection of pictures due to the synchronisation problem. Bibble5 solves this problem by having a so called „File System Mode”, where just everything is stored in xmp files, so you just need to synchronize file systems with tools like rsync or unison, which perfectly allows to work simultaneosly on the same collection of pictures as long as not on the same pictures.

I tested whether it is possible to do the same in Lightroom by writing out the xmp files after work and synchronizing before. Unfortunately Lightroom's xmp files are somewhat incomplete.

Another point is that complete xmp files allow to read (and change) all settings e.g. from scripts or other programs from any copy of the file system tree.

It's a feature of Bibble5 that I miss on Lightroom and which currently keeps me from changing.

Collections, stacks, VCs, flags and Develop history do not appear in the XMP data. There are application interoperability reasons for this, but I think they should work through as much of this as possible.

Is this a problem or are you requesting additional functionality? It sounds like you'd like metadata about collections/stacks stored with the file.