Historically I've captured and stored most images with parallel JPEG + NEF
RAW files. I've come to realize that keeping both JPEG + NEF files in parallel is essentially pointless, since I can easily extract the embedded JPEG preview from the NEF, or run a raw convertor on it to get a full resolution JPEG. So I'm intending to switch to an exclusively NEF based workflow and likely will remove all the JPEGs I've already got to just leave the original NEFs. The only problem is that when managing in digikam I've assigned tags and star ratings against the JPEG file only though, since it was tedious to do the same work against the NEF file too, and in the past I've mostly worked with the JPEGs only processing the NEFs occassionally. So I need to figure out a way to batch update digikam's database so that all the information I've recorded against the JPEG is copied to the RAWs. I've tried doing this by going via XMP sidecars. eg 1. Tools -> Maintainence -> Sync database to metadata 2. Use script to copy xmp:Rating from JPEG XMP file to the NEF XMP file 3. Tools -> Maintainence -> Sync metadata to database This seems to work, but digikam sure is slow at writing the XMP and also at loading them back in later. It'll take it a real long time to do this for all the images in my collection. Are there any other more effective ways to sync the metadata from JPEGs to the correspondingly named NEFs across the entire collection ? I have thought about perhaps writing a script to munge the mysql database directly, but that has high risk of calamity :-) Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
I did something like that years ago with a pascal database. If you make a
backup copy of your database first, then an accidental munge would not matter, and it could be a reasonably easy way of doing the job. Gordon. On 04/26/2014 11:40 AM, Daniel P. Berrange wrote: > I have > thought about perhaps writing a script to munge the mysql database > directly, but that has high risk of calamity:-) _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Bugzilla from dan@berrange.com
Le Sat, 26 Apr 2014 01:40:43 +0200, Daniel P. Berrange <[hidden email]>
a écrit: > > I've tried doing this by going via XMP sidecars. eg > > 1. Tools -> Maintainence -> Sync database to metadata > 2. Use script to copy xmp:Rating from JPEG XMP file to the NEF XMP file > 3. Tools -> Maintainence -> Sync metadata to database > > This seems to work, but digikam sure is slow at writing the XMP and also > at loading them back in later. It'll take it a real long time to do this > for all the images in my collection. > > Are there any other more effective ways to sync the metadata from JPEGs > to the correspondingly named NEFs across the entire collection ? I have > thought about perhaps writing a script to munge the mysql database > directly, but that has high risk of calamity :-) > > Regards, > Daniel Hi, What do you mean by "Slow to write XMP" ? For using NEF only and at the beginning, when XMP didn't exist yet, I'm used to write metadata in the RAW file, and I can say it takes still more time than writing XMP. What you have to keep in mind, is it take a long time the first time you do this, but after that, when RAW files get their XMP sync with Digikam Database, it should be almost like before when you use JPEG for metadata. Regards, Nicolas -- Utilisant le logiciel de courrier d'Opera : http://www.opera.com/mail/ _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
On Sat, Apr 26, 2014 at 09:11:49AM +0200, Photonoxx wrote:
> Le Sat, 26 Apr 2014 01:40:43 +0200, Daniel P. Berrange > <[hidden email]> a écrit: > > > > >I've tried doing this by going via XMP sidecars. eg > > > > 1. Tools -> Maintainence -> Sync database to metadata > > 2. Use script to copy xmp:Rating from JPEG XMP file to the NEF XMP file > > 3. Tools -> Maintainence -> Sync metadata to database > > > >This seems to work, but digikam sure is slow at writing the XMP and also > >at loading them back in later. It'll take it a real long time to do this > >for all the images in my collection. > > > >Are there any other more effective ways to sync the metadata from JPEGs > >to the correspondingly named NEFs across the entire collection ? I have > >thought about perhaps writing a script to munge the mysql database > >directly, but that has high risk of calamity :-) > > > > What do you mean by "Slow to write XMP" ? For using NEF only and at > the beginning, when XMP didn't exist yet, I'm used to write metadata > in the RAW file, and I can say it takes still more time than writing > XMP. I mean that the 'Tools -> Maintainence -> Sync database to metadata' task and the reverse, take a long time - judging by the speed todo it for one small album, it is going to take many hours to do it across the entire collection. > What you have to keep in mind, is it take a long time the first time > you do this, but after that, when RAW files get their XMP sync with > Digikam Database, it should be almost like before when you use JPEG > for metadata. Yep, understood - I'm just wondering if there was a way to do the conversion step a bit quicker :-) Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Free forum by Nabble | Edit this page |