Re: [Shotwell] GSoC idea: Shotwell parametric RAW development
- From: Camilo Polymeris <cpolymeris gmail com>
- To: Adam Dingle <adam yorba org>
- Cc: shotwell lists yorba org, gnome-soc-list gnome org
- Subject: Re: [Shotwell] GSoC idea: Shotwell parametric RAW development
- Date: Wed, 28 Mar 2012 17:10:03 -0400
On Tue, Mar 27, 2012 at 8:10 PM, Adam Dingle <adam yorba org> wrote:
> On 03/26/2012 02:37 PM, Camilo Polymeris wrote:
> Hello Camilo - thanks for getting in touch.
Hello Adam, and thanks for the feedback on my proposal.
>> Also, my needs regarding RAW development are quite simple: adjust the
>> tonal curves (contrast, saturation, temp, etc...) crop, straighten,
>> lens correction& sometimes a bit of denoise. Even if only a subset of
>> these could be done directly in shotwell, it would be a great
>> I believe I am not the only one who would benefit from this, and its
>> interface could be hidden away from the basic user, so to not
>> complicate their workflow.
> We agree this would be a nice enhancement to Shotwell sooner or later. Your
> proposal more or less corresponds to this Shotwell ticket, which we've had
> open for a couple of years now:
Great that you are of that opinion!
>> a) Do you think this can& should be implemented as a plugin?
> Shotwell's plugin system is currently limited: a plugin can only implement
> an import source, a publishing destination or a slideshow transition.
> There's no way that these enhancements could be a plugin today, and I don't
> think it makes sense to try to fit them into a plugin anyway - if we
> implement this it should be part of the Shotwell core.
Yes, as I wrote in another thread, after looking a bit at the code it
seems impossible to something like this as a plugin without huge
refactoring. Also, I agree that it doesn't necessarily make sense --
better if it is in core.
>> b) My work plan includes spending the first GSoC term adding the
>> necessary hooks and parameters to the shotwell core& the second term
>> developing the UI& each tool's particular behaviour. All in all, do
>> you think that is a good approach?
> I think this would be a pretty challenging summer project. We've been
> impressed with the patches you've sent us so far in
> http://redmine.yorba.org/issues/4940 and so you may well be up to the task,
> but I think you should spend some time looking at the code to convince
> yourself that you think this is really doable in a summer.
Uhm, yes. I do have the impression that it might be a little too
ambitious. I am still figuring out Shotwell's code, so I can't really
make an assesment. An option would be to move only a subset of the
pipeline to libraw. Constrain the project to say, only curves, and
then merging with the JPEG pipeline.
> One issue is that RAW support in Shotwell is currently slightly broken. In
> 0.11 we added the ability for the user to switch between the camera's
> development of a RAW photo (in an embedded or paired JPEG) and Shotwell's
> development generated using libraw. But we were on a tight schedule and
> weren't able to iron out all the bugs either for the 0.11 release or for the
> following 0.12 release (where the GTK 3 port took up tons of time). So this
> area of Shotwell remains buggy - see, for example
> I hope we can improve the situation this spring, but these bugs might still
> intersect with your work a bit.
> Here are some things to ponder: in Shotwell's enhance dialog, which of the
> adjustments there could be made in libraw? Which adjustments will need to
> be made later in the pipeline? Does libraw have all the customizable
> parameters we need today, or will we need to propose changes to libraw
> itself to make all this work nicely?
libraw supports: cropping, interpolation, auto wb, user wb, exposure,
noise reduction, rotation, saturation, contrast, ca correction...
In summary, everything we need, except red-eye reduction,
straightening & geometrical lens correction. For the first two we
could use the existing code, while for the latter (if we ever got that
far!) use the lensfun library, maybe as optional dependency.
It is unlikely that changes to libraw post-processing would be
accepted, I believe they aim for compatibility with dcraw.
> Can the enhance dialog look exactly
> the same for RAW photos as it does for JPEG photos, or will we want to add
> some bells and whistles for RAW?
Yes, for the most part. I like that Shotwell is userfriendly and I
would try to keep everything possible under the hood. Things that I
think that would benefit from a specialized interface: Auto WB (to
pick a grey point) & lens correction.
> Or should there be an entirely separate
> dialog for RAW adjustments? With your proposed changes, will the user still
> be able to open a RAW photo in an external RAW editor? If they have
> adjustments both in Shotwell and the external RAW editor, which take
> precedence? I think we'd want to have pretty good answers to all these
> questions before deciding to embark on this project.
>> c) If you are a shotwell developer, would you be willing to mentor this
> Yes - either I or others on the team at Yorba could mentor. :)
So, what I gather is that this is too much work for barely 3 months,
specially considering the bugs involved. So I'll keep this on file for
a later date, and meanwhile work on the post processing plugin idea,
which will also allow me to better understand Shotwell's architecture,
for when I eventually come back to this.
Thanks again for your comments & best regards,
] [Thread Prev