Re: [Shotwell] Shotwell Plugin-based Postprocessing Tools

[Camilo Polymeris <cpolymeris gmail com>]

On Wed, Mar 28, 2012 at 8:38 PM, Adam Dingle <adam yorba org> wrote:
> Camilo,
>
> thanks for your message.  My general feeling about your proposal is that
>
> - it might be more complicated than we want effects to be in Shotwell at this stage in its evolution
> - it is probably too challenging to implement in a single summer
> - it's not clear how it will interact with Shotwell's non-destructive editing model
>
> I'll elaborate on each of these points below.
>
> First, at this stage in Shotwell's evolution I think it might be nice to have a palette of simple effects such as sepia, vignette, matte and so on.  The user could click an effect once to apply it a little bit, or several times to apply it more.  We could display a number over the effect to indicate the degree to which it's been applied.  That would be super easy to use.

Good idea. I was thinking more in the vein of click on effect, slider
appears, move it to "off", "mild", "medium", "strong", effect applied!
But your idea might be better.

> At some later point I think we might have more general effects controlled by parameters or sliders.  For that to work nicely, we'd need to have a scrollable list of effects in a sidebar (like in Lightroom or Aperture).  I think we'd also want to move the existing editing tools into the sidebar, and display metadata information there too (see http://redmine.yorba.org/issues/1918).  That's how I see Shotwell's interface evolving in the long term, but I think we won't get there in time for a summer of code project this summer.

Sure, I mentioned the toolbox idea as a future possibilty, not
necessarily something that will fit into this summer's project.

> I don't think we ever want effects in Shotwell to be able to operate at a certain point in a photo or on a photo region as you've suggested.  To me, that's the domain of editors such as GIMP.  Shotwell should interact nicely with such programs, but I don't think we need those capabilities in Shotwell.

Ok. I included "clicking on points in the image" and such for things
like red-eye reduction & automatic WB. But if deemed unecessary, we
can remove "interactive" parameters. Makes everything simpler. :)

> One challenge with implementing effects as plugins is that Shotwell is non-destructive.  As you probably know, when you make edits in Shotwell nothing changes on disk; Shotwell simply remembers your edit parameters.  Every time you open a photo in Shotwell, it applies your edits on the fly.  If we implement effects as plugins, then they could be applied on the fly too.  But now what happens if I've used an effect to edit a photo, and then I uninstall the effect and open the photo?  Shotwell won't be able to apply the effect since its code will not be present.  We could solve this by saying that effects are destructive, but would be disappointing - I'd like to be able to undo an effect after applying it.  So we might just have to accept that if you uninstall an effect, you can't open any photo that it was applied to.  (Before too long, we want to modify Shotwell so that it writes all edits to photo files on the disk while still keeping the original file - this is http://redmine.yorba.org/issues/1798.  If we have that, then if an effect is uninstalled at least you would still have the modified photo to work with.)

If we followed current behaviour of "edit in external application", of
couse it would be destructive. But I was thinking more of saving the
list of effects applied with their respective parameter values, and
re-apply them when the photo reopens. If the plugin doesn't exist
anymore -- skip it, and notify the user. I think users can expect that
if they deinstall a plugin that function won't be available anymore,
and usually they will find a few they like, and stick with them.

> Another concern here is this: what if an effect plugin gets updated to a newer version which uses a different algorithm for applying the effect?  Then if I open a photo which uses the effect, suddenly it will look different than it did before.  Is this OK?  Or do we need a version number for each effect?

That is a very good point. Then again, same thing would happen if you
update shotwell and there have been changes to e.g. the curves or
red-eye reduction. Maybe store the version of the effect that was
originally used and so give plugin developers a chance to stay
backwards compatible if they change the algorithm? Else, just warn
users that plugins in development are likely to change, and ask
developers, that once their plugin is mature, they don't change the
plugins behaviour.

> These are all things to think about, but all of this is deep enough that I think it may be best left to the core team rather than implemented as a summer project.
>
> I don't want to be discouraging .  You could think through all these issues, study the code to convince yourself that this is doable in a summer, and produce a detailed proposal that describes both how the user interface will work and the architectural changes you plan to make in order to implement this.  If you do all that, we'll certainly be interested to read it and will be open-minded about the project if it seems feasible.  But if you're unsure, I suggest that you look through the Shotwell ticket list (we have over 800 bugs and feature requests!) for ideas which would not require deep changes to the Shotwell core and which would be more easily approached in a summer timeframe.

So far, I *do* think it is doable in 3 months, at least if kept
simple. I have sketches on the UI already (basically reusing the
existing EditingToolWindow) and am writing a prototype interface as we
speak. The project could be further simplified if we reduced the type
of parameters to only the above mentioned slider/number of clicks (or
even just an "on/off" toggle!).

Remember, I wouldn't be implementing any complex graphic-processing
algorithms, just the bare minimum to prove that the plugin system
works (or probably use some canned library function).

In terms of changes to the core photo pipeline:
The id and parameters of the effects  would have to be stored as
transformations in the photorow, then, when a pixbuf is requested,
after rotating & cropping it, the effect's "run()" (or similarly
named) function is called, passing the pixbuf and the parameter
value(s) as arguments. This function edits the pixbuf as needed and
returns it.

Of course, I intend to write a longer proposal detailing this, and
also expect to see changes during both the design and implementation
phases.

> Cheers -
>
> adam

Thanks for your feedback!

Regards,
Camilo