On 07/18/2013 11:55 AM, Tobias Ellinghaus wrote: Hi!
>> In all fairness to the dt developers, users, note that the metadata and >> tagging issues are currently listed in the Developer's Wiki as 'Features >> under consideration' in the section 'Versions and Roadmap'. The question >> is whether there is any interaction possible between users and >> developers that can at this stage help so that these features become a >> reality. > > I have been reading the discussions about metadata > handling for some time now. Since you finally moved it to > the developers list I feel that the time has come to start > getting some input from you. > > Currently dt has only a hand full of fields that mostly > come from dublin core. However, we mix the semantics up > somehow and treat them like XMP fields, it's all quite > messy. I think it is fine that you embed dc fields in xmp. That's how it is supposed to work. However, the xmp block can contain additional namespaces as well. > So the first question that needs to be sorted out is "is > supporting IPTC enough?" or do we also need all the exif > and XMP fields? I think exif for the techical metadata is quite out of the question. Surely you don't want to drop that. Now for IPTC and XMP, I think there might be some confusion of wording here. There is the IPTC definition like the embedded fields in JPG (aka IIM) and there is the "IPTC Core & Extensions" also named "IPTC Photo metadata standard". The latter is expressed within the XMP block and has defined mappings from the former. While IIM is well, by defined fields. If you check out http://www.iptc.org/goto?help-cs5panels this mapping between those two is expressed in Appendix 2 (p.32ff) where you can find the legacy IPTC (IIM) fields and there equivalents in the IPTC Core (written to the XMP block) and also some other well known commercial schemes. E.g. Title (IIM) == Title (IPTC Core) == expressed as dc:title and you'll find some tag names used in commercial software as well. Note that this document also contains a bunch of samples as well as the default dialogues used in some other software. Similarly, in the specification http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata-201007_1.pdf p.28 you can also see that the usage of DC-elements in the xmp block as such is not only fine but as designed. (This is where I took the above dc:title mapping from.) > And if we decide that IPTC is all we need, are there > standardized translations to/from exif and xmp? For exif you're thinking about artist, description, copyright? Just cause in the exif domain you've mainly technical metadata like focal lenght, geo tagging, iso and what not so I think the exif part is "mappable, but mostly uninteresting" in the sense of subject indexing, and it is mainly passed on as is. I think for copyright, description and artist one could go with a mapping to/from IPTC. At first glance all other fields should not be editable. For XMP <-> IPTC I think for the best thing for interoperability would be to write the IPTC Core blocks to the XMP in proper namespaces and keep it in sync with the legacy fields of IIM as defined in the documents mentioned above. > Because, if we get fed an image (or sidecar file) that > contains relevant information in those metadata sets, we > surely want to keep them. Right. Probably, one will get some namespace one can't handle and should pass it on until a mapping is available. > The alternative would be to support all possible data > sets, however, that would mean that we > > 1) have to decide what to do when the user changes the > "Author" value in exif. Shall it be changed for IPTC, > too? IMHO(!) keeping that in sync by mappings is indeed the way to go to get consistent metadata. It also limits the number of fields in a nice way. > 2) have to find a way to not make the GUI too cluttered > and ugly, A reason why I think "less is more". Even from a usability point of view. exif.author iim.by-line iptc.creator all expressing the same carbon based life form and you don't want to have to enter it three times. > I personally would favour limiting ourselves to IPTC in > the GUI and when finding some other data sets while > reading the image we should translate these to IPTC. IMHO this is would be the way to go. If the target it the largest namespace (I think this is IPTC Photo metadata standard) the smaller ones can be mapped to that, probably leaving some holes for the user to fill in. > The next step after deciding what we actually need is to > find a suitable way to store that in the database and > sidecar file (some of these are trivial decisions, I just > wanted to write them down once). > > TL;DR: > [0] alone will probably not be enough, but what about also > supporting [1]? Is our current set completely supported by > that? I think I don't quite get your point, but if I get it right a lot of that is solved if the storage value is not a literal, but a key for an (external) controled vocabulary. This gives you another abstraction layer and a lot of flexibilty. If there is a speed issue one could think about a copy of the literal for "caching". > PS: You might have noticed that I don't intend to add all > the technical exif data to the list of editable things in > the GUI. I think it is sensible that focal lenght can't be edited. ;) > If someone intends to change the aperture, well, > go ahead, but not from inside dt.<-- Comments welcome ;) Perfectly agree. > [0] http://www.exiv2.org/tags-xmp-iptc.html > [1] http://www.exiv2.org/tags-xmp-iptcExt.html Note that these refer to 2008 definition. The docs given above would be the 2010 update. -- Kind regards, / War is Peace. | Freedom is Slavery. Alexander Wagner | Ignorance is Strength. | | Theory : G. Orwell, "1984" / In practice: USA, since 2001 ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Darktable-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/darktable-users
