Hi Jim, Thanks for the reply. See responses below
On Tue, May 14, 2013 at 2:44 PM, Jim Nelson <[email protected]> wrote: > We have thought about this, although we've not gone into great detail > about it on the wiki. XMP would be the right way to do this, as it allows > for user extensions. It would be *best* if there was a standard way to > save transformations, but one doesn't appear to exist yet and so it would > probably be up to the various projects to come together and agree on a > format. Agree on the merits of XMP. Adobe has the camera raw schema that could be a starting point: http://www.exiv2.org/tags-xmp-crs.html (Notice that the uri for the schema http://ns.adobe.com/camera-raw-settings/1.0/ is a dead link -- do these things ever go to a live page?) I'm not sure when these are generated, maybe when processed by Adobe's raw processor? In any case, I don't think it would be a good idea to write to those "crs" tags, but one could perhaps use them as a jumping off point for defining a new namespace. One thing I am not sure about is whether it would be better to just define a single tag array-type transform (or a string of xml), say "Xmp.namespace.ImageTransforms" that contains all of the transforms that must be performed (in sequence) instead of a key for each tansform. The problem with defining a key for each transform (or multiple keys for each transform in the case of adobe crs) is that it implies those transforms can either be performed in any order or that there is a canonical ordering. There's also the issue of how to handle multiple transforms (e.g. multiple red eye reductions) vs transforms that should be singletons (e.g. probably only makes sense to have one crop per image). One essential tag to include would be the version of software that generated these keys, which might be helpful when trying to recreate transforms that are idiosyncratic to particular software. > > Note that some users may want the metadata written to the original file > and not a sidecar. Sidecars also introduce the problem of conflicting > metadata -- when fields are present in both the original and the sidecar, > which has priority? (Probably the sidecar, or the mtime of both files > could be compared.) > In my own program, I currently use sidecars as a fallback for whatever exiv2 can't write to. The approach I have taken is that everything the user does to the image is written to the image or a sidecar (i.e. the database can be fully reproduced from the directory of images). Re conflicts -- in my current approach, if the sidecar exists it is given priority over the image metadata (but one could also imagine checking which file is newer and doing something more sophisticated.) In general, Adobe's spec for handling metadata conflicts is very complicated. > > I do think the bulk of transformations could be described in a > near-universal way. Color transformations may be the most difficult, since > the inputs are reliant on the algorithms, which may be different from > application to application. But things like crop and straighten could be > described in straightforward terms. > Agree > > So, yes, this is something we've thought a lot about. If there was some > momentum to begin something like a standardization process, I know we would > definitely like to be a part of that conversation. > Good to know. I might bring this up with the gthumb, DigiKam and DarkTable guys. If the major open source projects could agree on something, that would be a great start. I wonder if this is a spec that freedesktop.orgwould be interested in? Cheers, Damien _______________________________________________ Shotwell mailing list [email protected] http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
