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

Wed Apr 4 15:55:01 BST 2007

A Dimecres 04 Abril 2007 11:09, Gilles Caulier va escriure:
> 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>:
[....]
> > (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...

ok, please study it. Mr. Fuchs have done a very good job.

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

it's not that. Maybe now that I begin to shot in jpg +raw I will begin to use 
digikam, but it's another question, not for this thread.

[....]

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

well, to me decoding is to obtain the data from the raw file and the way how 
this data is used to have an image. From the pure data, then you can do 
everything you want. It's my opinion and I can be wrong.

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

I think that now no, but if we make some help (of course I'm making some 
propose and I have done nothing ...) it could be done in some time. Then, if 
this library is done, and there's some kind of propose of xml file to adjust 
the raw parameters for a conversion, the kde-imaging (krita, digikam, or 
whatever) and the gnome ...(ufraw, gimp...) will adopt this xml file and will 
use this library ?

> This is the first problem to solve...

sure.

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

well, I have read the license and I'm not an expert. I hope that the 
debian-legal team take care about it. Mr. Coffin _only_ says about the 
distribution of the source code (no, problem GPL means something similar)

> o license is required to download and use dcraw.c. However,
>     to lawfully redistribute this code, you must either (a) include
>     full source code* for all executable files containing RESTRICTED
>     functions, (b) remove all RESTRICTED functions, re-implement them,
>     or copy them from an earlier, unrestricted Revision of dcraw.c,
>     or (c) purchase a license from the author.
>    The functions that process Foveon images have been RESTRICTED
>     since Revision 1.237. All other code remains free for all uses.
>    *If you have not modified dcraw.c in any way, a link to my
>     homepage qualifies as "full source code".

the restricted functions is about the foevon sensors. You always can link, 
mention, distribute to the original dcraw code. 

Well, in this point I would like to hear other opinions. We have some kind of 
holiday period and I will try to study the ufraw code.

Best regards,

and thanks for your patience with this.

Leo

-- 
--
Linux User 152692
PGP: 0xF944807E
Catalonia
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20070404/750b13b8/attachment.sig>