Photo Organizer

  • Status Unconfirmed
  • Percent Complete
    0%
  • Task Type Feature Request
  • Category Backend / Core → Import
  • Assigned To No-one
  • Operating System All
  • Severity Medium
  • Priority Very Low
  • Reported Version 2.36
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 1
  • Private
Attached to Project: Photo Organizer
Opened by eirik - 2008-10-26

FS#397 - Import of metadata from programs like Raw Therapee

Some programs like Raw Therapee creates a file to store all metadata to convert a raw file to a jpg file. To repeat the convert process (with or without slightly differences) it would be nice if I'm able to store such metadata with variants at the side of the original picture.

From other programs that storing data in a database, it would be possible to read out the data from the DB and storing metadata into xml-files and backwards.

Admin
pizza commented on 2008-10-26 22:27

Currently PO supports importing XMP sidecar files, but there's no inherent reason why additional file types couldn't be treated the same way.

Does Raw Therapee have a batch/cmdline import mode?

eirik commented on 2008-10-27 11:35

Sadly no. But the filenames are similar to the names of the picture, only with another extension in the same directory. My idea is, if I have i raw file like DSC_2303.nef PO should load automagically a file like DSC_2303.rt from the same directory, if this is configured. The configuration data should be:

1) extension of the metadatafiles
2) should metadatafiles automagically uploaded (y/n)

It would be nice, if I could store different versions of these files with a description.

The reason for the future request is my workflow:

1) Getting the pictures on harddisk
2) Storing the good ones into PO
3) Getting out some pics from PO
4) Converting them to JPG or TIFF

But instead of putting various JPGs back into PO, I want to store these metadata files.

Admin
pizza commented on 2010-08-06 02:58

this might work now, due to some of the changes I've made in the import code.. Hmm. or I can genericize the sidecar support.

... if anyone still cares, that is. It's been nearly two years since you filed this. :)

Hi, i'm new here, but i would be very interested in the feature to be able to import (or better yet) recognize sidecar files.

I am RAW developing with Bibble5 and it's XMP sidecar files could be used for keywords and hierarchies and also thumbnail generation. Bibble can be called via CLI (i'm on Linux, don't know about other platforms). I am talking about RAW files (nikon nef in my case), not just jpegs.

I am also willing to test things if that helps you.

Admin
pizza commented on 2011-01-14 19:33

Bibble spits out XMP sidecar files, that's good! But I'm guessing that I'd need to use bibble to recreate the processing settings specified in the sidecar, and it looks like bibble still doesn't support a cmdline "process this image" mode.

Supporting uploading sidecar files as "versions" is a good next step in any case.

I commented in another post also. But, bibble does seem to respond to commands, the Digikam team has found a way to do it. Bibble also describes it in their documentation on the web. I am pretty sure it even allows for multiple images to be "sent" to bibble in one command (like a batch queue).

Wrt the versioning, i would like to see an implementation where it isn't necessary to develop the RAW file to get the version. Only the description should be enough. Of course, thumb and preview would have to be rendered.

In case you don't want to call bibble for this, or any other external renderer, allow the user to map specific settings from XMP file onto dcraw or ufraw CLI parameters. So, at least the preveiw and thumb show the main differences in versions (like B&W, different crop or excessive contrast curve, etc.). All of this, should be configurable by user.

Again, i am very willing to share ideas about this kind of workflow enhancements.

By the way, to add to my above text, this is not only about Bibble, obviously.

Also Adobe Bridge/Raw and other commercial RAW developers will be able to use this, as well as some open source RAW developers like Darktable, Photivo, as well as RawTherapee and UFRaw.

In workflow perspective, it is crucial that PO both reads from and writes to the sidecar file. Example workflow: Load RAW images in PO, meta data ingestion (EXIF, IPTC, XMP), do initial keywording in PO, perform initial selection in PO, PO writes updates to sidecar file, check out selected images from PO and send them to preferred RAW developer, RAW developer reads sidecar and uses this data (keywords), add keywords in RAW developer, perform processing of images, RAW developer writes changes into sidecar (both additional keywords and processing parameters), check images back into PO, PO absorbs all changes to side car (both keywords and (basic) processing parameters), PO updates thumbs and previews (if necessary), do further keyword fine tuning/adding.

Special case is the way versions are handled, because then there will not be a new image file, only another sidecar file linking to the same source image file (this is at least how Bibble5 handles it).

This way, PO can focus on being a real photo organizer and let the RAW development burden be handled by dedicated RAW developers. And vice versa, of course :-)

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing