Photo Organizer

Notice: Undefined index: tasklist_type in /var/www/flyspray/includes/class.tpl.php(128) : eval()'d code on line 85 Notice: Undefined index: tasklist_type in /var/www/flyspray/includes/class.tpl.php(128) : eval()'d code on line 90
  • Status Unconfirmed
  • Percent Complete
    0%
  • Task Type Feature Request
  • Category Backend / Core → Import
  • Assigned To No-one
  • Operating System All
  • Severity Medium
  • Priority Normal
  • Reported Version 2.36
  • Due in Version Undecided
  • Due Date Undecided
Attached to Project: Photo Organizer
Opened by Eirik Pettersen (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.

This task does not depend on any other tasks.

Solomon Peachy (pizza)
Sunday, 26 October 2008, 22:27 GMT
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 Pettersen (eirik)
Monday, 27 October 2008, 11:35 GMT
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.

Solomon Peachy (pizza)
Friday, 06 August 2010, 02:58 GMT
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. :)
Hans Cremers (hcremers)
Friday, 14 January 2011, 09:21 GMT
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.
Solomon Peachy (pizza)
Friday, 14 January 2011, 19:33 GMT
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.

Hans Cremers (hcremers)
Sunday, 16 January 2011, 11:22 GMT
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.
Hans Cremers (hcremers)
Monday, 17 January 2011, 15:19 GMT
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...