[Digikam-users] Future direction of digikam?

[Ravi Swamy]

On Sat, 10 Nov 2007, Arnd Baecker wrote:

> I don't use windows at all, but donations to the digikam
> project are surely welcome.

I will send you a private email about donations.


>> Would you be willing to use it, watch these tutorials:
>>
>> http://www.whibalhost.com/_Tutorials/Photoshop_LR/08/index.html
>
> These tutorials are already worth watching even without
> having the software - thanks for the pointer!
>
>> and then ask questions to users here about how they use a feature or
>> why a feature is important so you can understand how to implement an even
>> better version in digikam?  Clone was a poor choice of worlds but I think
>> Lightroom is a good model that can be improved upon.
>
> Fully agree! However, I think it does not really work
> to just shortly try a software, without properly using it over a longer
> period, and therefore suggestions by users like you with
> experience of other software are of particular importance.
>
> 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.

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?
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.

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.

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.

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.

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.

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

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

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.