I've been looking at the metadata handling of RawStudio, and I've some
thoughts that I'd like to send out an RFC for, with regards to two
things: the internal storage of the metadata, and the external saving
of it.
Long-winded email alert!
--
Internally, while RawStudio is running, we've got internal
representation of the metadata in at least three places:
* The iconviews held by RSStore (actually, the GtkTreeViews of the
iconviews) hold some of it in various columns, e.g. PRIORITY_COLUMN
for the image priority for sorting purposes.
* RSMetadata holds a large chunk per-image, in a pre-parsed format,
for things like timestamping, focal lengths, etc.
* RSLibrary holds an sqlite-backed view of user-assigned tags
associated with each image.
I'd like to reorganize this and put it all in one place.
* The iconviews already hold RSMetadata in a METADATA_COLUMN; I'd like
to move the other metadata bits into the RSMetadata and drop their
columns from the icon view.
* Per-image user tags should also live inside RSMetadata, and they
should be extended: instead of just a set of tags, they would be a set
of key-value pairs. Keys created with a null value would be the
equivalent for the current tag model.
* Allowing key-value pairs would also allow the RSMetadata to also
present its other metadata (focal length, aperture, etc.) in the same
key-value namespace -- this allows us to operate on and search through
"standard" image metadata in the same way as the "custom" user tags.
* RSLibrary's sqlite backing should be expanded to back not just user
tag lists, but to back the entire RSMetadata chunk. (More on this in
the backing store discussion later.) RSLibrary would be responsible
for returning multi-image results for searches over tags (as it is
now) as well as other metadata searches (e.g. "all photos with
priority 1", "all photos with lens X").
My motivation for reorganizing this is to enable a user-interface
change further down the line. Our current thumbnail organization is
fixed with the "U", "3", "2", "1", "D" panes. I'd like to generalize
this such that the user can define custom panes with custom filtering
criteria; the current set would just be a trivial specialization of
this; i.e. allow the user to create custom panes, drag them around and
reorder them, etc. Unifying the metadata backend would allow the user
to create filtering criteria over all the metadata available. I think
this would have the benefit of allowing further flexibility, with no
workflow change forced on people who are used to the present system --
we'll just define the "U" "3" "2" "1" "D" panes as defaults, and
people who don't want to deal with more than that don't have to. This
would also have the benefit of allowing the removal of the somewhat
confusing "Tag Search" field from the right-side edit box, where its
connection with the thumbnail panes up top is a little less than
obvious. (At least it was for me, trying to figure it out.)
--
There's also the issue of the backing store of the metadata, i.e. what
happens when we hit "save". A few places we have metadata saved:
* If we export an image, we'll try to stuff the metadata into EXIF or whatever.
* We cache metadata in ${PWD}/.rawstudio/${NAME}.metacache.xml
* We save the image-editing options in ${PWD}/.rawstudio/${NAME}.cache.xml
* We've got the sqlite backing store for user-assigned tags.
There's a few principles I'd like to follow with regards to the
metadata saving. They are:
* The original source image should never be modified.
* There should be one authoritative copy of saved metadata -- caches
made for efficiency purposes should defer to, and update from, this.
With that in mind:
* Metadata should be read from the source image, if no XMP sidecar file exists.
* Metadata should be written to an XMP sidecar when the source image
is saved -- this include image-editing options associated with
RawStudio.
* When an image is exported, metadata is exported into the image, if
embedding is allowed, otherwise optionally into an XMP sidecar saved
with the exported image.
* The sqlite backing store is used just as an LRU cache for speeding
up commonly-used files. The authoritative backing store for metadata
is still the images, or the XMP sidecar files.
Future feature to think about: DNG file import/export, with XMP
embedded into the file. In this case, we'll modify the rules
slightly:
* When exporting DNG, we'll export with RawStudio-specific XMP info
embedded into it.
* When opening a DNG source file, if it has RawStudio-specific XMP
info, then the DNG file itself will be updated when we update the
metadata. Otherwise, it's treated as an external DNG and is not
modified -- the XMP sidecar is used.
DNG support is, of course, a future thing.
--
I've been familiarizing myself with the codebase, so I'd like to get
some feedback before I start anything that might annoy people.
Commentary please!
Thanks,
-John Sheu
_______________________________________________
Rawstudio-dev mailing list
[email protected]
http://rawstudio.org/cgi-bin/mailman/listinfo/rawstudio-dev
