[Digikam-users] Future direction of digikam?

[Arnd Baecker]

Hi Ravi,

thanks a lot for your e-mail, let me add some
comments, in addition to Gilles reply:
((just to warn you before: many will end
with "Could you file a wish for this?" ;-))

On Mon, 12 Nov 2007, Ravi Swamy wrote:
> On Sat, 10 Nov 2007, Arnd Baecker wrote:
[...]
> > So what are your suggestions for a workflow with digikam?
>
> The edit program seems too separate.  I don't know if it really is separate
> or shared memory or whatever.  In library mode the right side tabs like EXIF
> data, tags, etc are useful but in edit mode I'd prefer an option to have
> white balance, levels, curves, as separate sub windows on the right side.

Yes, makes perfect sense
(still having the EXIF Info and tags available as well
as they can be useful)

> Lightroom/Aperture/Picasa store the image modifications as commands.
> I think digikam processes the image serially.  Example of editing an image:
>
> 1) adjust white balance, click OK
> 2) data adjusted in memory
> 3) adjust curves, click OK
> 4) data adjusted in memory
> 5) readjust white balance
>
> I'm assuming that in digikam step 5 uses the data as it was in step 4?

As far as I know: yes.

> Every edit step decreases the quality of the data.  You can avoid this by
> undoing steps, then reapply the white balance correctly but that can slow
> you down.
>
> The other programs store the edit steps as commands so you just adjust the
> value of the white balance and it replays the edit commands to update the
> image.  You don't change one parameter, hit OK, then change another.  You
> adjust the exposure, saturation, etc all at the same time.
>
> You don't get any new JPEGs, TIFFs, nothing until you're done, then you
> hit Export and it takes a few minutes to churn and generate new files
> with all your changes.
>
> By keeping the edit steps as a series of commands you can store those
> as custom develop settings then easily apply them to other images in a
> batch process.
>
> I realize that this may be a fundamental design issue.

Yes, this would change a lot, also internally.
But to me it sounds like the right approach.

A lot of what you wrote is already expressed here
  Bug 125387: Simulate changes to images only
  http://bugs.kde.org/show_bug.cgi?id=125387
and this is one of the wishes with the largest number of votes.
Then there is the discussion in
  http://wiki.kde.org/tiki-index.php?page=Digikam+development+discussion
in particular under
  "Storing relations and actions"

> Here are maybe some simpler ideas.  Can I have two images open for edit?
> When I edit one, make a change without saving, then select another for
> edit I'm forced to save the first image.  Why not have a bunch of edit
> windows open, then click a "Batch Save" button when I'm done.

Currently it is not possible.
Could you file a wish for this?

> If the editor is to remain separate how about linking the light table to
> the editor.  Edit two pics at once and pan around the light table to compare.

Interesting idea. Could you file a wish for this?
(Code-wise this would be a lot of non-trivial work ...)

> I'd like preferences for how to automatically name output files so I don't
> have to type in a file name.  Let's say I edit dsc_3142.nef (Nikon RAW file)
> The default save filename is dsc_3142.nef   There should be a default save type
> setting so it changes the name and type to .jpg or .tiff.  Assuming you
> were editing a jpeg, most don't want to overwrite their original jpeg.
> Lightroom allows you to name new files by appending a number, date,
> custom string (i.e. dsc_3142-2.jpg)   These are the kind of minor things
> that save time.  Typing in a "b" or "-2" a hundred times is pointless.

This has been discussed a lot in this context:
  original image is silently overwritten when saving (patch)
  http://bugs.kde.org/show_bug.cgi?id=103350
The current solution was to never silently overwrite the
original.
Instead of re-opening this bug, I would suggest
that you file a new wish for this.

> I saw some comments from the developers on image "Stacks" but that it
> would require a database rewrite.   I haven't really used this in the
> proprietary programs but it's useful for a sports photographer shooting at
> 8 frames per second.  Group 20 shots together to reduce library thumbnail
> clutter, then pick the best one.

Yes, and one could define a mode that any sequence of images
which are not separated by >1s are taken into a group automatically
(Maybe some other rules would be useful as well, so this should
be flexible ...)

> Some shoot in RAW+JPEG mode, a preference to automatically create a stack of
> these 2 files would be useful to some.

Absolutely, see
  Bug 126149: Camera stores both jpeg and raw (nef), handle both as one
  http://bugs.kde.org/show_bug.cgi?id=126149

> Stacks could also be an interesting way to organize multiple versions of
> the same base file.

Yes, grouping images is very important IMO
(also for HDR images, or panorama shots,
where one would like to see one or two images out of such a group).
See
  http://bugs.kde.org/show_bug.cgi?id=121310
(and add your votes to it ;-).
This is planned for digikam >0.10.0

> I realize these are a lot of ideas, maybe not all of them are good or
> practical given the existing code but I hope you will try to see why I
> think they are useful.

You do address important issues! And yes, they will
require more substantial changes to the code-base.
For example, as far as I understand, for grouping of images,
the database needs to be changed
and the album icon view has to provide a visual
means to indicate groups of images, to show all members
in a group and to select members which will are still shown
within a group when it is "collapsed".

The action lists seems like a really big and important one ...

Thanks a lot for your comments and thoughts, best

Arnd