Future direction of digikam?

[Ravi Swamy]

I'm wondering what the future direction is for digikam and who the target
user is.  I'm a serious amateur and do a few paid things. I shoot about
75% RAW, 25% JPEG, 50-1000 shots per session.

I'm specifically interested in the "workflow" aspects.  I'm doing my yearly
reevaluation and I'm thinking of switching from Picasa/UFraw/GIMP to Lightroom
on my Macbook.  I'm checking out digikam too and trying to see where it's
going.  After reading some comments in the bugzilla entry for the light table
it seems like the authors were at least somewhat interested in cloning
Aperture or Lightroom.  I love open source software but its usually
written for programmers by programmers not always what the end user wants.
The comments on the light table bugzilla entry showed to me that the authors
of digikam were different and actually listening to real photographers.

If anyone is interested I could elaborate further.  If not thanks for
a nice and improving program.
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Arnd Baecker]

Hi Ravi,

let my try to answer your questions from my point of view:

On Fri, 9 Nov 2007, Ravi Swamy wrote:

> I'm wondering what the future direction is for digikam

Apart from the incremental improvements, which take
mainly part in the development of the upcoming 0.9.3 and
0.9.4 (See http://www.digikam.org/?q=about/releaseplan),
there is in parallel the development of
0.10. branch which uses KDE4. This, together with
a new database layout, will provide the basis for many new
features, addressing various of the wishes in the bug tracker
which require a major structural changes
For the new database scheme, see for example
  http://www.digikam.org/?q=node/256
Apart from this, the future direction is to a large extent
driven by users, which can vote for bugs and define
priorities in this way.
Moreover, contributions to the code are of course also
very well taken ... ;-)

> and who the target
> user is.  I'm a serious amateur and do a few paid things. I shoot about
> 75% RAW, 25% JPEG, 50-1000 shots per session.

Digikam is used by many normal amateurs and I am at least
aware of one professional whose main business is photography.
So it seems to cater well for a large range of purposes.

> I'm specifically interested in the "workflow" aspects.

The workflow aspect is definitively a very important one,
and in my opinion in this area a lot of improvements
are possible. Getting a  workflow design is non-trivial,
so any ideas/suggestions/ (code ;-) is very welcome!

>  I'm doing my yearly
> reevaluation and I'm thinking of switching from Picasa/UFraw/GIMP to Lightroom
> on my Macbook.

Lightroom is surely a good product, judging from the reviews
(So I am not going to bash it, in particular because I haven't used
it ;-).

> I'm checking out digikam too and trying to see where it's
> going.  After reading some comments in the bugzilla entry for the light table
> it seems like the authors were at least somewhat interested in cloning
> Aperture or Lightroom.

Well, digikam is surely not about cloning any of these applications,
but many requests by users of course arise from previous usage
of other applications ;-).

> I love open source software but its usually
> written for programmers by programmers not always what the end user wants.
> The comments on the light table bugzilla entry showed to me that the authors
> of digikam were different and actually listening to real photographers.

The good thing is that the authors are real photographers
(though non-professional ;-).

> If anyone is interested I could elaborate further.  If not thanks for
> a nice and improving program.

Surely, input is very welcome!
If it is about concrete feature wishes, they are best
done in terms of a wish in the bug tracker, so that nothing
of the discussion gets lost (in contrast to the mailing list here).
For a more general discussion about the workflow, this mailing
list might be the better place
(but with keeping in my mind, that at some point this
should lead to concrete wishes for the bug-tracker,
so that things can be improved step-by-step).

Hope these explanations help a bit to clarify the situation
and the development process (at least how I see things ...;-),

best, Arnd

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Ravi Swamy]

On Fri, 9 Nov 2007, Arnd Baecker wrote:

>> I'm specifically interested in the "workflow" aspects.
>
> The workflow aspect is definitively a very important one,
> and in my opinion in this area a lot of improvements
> are possible. Getting a  workflow design is non-trivial,
> so any ideas/suggestions/ (code ;-) is very welcome!
>
>>  I'm doing my yearly
>> reevaluation and I'm thinking of switching from Picasa/UFraw/GIMP to Lightroom
>> on my Macbook.
>
> Lightroom is surely a good product, judging from the reviews
> (So I am not going to bash it, in particular because I haven't used
> it ;-).

Unfortunately I don't have a lot of time to code.  Most of the code I write
at work is command line stuff for engineers with very little user interfaces.

Do any of the developers have access to Windows or OS X?  If I made a donation
would you consider using it to purchase a copy of Lightroom or Aperture?
Would you be willing to use it, watch these tutorials:

http://www.whibalhost.com/_Tutorials/Photoshop_LR/08/index.html

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.  Also, anybody that
can make a decent image is a real photographer regardless of camera used,
software, or experience level.
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Arnd Baecker]

On Fri, 9 Nov 2007, Ravi Swamy wrote:

> On Fri, 9 Nov 2007, Arnd Baecker wrote:
>
> >> I'm specifically interested in the "workflow" aspects.
> >
> > The workflow aspect is definitively a very important one,
> > and in my opinion in this area a lot of improvements
> > are possible. Getting a  workflow design is non-trivial,
> > so any ideas/suggestions/ (code ;-) is very welcome!
> >
> >>  I'm doing my yearly
> >> reevaluation and I'm thinking of switching from Picasa/UFraw/GIMP to Lightroom
> >> on my Macbook.
> >
> > Lightroom is surely a good product, judging from the reviews
> > (So I am not going to bash it, in particular because I haven't used
> > it ;-).
>
> Unfortunately I don't have a lot of time to code.  Most of the code I write
> at work is command line stuff for engineers with very little user interfaces.
>
> Do any of the developers have access to Windows or OS X?  If I made a donation
> would you consider using it to purchase a copy of Lightroom or Aperture?

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

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

Best wishes,

Arnd
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

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

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

2007/11/12, Ravi Swamy <[hidden email]>:

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.

Mail me directly. Look details on project page for details:

http://www.digikam.org/?q=donation

Gilles Caulier

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

2007/11/12, Ravi Swamy <[hidden email]>:

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.

I have planed to make a new tool named RAWImport including Color Management + White Balance options (including gamma adjustements). This will reduce serialization operations to import RAW files in editor.

But at this moment, i'm buzy right with KDE4 port of digiKam + kipi-plugins. I hope to do it for digiKam 0.9.4

Gilles

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Ravi Swamy]

On Mon, 12 Nov 2007, Gilles Caulier wrote:

> I have planed to make a new tool named RAWImport including Color Management
> + White Balance options (including gamma adjustements). This will reduce
> serialization operations to import RAW files in editor.
>
> But at this moment, i'm buzy right with KDE4 port of digiKam + kipi-plugins.
> I hope to do it for digiKam 0.9.4

Do you keep up with development of ufraw?  The latest GUI is pretty good.
It's easy to adjust white balance, saturation, curves, see highlight
clipping.

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[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
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users