Re: Current plan for RAW integration into f-spot?

["Josh Gerdes" <joshgerdes gmail com>]

Hello Stephanie,

Thank you for the reply.  So from the standpoint of f-spot RAW integration the basic plan is to just use ufraw?

As for the bug I mentioned, after reading the mailing list archives (I have not taken a look at the specific code yet) it seems that f-spot displays the embedded jpeg image as a thumbnail for the RAW file.  People also mentioned that some cameras allow for orienting the embedded jpeg as well.  
So since modifying the RAW file is off limits (which is understandable) could we not just have the rotate image button create a new version of the RAW file as a jpg based on the embedded jpeg that is rotated correctly for displaying within f-spot?
Then in addition, if you used the RAW+Jpg plugin and already have a RAW and jpg image associated together the jpg image could be rotated and the rotation would not be attempted on the RAW version of the file.
From a user perspective it doesn't seem to make sense to have a rotate button enabled for RAW images that does not work even if the exception was caught and ignored.
If this sounds like a feasible idea then I would like to help make it a reality.  Since I am new to f-spot development I am unsure how this sort of functionality is decided upon within the community.  Any guidance would be appreciated.

Thoughts?

Thanks,

Josh

On Nov 18, 2007 3:23 AM, Stephane Delcroix <stephane delcroix org> wrote:

Hi Josh,

Here's my current plans for a better raw support in f-spot:
- support r+j a import time (same functionality as the "Merge Raw"
extension)
- extend the "Develop in UFraw" extension for batch processing
- keep relying on UFraw for raw->jpg conversion

There's not a lot to do on the bug you mentioned, except catching and
ignoring silently the exception. There's no safe way to edit (or modify)
a raw file, and that file is your precious orignal...

AFAIK, all the cameras with Raw capability these days also have a
orientation sensor so the images should be well oriented in f-spot. If
I'm wrong about this, we could think of something else to display the
images, but forget about even touching the file...

regards

s

On Fri, 2007-11-16 at 13:30 -0800, Josh Gerdes wrote:
> Hello,
>
> I am a C# developer and I am interested in contributing to the
> development of more RAW functionality into f-spot.  While searching
> through the mailing list archives I found this thread:
>
> http://mail.gnome.org/archives/f-spot-list/2006-November/msg00001.html
>
> It talked about RAW integration and general workflow with RAW images
> but it ended without any clear plan or focus.  Since that thread I
> notice that some RAW functionality (ufraw plugin, etc.) has been
> implemented.  I would like to help contribute to this development
> starting with this bug:
>
> http://bugzilla.gnome.org/show_bug.cgi?id=497229
>
> I was wondering what the current plan for implementing more RAW
> functionality in f-spot is? I do not want to reinvent the wheel so I
> would like to know what related work is in progress and where the
> f-spot development community is planning to go in terms of RAW
> integration before I start work.
>
> So if anyone could point me in the right direction in finding more
> details on the plan for RAW integration into f-spot that would be
> great.
>
> Thanks,
>
> Josh

> _______________________________________________
> F-spot-list mailing list
> F-spot-list gnome org
> http://mail.gnome.org/mailman/listinfo/f-spot-list