Re: ufraw (and others) integration

["Olafur Arason" <olafra gmail com>]

Great work.
Just some HIG..

On 9/6/07, Stephane Delcroix <stephane delcroix org> wrote:
> An update on the RAW status...
>
> - since a few days, db supports versions of images with different
> extensions
> - I wrote an addin that'll help you fix your actual db by merging raw
> +jpeg files of the same image as only one image with versions. This will
> be available very soon via the 'Manage extensions' menu entry.
> - I wrote a patch for ufraw and it was accepted so f-spot can force the
> output file while converting to raw. I still have to write an addin so
> it "Develop in ufraw" appears in everyone's contextual menu.
Please use something like "Develop the raw image", because
some people don't know what ufraw is. And also it should not show
up if the user does not have ufraw installed.
> - the code for reparenting an image as version of another dy drag'n drop
> is already in trunk, just not compiled yet (compile with
> -d:ENABLE_REPARENTING if you want to give it a try)
> - code for keeping Raw+Jpeg together at import time (will make the merge
> addin obsolete) will come after that
>
> hope it clarify the situations a bit...
>
> regards
>
> s
>
> On Tue, 2007-07-17 at 17:57 -0400, Peter Finley wrote:
> > I looked into doing something similar a while ago.  I dug around in
> > the code a bit and if I remember right, I found that the biggest issue
> > with this is that the database doesn't support versions of an image
> > with different file type extensions.  This means that a JPEG can't be
> > stored as version of a RAW file.  I couldn't think of a good solution
> > that didn't involve changing the data model.  It may have changed
> > since I looked at it, though (I hope so).  It was several months ago.
> >
> > Peter
> >
> > On 7/16/07, David Collett <davec internode on net> wrote:
> >         Hi all,
> >
> >         I've spent a bit of time searching the lists for where RAW
> >         support is
> >         currently at and where it is headed, but it's still unclear.
> >
> >         What follows is a description of a simple workflow which I
> >         think would
> >         suit many people in the meantime, and should be easy to
> >         implement.
> >
> >         My ideal workflow would be something like this:
> >
> >         1. import RAW files directly from camera/memcard
> >         2. right-click desired photo and select "develop in UFRAW"
> >         3. UFRAW would be launched where I can perform RAW developing.
> >         4. When UFRAW is closed, the resulting jpeg would be
> >         automatically added
> >         as a version of the original raw image.
> >
> >         Ufraw can easily be told via the commandline, how and where to
> >         save the
> >         output file, suiting f-spot integration. Furthermore, Ufraw
> >         can
> >         optionally save an "ID" file which stores the settings used
> >         during raw
> >         conversion. If desired, this could be saved, so that if the
> >         photographer
> >         decides they dont quite like their conversion, they only have
> >         to
> >         right-click and develop again and will start where they left
> >         off in
> >         ufraw (the resulting jpeg would become yet another version).
> >
> >         Batch processing can easily be accommodated too. Suppose you
> >         have a set
> >         of photos shot in the same conditions and want to batch
> >         process them.
> >         You can right-click/develop the first one as described above.
> >         What this
> >         will do is set your current adjustments into your .ufrawrc
> >         file (a
> >         standard ufraw feature). Now you can select all the remaining
> >         photos in
> >         the set, right-click and choose "develop with UFRAW", when the
> >         develop
> >         action is invoked with multiple selections, it will launch
> >         "ufraw-batch"
> >         instead of "ufraw" (ufraw-batch comes standard with ufraw).
> >
> >         Once the photographer has a good 'developed' jpeg image as a
> >         version,
> >         they can further edit it with the standard f-spot set of tools
> >         (or
> >         externally via gimp etc).
> >
> >         This may not be the holy-grail of RAW integration in f-spot,
> >         but it
> >         would be a big step up for those of us currently using f-spot
> >         to manage
> >         RAW photos.
> >
> >         Can other f-spot users let me know what they think of this
> >         approach?
> >
> >         Can the developers let me know where I might start
> >         implementing it? I
> >         figure I just need to add a right-click menu item which, when
> >         clicked
> >         will launch a sub-process (ufraw/ufraw-batch) with the current
> >         selection, then wait on the process to complete before
> >         re-injecting the
> >         resulting jpegs back into f-spot as versions. Sounds easy
> >         enough?
> >
> >         Thanks,
> >         Dave
> >         _______________________________________________
> >         F-spot-list mailing list
> >         F-spot-list gnome org
> >         http://mail.gnome.org/mailman/listinfo/f-spot-list
> >
> > _______________________________________________
> > F-spot-list mailing list
> > F-spot-list gnome org
> > http://mail.gnome.org/mailman/listinfo/f-spot-list
>
> _______________________________________________
> F-spot-list mailing list
> F-spot-list gnome org
> http://mail.gnome.org/mailman/listinfo/f-spot-list
>