[Digikam-devel] About dcraw, libufraw, libopenraw and libkdcraw

Gilles Caulier caulier.gilles at gmail.com
Wed Apr 4 10:09:53 BST 2007


2007/4/3, Leopold Palomo Avellaneda <lepalom at wol.es>:
>
> A Dilluns 02 Abril 2007 19:16, Gilles Caulier va escriure:
> > 2007/4/2, Leopold Palomo Avellaneda <lepalom at wol.es>:
> [....]
> >
> > We need a library, not a simple binary program to decode RAW files. This
> is
> > why there are a lots of projects witch re-implemente/re-use dcraw.c from
> > Dave
>
> well, I think that there are a more complex needed in this. ...
>
>
> > >I like the ideas from Mr. Figuière to develop a library to use in the
> free
> > > software projects for the raw. But, to begin a new library from
> scratch,
> > > (or
> > > I understand that it have been developed in this manner) is a lot of
> > > work.
> >
> > Exact. This is why i think this project will never out, or perhaps in a
> far
> > far future...
> >
> >
> > However, maybe it's the most easy thing, do it your self from zero.
> >
> >
> > no. RAW file decoding is a science of reverse engineering. Dave have
> used
> > 10 years of like to provide dcraw.c
>
> sure, probably you are right. However, at least as Mr. Figuière says in
> his
> webpage we can decode a lot of cameras. I think that probably we will use
> the
> dcraw code.
>
> > Since some time ago I use ufraw to convert my photos to something
> viewable.
> >
> > > I
> > > like very much Mr. Fuchs application and I think that he have designed
> > > and developed a very good application to convert raw files. Also, I
> think
> > > that the idea to have some kind of job ticket, or convert options that
> he
> > > propose
> > > in the ufraw xml file it's a very good idea.
> > >
> > > I proposed to Mr. Fuchs to try to make the ufraw file description
> (xml)
> > > as "standardized" file format in the way that you could use it in any
> > > application having the same (or very similar) results. Mr. Fuchs told
> me
> > > that
> > > one way to do it is encapsulate ufraw in a library.
> >
> > fine.
>
> so, are you saying that you like this approach?


why not. But i need to study indeep how UFRAW work exactly...


[...]
>
> > > and the kde project. I have been a bit surprised when today looking on
> > > the blog of digikam I have been an entry about the libkdcraw. However,
> I
> > > have seen that has a dependency with the kdelibs, as normal as a kde
> lib.
> >
> > libkdcraw provide and interface for KDE applications. This
> implementation
> > come from digiKam core and will be used by digiKam 0.9.2 and
> kipi-plugins
> > 0.1.4. In the future, Krita will use it when libkdcraw will be ported to
>
> > QT4/KDE4. I'm sure than KDE KIO slave will use it later...
>
> ok, interesting.
>
> > The implementation provide an C++ interafce witch use QT and KDE
> component
> > to run. Also, libkdcraw provide a QT/KDE settings widget used by hosts
> > application to set RAW decoding parameters.
> >
> > There is no plan to remove the KDE/Qt. This is a non sence. If a low
> level
> > library need to be done, libkdcraw is not the good way.
> >
> [....]
> > > dcraw in the manner to help it to integrate in a library?
> >
> > This is must be done in a low level library... like an ufraw-lib for
> > example. This will be easy to fix libkdcraw to support ufraw shared lib
> > instead dcraw.c.
> >
> >
> > (I have in mind the
> >
> > > little  modification that the libkdcraw have to do obtain the model
> and
> > > camera
> >
> > Already done in libkdcraw, plus others stuff... (:=)))... Are you
> already
> > used digiKam ?
>
> when the manner to manage raw files change .....


because in digiKam we use Color Management every where.


>
> > - Mr. Wiesweg and Mr. Caulier (digikam) what do you think to modify
> >
> > > libkdcraw
> > > to avoid any dependency of qt or kde in the way that the gnome team
> > > (remember, I use kde!!!! ;-) ) or whatever program could use it?
> >
> > no... see below...
> >
> >
> > - Mr. Fuchs, what do you think to begin to modify ufraw in a way that
> use
> >
> > > this possible library or another in common?
> >
> > This is the better way...
> >
> > Question : where is Dave Coffin job in this mail ? This is the main
> actor
> > about RAW file format reverse-engineering ! If a low level shared lib is
> > created for that, Dave is the better guy to do the core. Others
> developpers
> > can maintain and adapt the lib interface...
>
> Well, I think that the problem or the situation is a bit more complex.
> Maybe
> I'm wrong but I think that the ufraw do with the raw files is more
> interesting that a simple conversion. To me the problem has four parts:
>
> 1) from raw files from different vendors understand how is the information
> stored (compressed/ encrypted/ etc) and obtain the data from the files
>
> 2) using this data, apply the adjust that you want as icc/icm, curves,
> noise
> reduction, mask ...
>
> 3) and then convert the data from 1, using the parameters from 2 using
> some
> sophisticated method in 3
>
> 4) this result saves it in a tiff, jpeg, compressed, 16 bits, 8 bits, etc.
>
> I think, (but I insist that maybe I'm wrong) that the interesting approach
> is
> to set the parameters in 2) from  the original raw data because the result
> will be better than apply the filters from the result in 4) in krita/gimp
> or
> whatever.


Better... you want mean about White balance correction during decoding ?


dcraw do a very good job (the best one) in 1). Do good job in 2) (but using
> ufraw, the result is better) and do a very good job in 3) and 4).
>
> The idea of a libraw, or whatever, is taking the good part done in 1) by
> dcraw
> + adding good part done in ufraw in 2) and 3) and encapsulate it in a
> library
> in the way that could be used by gimp, krita, digikam or whatever. Not
> only a
> wrap around dcraw as is done by libkdcraw.
>
> Also, the idea of Mr. Fuchs about the ufraw files could complement the
> library
> in the manner that we could have the same (or very similar) results using
> the
> program that we want, because we were using the same criteria (as a
> parameters) in the library. Having a this common library we can have the
> benefits of a lot users testing it in both desktops with their favourite
> applications.
>
> That's is the idea about to have some kind of common library to manage the
> raw
> files.


The main question is  : Is UFRAW team is ready to provide the UFRAW core
like a shared library ?

This is the first problem to solve...

The second one is the licence header used in dcraw.c > 8.60 witch is
uncompatible with Debian & co dist. Look here :

https://launchpad.net/ubuntu/+source/dcraw/+bug/86480

This is want mean than in Debian like distro (ubuntu, kubuntu, etc..) dcraw
will be never updated to more than 8.60 release. This is the main problem.
Idem for UFRAW and other raw decoding tool based on dcraw.c code ! This
problem is very IMPORTANT to solve for the future...

What do you think about ? Dave any news to solve this license problem ?

Gilles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20070404/a09f861d/attachment.html>


More information about the Digikam-devel mailing list