[Digikam-devel] extragear/graphics/digikam

[Gilles Caulier]

Le Mercredi 14 Décembre 2005 13:56, vous avez écrit :
> On Wed, 14 Dec 2005, Gilles Caulier wrote:
> > Hi Boudewijn, how are you (:=)))...
>
> No laptop, so not hacking as much as I would like.
>
> > Sure, in the future, we need to improve krita/digiKam interoperability. I
> > adding this task in my TODO list, because i had any other stuff to do
> > before...
> >
> > But, there is one point that we can talking now : a common ICC profiles
> > repository between krita and digiKam.
> >
> > Like you have see certainly, digiKam now support ICC profiles to render
> > image in editor (printing coming soon).
>
> I noticed from the logs, but haven't had the hd space to build digikam
> recently.
>
> > We have started a repository of digital
> > still camera profiles at this url :
>
> Adobe has released its high qualit profiles under a quite liberal
> license that allows bundling with applications. The openicc project
> has determined a standard location for icc files:
>
> /usr/share/icc (and subdirs, but not following links)
> and
> ~/.icc (and subdirs, but not following links)
>

ok. We take a care about this point when we will update digiKam handbook

> Krita already supports the former, not the latter, but that's a matter of
> adding a little code. We don't let the user select icc files, but build
> a list of them and present the product names to the user. We also allow
> people to choose a profile that will be applied on paste of clipboard
> image data and so on and read the icc profile X Atom in case it's set
> (otherwise we use the configured icc profile).
>
> > http://digikam3rdparty.free.fr/ICCPROFILES/
> >
> > In kde svn, krita provide any common ICC profiles :
> >
> > http://websvn.kde.org/trunk/koffice/krita/data/profiles/
> >
> > Questions :
> >
> > 1 / Perhaps we can merge these places ?
> > 2 / Are you sure that includes ICC profiles in svn is the better place ?
> > 3 / ICC profiles are (c). Are you sure that you can includes by default
> > krita profiles with koffice packages without any problems with commercial
> > compagnies ? (This is why digiKam team have copied ICC camera profiles in
> > a simple web space, not svn)
>
> The profiles we bundle are all free as in public domain (and of none too
> good a quality). I explicitly wanted to avoid having people download
> profile separately, because Krita simply does not function without
> profiles. We've decided that a color isn't a color unless it has a profile
> associated with it.

sure.

>
> Camera profiles are a different issue, and one I hadn't realized existed 
> until I started working on our RAW importer.

Ah, the famous RAW importer. Have you progressed in your current 
implementation ?

Personally, RAW loader in digikam work fine. I use an external dcraw instance 
to decode RAW files, but i'm not satisfied by it. For any performance 
reasons, including dcraw source code in digikam core will be better, but... 
dcraw if a sad C ansi implementation, not a clean C/C++ library. 

To identify and extract thumbnails from RAW files, parse.c source file from 
dcraw project is already included to digikam core. If i trying to add dcraw 
source code, i will have any method conflics between these implementations. I 
need to create a pure C++ class regrouping all dcraw/parse methods and create 
a dedicaced lib (in digiKam core). This is not a trivial task, because there 
is a risk to break dcraw implementation (and future dcraw source code 
backport).

- 
Gilles