[Kde-imaging] About dcraw, libufraw, libopenraw and libkdcraw

Tue Apr 3 01:21:50 CEST 2007

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?

[...]

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

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

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.

Best regards,

Leo

Pd. And of course, Mr Coffin is the main actor in this job, thanks to him,  
all the people of the free software world can use our photos in raw format.

-- 
--
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/kde-imaging/attachments/20070403/484e0274/attachment.pgp 