On Fri, Dec 21, 2012 at 8:00 PM, Tobias Ellinghaus <[email protected]> wrote: > Am Freitag, 21. Dezember 2012, 15:07:36 schrub Pascal de Bruijn: >> Hi, > > Hi. > >> It seems that we are currently moving our XMP data verbatim into >> exported files, even thought most of the data in that XMP has no added >> value for exported files. > > We do that on purpose so you know what you did to get the result (you could > probably even recreate the xmp sidecar from the data attached).
But what's the value of including that in the JPEG? You're keeping the XMPs with the RAWs. And if you nolonger have the RAW the XMP is useless anyhow. More to the point, our blob encoding makes most of the data poor learning tool anyhow :( >> It would make sense to clean this up to some extent. And I've been >> doing an attempt at this, and my code does compile, however it doesn't >> seem to be having any effect. > > I haven't looked at your patch, but the clean way would be to handle this > together with #8421 [0]. I'm not so sure. That's a ticket for either a simple system to exclude everything, or a complex GUI to let the user decide everything in detail. I'm mostly looking to have Darktable behave a bit more sane by default. Regards, Pascal de Bruijn ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ darktable-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/darktable-devel
