On jeudi 16 mai 2019 04:37:20 CEST William Ferguson wrote: > On Wed, May 15, 2019 at 5:50 PM <[email protected]> wrote: > > William Ferguson (2019-May-15, excerpt): > > > Without knowing more specifics about what you're trying to do, > > > that's the best I can come up with at the moment. > > > > I'm trying to figure out how difficult it would be to satisfy Kneops' > > request about editing more metadata fields, following the KISS > > > > principle as I had suggested: > > * Use Lua only to describe a GUI module in DT's lightroom (enter > > > > metadata into fields) and to hand the slected images and desired > > task off to any other program. > > > > * Use `exiv2` to modify the metadata in the XMP file(s) of selected > > > > image(s). Or `exiftool`, or whatever. > > > > * Make DT read the XMP file(s) and update its database. > > This is the problem. Darktable doesn't know what to do with the extra > metadata in the xmp, so all it's going to do is ignore the extra metadata > (best case), or ignore the xmp because it thinks it's corrupted (worst > case).. In order for darktable to use it, someone is going to have to add > all the database tables and supporting code to store, retrieve, and use the > information. Then the exporter needs modified to embed the additional data > in the exported file. > Not necessarily.
As the sidecars used by dt are in XML format, dt should ignore unknown elements (provided the XML is valid) on reading the sidecar. Ideally, unknown elements should be passed through to any derived file (exported images *and* duplicates, which copy the sidecar). As long as that happens, and we can live with not being able to search on those unknown fields, or inspect/edit them, that's all that is needed. So, the flow as described above should work. This has another advantage, in that any metadata element can be added to the metadata, without needing to update dt whenever someone needs a new field. Note that rejecting an otherwise valid XMP file just because it contains unknown elements is not only non-conforming behaviour, it also requires extra work with most XML parsers. > I just did a quick look at the IPTC tags. Some of the records are fixed > format with certain data in specified columns. Some records are use codes > to mean different things. Each of the coded fields would require a table > in the database for lookup, plus tables to contain the records. This isn't > trivial to implement. It's probably not too difficult, but it's a lot of > work. And not needed if dt passes through unknown XMP elements without presenting them in the GUI. For me, the problem in this thread has two parts: 1 - someone needs some extra metadata on his/her images, that should be conserved by darktable; 2 - ideally those extra tags should be understood by and editable through dt. Item 1 looks to me to be essential. It also doesn't need dt to understand those extra metadata, dt just has to transmit a few extra XML elements as black boxes. Item 2 is the one that would case the most work, and require the most maintenance (in that values allowed for those fields can change, and extra fields will be requested). ____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to [email protected]
