list of possible GSoC projects for digikam

[Arnd Baecker]

Hi,

following the discussion on the IRC with Gilles,
here is a list of possible projects for the Google Summer of Code
(most likely to take place this year again, see
http://code.google.com/soc/2007/ for information for last years run).

I think such projects for digikam should
- add something new, exciting/interesting (i.e. not just bug-fixes)
- be self-contained and not too big, so that success is "guaranteed"
  (but expandable ... ;-)
- therefore most likely they should not touch too much
  in the core of digikam ...

Some Projects:

- http://bugs.kde.org/show_bug.cgi?id=149485
  "Advanced image resize for the digikam editor"

- http://bugs.kde.org/show_bug.cgi?id=144593
  "New High Dynamic Range (HDR) plugin"
  This could involve
  - contrast masking
  - HDR generation and tone-mapping (but we have qtpfsgui for that ...!)
  - enfuse (see the hugin project, http://wiki.panotools.org/Enfuse )

- Fulla http://wiki.panotools.org/Fulla
  integration into the JPG and raw workflow.

  This tool addresses: Chromatic aberration, Lens distortion, Vignetting

  Specific bugs:
  - http://bugs.kde.org/show_bug.cgi?id=98651
    "imageplugin filter based on clens"
  - http://bugs.kde.org/show_bug.cgi?id=143864
    "Tool to remove Chromatic Aberration from photos"

  Because of a tight integration into digikam,
  I am not sure, whether this can still be realized as kipi-plugin.
  (Also thinking ahead in the direction of the "action lists"
    http://bugs.kde.org/show_bug.cgi?id=125387)

- http://bugs.kde.org/show_bug.cgi?id=143978
  "Sync Plugin: New Syncronisation Framework KIPI Plugin"

- KROSS integration for digikam 0.10:
  http://bugs.kde.org/show_bug.cgi?id=146866
  This would be very powerful as it allows to script
  digikam via python, ruby etc.
  (For example realized for krita).

  In the long run I would love to see a way that users
  can contribute simple scripts to digikam
  (either for download, or included in the digikam distribution
   in a scripts directory) which can do all kinds of tasks.
  The idea is to get the community (and just people capable of
  C++ programming) involved in building useful tools for digikam
  (e.g.: wouldn't it be possible to do something similar as
   http://www.outbackphoto.com/workflow/wf_a118/essay.html ?)

- Layers, adjustment layers, smart filters and such:
  See eg.:
  http://www.outbackphoto.com/workflow/wf_a117/essay.html

- http://bugs.kde.org/show_bug.cgi?id=138290
   "GPSSync plugin integration in the side bar"
  This does not touch digiKam's core; the idea is to use marble from kde4,
  http://edu.kde.org/marble/

  And geo-location stuff is a hot topic... ;-)

- http://bugs.kde.org/show_bug.cgi?id=146288
  "Face detection / recognition for digikam"


Well, let's collect all ideas for the moment and
then we have to select some of them...
(Presumably it is good to have already a student interested
in a specific project, before one starts thinking about
the concrete proposal.)

About the target: KDE3 or KDE4:
In my opinion KDE4, as digikam 0.10 is planned for end of July 2008.

Best, Arnd



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

Dnia Monday 04 of February 2008, Arnd Baecker napisał:
> Well, let's collect all ideas for the moment and
> then we have to select some of them...
> (Presumably it is good to have already a student interested
> in a specific project, before one starts thinking about
> the concrete proposal.)


- Database backend for digiKam making possible for groups of people
  working on the same set of photograps - especially metadata edition.

  This feature could bring digiKam to photo agencies - contrary to
  single photographer workshop where digiKam already shines :)

  Note: I don't know  how this feature could affect core digiKam
  database stuff.

  http://bugs.kde.org/show_bug.cgi?id=146865

- Off-line manager

  http://bugs.kde.org/show_bug.cgi?id=114539

m.

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

[Gerhard Kulzer-3]

Thank's Arnd for the good list.Here are my additions:
- included data integrity into the digiKam workflow (as discussed on the ML)
  that would provide us with a robust framework for saving images, Many other projects could profit fromt that

- HDR: I just submitted a bash script using enfuse to do HDR. It is now easy with enfuse to create a plugin for digikam. I think it's is not worthwhile wasting Googlesummer time for that

- A better filmgrain plugin, the current one is unusable
  I have some precise ideas how to do that

- A simple clone tool with 2 types of 'brushes': round step function and round gaussian

- change digiKam into a non-modal editor mode alias Aperture, Lightone, ....

- in the same veine: in-place editing of metadata.

- a better vignetting tool (better visual feedback: without changing the current algo, I'd like a histogram across a section line that can be positioned with the mouse close to a border. With that it is then easier to set the many vignetting sliders)

- LDR plugin: in a Gimp workflow that would look like that: dublicate layer, desaturate top layer, invert, gaussian blur 25, merge layers in overlay mode
  All these functions are already there in different plugins, they only need to be stiched together. A lightness curve adjust widget for the toplayer would be very welcome too.

voilà for today (or tonight rather)

Gerhard

On Monday 04 February 2008 Arnd Baecker wrote:

> Hi,
>
> following the discussion on the IRC with Gilles,
> here is a list of possible projects for the Google Summer of Code
> (most likely to take place this year again, see
> http://code.google.com/soc/2007/ for information for last years run).
>
> I think such projects for digikam should
> - add something new, exciting/interesting (i.e. not just bug-fixes)
> - be self-contained and not too big, so that success is "guaranteed"
>   (but expandable ... ;-)
> - therefore most likely they should not touch too much
>   in the core of digikam ...
>
> Some Projects:
>
> - http://bugs.kde.org/show_bug.cgi?id=149485
>   "Advanced image resize for the digikam editor"
>
> - http://bugs.kde.org/show_bug.cgi?id=144593
>   "New High Dynamic Range (HDR) plugin"
>   This could involve
>   - contrast masking
>   - HDR generation and tone-mapping (but we have qtpfsgui for that ...!)
>   - enfuse (see the hugin project, http://wiki.panotools.org/Enfuse )
>
> - Fulla http://wiki.panotools.org/Fulla
>   integration into the JPG and raw workflow.
>
>   This tool addresses: Chromatic aberration, Lens distortion, Vignetting
>
>   Specific bugs:
>   - http://bugs.kde.org/show_bug.cgi?id=98651
>     "imageplugin filter based on clens"
>   - http://bugs.kde.org/show_bug.cgi?id=143864
>     "Tool to remove Chromatic Aberration from photos"
>
>   Because of a tight integration into digikam,
>   I am not sure, whether this can still be realized as kipi-plugin.
>   (Also thinking ahead in the direction of the "action lists"
>     http://bugs.kde.org/show_bug.cgi?id=125387)
>
> - http://bugs.kde.org/show_bug.cgi?id=143978
>   "Sync Plugin: New Syncronisation Framework KIPI Plugin"
>
> - KROSS integration for digikam 0.10:
>   http://bugs.kde.org/show_bug.cgi?id=146866
>   This would be very powerful as it allows to script
>   digikam via python, ruby etc.
>   (For example realized for krita).
>
>   In the long run I would love to see a way that users
>   can contribute simple scripts to digikam
>   (either for download, or included in the digikam distribution
>    in a scripts directory) which can do all kinds of tasks.
>   The idea is to get the community (and just people capable of
>   C++ programming) involved in building useful tools for digikam
>   (e.g.: wouldn't it be possible to do something similar as
>    http://www.outbackphoto.com/workflow/wf_a118/essay.html ?)
>
> - Layers, adjustment layers, smart filters and such:
>   See eg.:
>   http://www.outbackphoto.com/workflow/wf_a117/essay.html
>
> - http://bugs.kde.org/show_bug.cgi?id=138290
>    "GPSSync plugin integration in the side bar"
>   This does not touch digiKam's core; the idea is to use marble from kde4,
>   http://edu.kde.org/marble/
>
>   And geo-location stuff is a hot topic... ;-)
>
> - http://bugs.kde.org/show_bug.cgi?id=146288
>   "Face detection / recognition for digikam"
>
>
> Well, let's collect all ideas for the moment and
> then we have to select some of them...
> (Presumably it is good to have already a student interested
> in a specific project, before one starts thinking about
> the concrete proposal.)
>
> About the target: KDE3 or KDE4:
> In my opinion KDE4, as digikam 0.10 is planned for end of July 2008.
>
> Best, Arnd
>
>
>
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel
>
>

--
><((((º> ¸.·´¯`·... ><((((º> ¸.·´¯`·...¸ ><((((º>
http://www.gerhard.fr

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

[Colin Guthrie-6]

Arnd Baecker wrote:
>   Because of a tight integration into digikam,
>   I am not sure, whether this can still be realized as kipi-plugin.
>   (Also thinking ahead in the direction of the "action lists"
>     http://bugs.kde.org/show_bug.cgi?id=125387)
>
> - http://bugs.kde.org/show_bug.cgi?id=143978
>   "Sync Plugin: New Syncronisation Framework KIPI Plugin"

I've been giving this a little thought of late (in the absence of
actually doing any coding on it!), and the more I think about this the
more I come to the conclusion that it should be separated from KIPI and
Digikam. I'm not sure if any of you guys have had a look at Conduit but
it provides a standard (Gnome) system for syncronising apps with various
things including webserivces like facebook and picasaweb etc. It seems
like a sensible approach in my mind and one I'd like to see happen in
KDE too.

I don't know if people agree with me on this so opinions are welcome and
perhaps a kipi pluign could be created that would tie things into it.
What it would mean is a more robust DBUS API to query Digikam (this may
exist already, I've simply not looked). This DBUS API should be
relatively standard ideally, allowing other KDE apps to implement
similar APIs. Perhaps the API used by FSpot and digikam are/can be
compatible?

Anyway, I think that Conduit or Konduit if it ever arrives, and opensync
are probably the important systems to bear in mind when moving forward
with this. I'll add more info to the bug when I get more info/responses.

Opinions/thoughts welcomed.

Col

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

[Gilles Caulier-4]

2008/2/4, Mikolaj Machowski <[hidden email]>:

Dnia Monday 04 of February 2008, Arnd Baecker napisał:
> Well, let's collect all ideas for the moment and
> then we have to select some of them...
> (Presumably it is good to have already a student interested
> in a specific project, before one starts thinking about
> the concrete proposal.)


- Database backend for digiKam making possible for groups of people
  working on the same set of photograps - especially metadata edition.

  This feature could bring digiKam to photo agencies - contrary to
  single photographer workshop where digiKam already shines :)

  Note: I don't know  how this feature could affect core digiKam
  database stuff.

  http://bugs.kde.org/show_bug.cgi?id=146865

- Off-line manager

  http://bugs.kde.org/show_bug.cgi?id=114539

Mik, this can be done ony when new DB schema + DB interace will be finalized by Marcel. It's too short to propose an GSoC about this subject.

But i'm agree with you, this feature is very important to do for the future...
 
Gilles

m.

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

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

[Marcel Wiesweg]

> >   Note: I don't know  how this feature could affect core digiKam
> >   database stuff.
> >
> >   http://bugs.kde.org/show_bug.cgi?id=146865
> >
> > - Off-line manager
> >
> >   http://bugs.kde.org/show_bug.cgi?id=114539
>
> Mik, this can be done ony when new DB schema + DB interace will be
> finalized by Marcel. It's too short to propose an GSoC about this subject.
>
> But i'm agree with you, this feature is very important to do for the
> future...

Yes. This requires too parts:

- adapt database backend to a database system (say, MySQL, or PostgreSQL) that
supports running on a server with multiple client access. This mostly
involves checking that our SQL, which is developed for SQLite, also works for
the other db. "Real backend" stuff like client lib access is done for us by
Qt

- set up locking mechanisms and change notifications needed when two people
access the same image / album / tag structure at the same time. (currently,
there is code to distribute change notification via DBUS locally). This could
be done by mechanisms of the database, an extra client/server structure, peer
to peer approach, or a combination of these.

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

[Gilles Caulier-4]

Arnd,

Another Google summer code proposal, outside digiKam, is to have writting mode for PNG file in Exiv2...

This is very important to handle PNG files like JPEG. If PNG writting mode on the fly is implemented, this will a killer feature into digiKam.

Patch on my computer is just started and very uncomplete. I have no more free time currently to implement it.

Andreas, I know that you is in the mailling list. What do you think about ?

Best

Gilles

2008/2/4, Arnd Baecker <[hidden email]>:

Hi,

following the discussion on the IRC with Gilles,
here is a list of possible projects for the Google Summer of Code
(most likely to take place this year again, see
http://code.google.com/soc/2007/ for information for last years run).

I think such projects for digikam should
- add something new, exciting/interesting (i.e. not just bug-fixes)
- be self-contained and not too big, so that success is "guaranteed"
  (but expandable ... ;-)
- therefore most likely they should not touch too much
  in the core of digikam ...

Some Projects:

- http://bugs.kde.org/show_bug.cgi?id=149485
  "Advanced image resize for the digikam editor"

- http://bugs.kde.org/show_bug.cgi?id=144593
  "New High Dynamic Range (HDR) plugin"
  This could involve
  - contrast masking
  - HDR generation and tone-mapping (but we have qtpfsgui for that ...!)
  - enfuse (see the hugin project, http://wiki.panotools.org/Enfuse )

- Fulla http://wiki.panotools.org/Fulla
  integration into the JPG and raw workflow.

  This tool addresses: Chromatic aberration, Lens distortion, Vignetting

  Specific bugs:
  - http://bugs.kde.org/show_bug.cgi?id=98651
    "imageplugin filter based on clens"
  - http://bugs.kde.org/show_bug.cgi?id=143864
    "Tool to remove Chromatic Aberration from photos"

  Because of a tight integration into digikam,
  I am not sure, whether this can still be realized as kipi-plugin.
  (Also thinking ahead in the direction of the "action lists"
    http://bugs.kde.org/show_bug.cgi?id=125387)

- http://bugs.kde.org/show_bug.cgi?id=143978
  "Sync Plugin: New Syncronisation Framework KIPI Plugin"

- KROSS integration for digikam 0.10:
  http://bugs.kde.org/show_bug.cgi?id=146866
  This would be very powerful as it allows to script
  digikam via python, ruby etc.
  (For example realized for krita).

  In the long run I would love to see a way that users
  can contribute simple scripts to digikam
  (either for download, or included in the digikam distribution
   in a scripts directory) which can do all kinds of tasks.
  The idea is to get the community (and just people capable of
  C++ programming) involved in building useful tools for digikam
  (e.g.: wouldn't it be possible to do something similar as
   http://www.outbackphoto.com/workflow/wf_a118/essay.html ?)

- Layers, adjustment layers, smart filters and such:
  See eg.:
  http://www.outbackphoto.com/workflow/wf_a117/essay.html

- http://bugs.kde.org/show_bug.cgi?id=138290
   "GPSSync plugin integration in the side bar"
  This does not touch digiKam's core; the idea is to use marble from kde4,
  http://edu.kde.org/marble/

  And geo-location stuff is a hot topic... ;-)

- http://bugs.kde.org/show_bug.cgi?id=146288
  "Face detection / recognition for digikam"


Well, let's collect all ideas for the moment and
then we have to select some of them...
(Presumably it is good to have already a student interested
in a specific project, before one starts thinking about
the concrete proposal.)

About the target: KDE3 or KDE4:
In my opinion KDE4, as digikam 0.10 is planned for end of July 2008.

Best, Arnd



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

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

On Feb 5, 2008 10:16 PM, Gilles Caulier <[hidden email]> wrote:

> Arnd,
>
> Another Google summer code proposal, outside digiKam, is to have writting
> mode for PNG file in Exiv2...
>
> This is very important to handle PNG files like JPEG. If PNG writting mode
> on the fly is implemented, this will a killer feature into digiKam.
>
> Patch on my computer is just started and very uncomplete. I have no more
> free time currently to implement it.
>
> Andreas, I know that you is in the mailling list. What do you think about ?

PNG refactoring and write-support is a possible self-contained
project. Although it's one of these rather hairy low-level things
which, I guess, has limited show-off potential and maybe a lower fun
factor compared to coding fancy GUI widgets. It would be a small
project, I estimate 3-4 weeks should be enough. Time permitting during
that period, I'd be willing to guide someone.

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

[Gerhard Kulzer-3]

I have one more project idea: Virtualization of albums

My proposal is not so difficult to implement, it is more a re-arranging of already available parts:

Current -> New

Albums Files

Collections Albums

Tags Tags and Rating (alternative name: Keywords & Rating)

Timeline Timeline

Calendar Calendar

Searches Searches

Essentially the Collections would fall away in favor of virtual Albums.

The files would be called what they are.

Tags should integrated automatically a 0-5 star rating section.

This proposal provides in my eyes more consistency with other applications, notably Amarok and OS applications. As far as I know, Albums are virtual everywhere.

It will not take away any feature or flexibility in digiKam.

Gerhard

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