Am Mittwoch, 4. Dezember 2013, 10:24:47 schrieb Giacomo Catenazzi: > On Tue, Dec 3, 2013 at 12:29 PM, Tobias Ellinghaus <h...@gmx.de> wrote: > > Am Dienstag, 3. Dezember 2013, 10:12:49 schrieb Giacomo Catenazzi: > > > (geotagging in dt still sucks; OTOH many other things sucks much more, > > > in the other programs) > > > > Bug reports and feature requests are welcome. > > I don't want to break the pace of development. geotagging is relatively > new, and still in improvement, so let wait a mature stage before to bug.
I don't think anyone is having plans for improvements in that part. So either tell us or it will stay as it is. > > > So I'm thinking if I should implement a new library to better handle xmp > > > and also that optionally it convert at best the data from a program to > > > an > > > other. > > > > And what is that library supposed to do? XMP is just standard XML and well > > understood. If programs are not adhering to standards its a bug and > > nothing > > some external libraries should try to fix. > > and XML are just plain text files. But I think a XMP library should be high > level respect XML (hiding some details). If you look at xmp parsing in dt, > you see that there is no clean interface (and it seems based/copied from an > example of exiv IIRC). Where did you get that from? Both exiv2 and darktable use the same library (which happens to be libexiv2) to handle that stuff, that's all. And that library abstracts the XML structure away completely. > Additionally dt now read the tree and write the > entire tree (in a less readable form), moving around all stuffs. Also if I > imported an image without display it (no also no attempt to retouch the > image), dt will rewrite the xmp. That's perfectly acceptable behaviour. XMP files may be reordered. That's why there are tags that explicitly specify things to stay in sequence. > So I think a XMP library (which know > better the structure of a XMP than a plain XML) should also try to insert > and delete lines, not to rewrite all file. So you want to add much more complexity and a higher possibility for bugs just to keep the edit distance between the XMP files low? Well, everyone should have a hobby, so go ahead. :) > And possibly the library could > contain some more high level translation (not for dt), but e.g. to simplify > to create short script to do statistics, handling, etc. libexiv2 is also quite high level, but doing statistics sounds like it could be nice. No idea if a new parser is needed for that, too. > I think that I I reach to write the library, dt could profit improving (and > hiding) the details of xmp handling, darktable will not use it. libexiv2 is fine, wide spread, and offers so much more that I doubt you/your library could compete. > but also many small external tools > could be implemented easilier. OTOH it is not so essential to dt. > > [BTW I';m stuck in reading the various standards (XMP, IPTC, etc., and to > find a good XML library that could also handle malicious xml code ] The standards are quite good, but finding an XML parser that doesn't touch anything without your permission will probably require to write it yourself or go quite low level. To a level that almost works on the text file. ;) > > > Many users will not switch program, in order not to lose years of > > > retouching of old photos. > > > > There will always be some kind of lock-in. > > For sure. let reduce the lock-in I don't see how changing the XMP parser helps with that. > ciao > cate Tobias
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
_______________________________________________ Darktable-users mailing list Darktable-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/darktable-users
