Moin, yesterday I hit a problem due to moving from digikam to darktable. First I have to note that using tags in digikam introduces a problem using raw files. Digikam doesn't maintain metadata as files by default, nor in file for raw files, so all tags and such is held only in digikam db for raws. I noticed this as dt has imported my tags for existing jpg files. Now I have changed this setting in digikam and ordered a full refwrite of metadata in digikam, which sadly rewrites the full xmp sidecard, kicking out darktables informations. Now in darktable you have to remove the files from collection to get the xmp-data reread, doing so will dispose the history stacks, which should normally be preserved in the xmp files, but those have been cleaned by digikam :(
Now triggering a metadata write in dt will overwrite the lr tags namespace, so the tags are erased before they could be imported. This was discussed yesterday in dt irc, bringing up the demand for improved xmp file handling. First dt has to notice third party changes of on disk stored metadata. Therefore it was proposed to store the last modification timestamp and a hash of the xmp file / xmp data along the other information in dts db, to allow quick detection of foreign changes of on disk information. Giving the second problem of information handling. If a file was changed, darktable should check if its used namespaces are still present, consistent and matching the in db information. Normally if they all three is true the hash shouldn't have changed, so in this case just the timestamp has to be updated, if for some reason the hash has changed (maybe information in unknown namespaces were changed) the hash has to be updated also. If namespaces are missing darktable should assume a ugly overwrite of the file, so it should evaluate the currently existing known namespaces and check/update the in db data, then it should fill back the missing information from the db. If all used/known namespaces are present, but inconsistent darktable could assume that a tool updated the file knowing / using another, partially overlapping, set of namespaces, so the unmatching information should be considered more up-to-date. (maybe it could desirable to make this behavior somehow configurable to give darktable precedence, display a merge dialog or something like that) At the end darktable should have restored consistence between the in file used/known namespaces and the database. Last question is how much a timestamp check takes, is it feasible to do it everytime image metadata is displayed (hovering/selecting in lighttable mode), doing it only on request (when reimporting a directory or using a button in lighttable mode) or before writing the file (introduces trouble with concurrent changes)? I wold prefer more frequent checking as it prevents concurrent modification troubles. Btw, implementing this would also allow using multiple darktable instances to operate on the same files, as long as there are no concurrent edits, but this should be left to the users to handle by soft human interaction protocols so far. I would suspect normally only one person works on a roll at the same time. Regards, Florian ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 _______________________________________________ darktable-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/darktable-devel
