Photo Organizer

  • Status New
  • Percent Complete
    0%
  • Task Type Feature Request
  • Category Backend / Core
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version 2.33
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Photo Organizer
Opened by pizza - 2007-08-13

FS#244 - Allow for custom rendering paths

Right now, it's:

thumb = raw -> scale -> colorspace (+extras) -> sharpen
prev = raw-> scale -> colorspace (+extras) -> sharpen -> watermark

IT would be REALLY nice if we could create customized processing paths; that is to say:

type_1 = raw -> scale -> b&w -> normalize -> sharpen
type_2 = raw -> scale -> add_border, add_text -> sharpen

This could either be on-demand, or automatic on uploads.

I support this request, but would like to take it a step further.

Why not allow for totally external renderers? Like any ohter raw converter that can be called from command line.

On top of that:
- respecting XMP side car files (or even other side car files, like RawTherapee .rt, etc.) with key words and settings.
- respecting renderer created versions (so, not created in PO), for example in separate XMP side car.
- creating separate version side car for PO created versions, to be recognizable by external renderer.
- allowing user mapping of elements into side car file (especially valid for XMP).
- allowing user mapping of side car values to other renderer instructions. Example: Bibble created version --> map certain rendering values (like B&W) to command line instructions for dcraw.
- allowing external renderer to generate thumbnails and previews, based on rederer's settings (the side car files).
- refreshing the thumbnails and previews when renderer's settings change (i.e. values in side car change).

All of this obviously user configurable.

Of course, i am willing to elaborate further on this.

I hadn't noticed that XMP sidecar support should be there already. The documentation doesn't seem to mention it.

It seems from item #292 that the current support is for keywords/tags only.

i would like to see an option to map the XMP file to PO fields and vice versa. Meaning, that if i were to use an application that adds to the Adobe XMP spec, i could make use of that and when i change/update data in PO, it could be written back to that file in a proper way.

Same goes for processing parameters found in the XMP side car.

Admin
pizza commented on 2011-01-14 18:59

PO reads quite a few of the XMP/RDF fields in, but nothing relating to image processing, and using sidecars versus embedding it into the image shouldn't matter. (if it does, it's a bug!) But adding the ability to update/export XMP sidecars would be really nice. PO's current export format utilizes its own XML DTD and doesn't include all the data that PO tracks.

But back to the custom rendering path. The scenarios you describe are perfectly reasonable, and it would be nice to support that. PO's internal processing pipeline is already fairly flexible, and we can add options to our heart's content, but the difficulty is presenting an UI to manage all of that.

(Oh, the last time I messed with RawTherapee and Bibble, there didn't seem to be any meaningful command line support)

The way XMP sidecars are implemented kinda sucks, and it's not terribly extensible (eg to rawtherapee's sidecar files) or flexible (ie using different sidecar files as different photo "versions" with the original RAW as the "master") -- But it seemed like a good idea at the time.

Actually, I'd like to revisit PO's entire notion of "versions"..

Hi Solomon, thanks for replying to fast.

Valid remarks, but at least Bibble has the option to be called from CLI, at least on Linux. The Digikam team seems to have found a way to do it (i believe you can call via a straight command, or with the use of a "batch" text file).

On the topic of XMP sidecar files. Even though i don't know much about that, it seems to have become some sort of industry standard dor describing image files in order to be non-destructive. The Bibble team (i am not a fanboy, but i am using it) thought the Adobe implementation was rather limited as well, so they 'extended' it for bibble use in bibble V5.

But, supporting side car files should be open enough for the user to define what maps to PO and back, without you doing all the work to find out (would be nice if the usual ones are supported out of the box), more like setting up an interface mapping.

I am very much willing to share thoughts about this, if you would be interested. My normal day job is information architect for SAP and related systems, so i'd be inclined to say i know a little about this :-).

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing