About dcraw, libufraw, libopenraw and libkdcraw

Dear people,

first of all I'm sorry for write you with also cc to some
list. I will try to 
be brief. I'm an advocate of the free software and usually I
use kde and 
debian. I'm a enthusiast of the photography and I normally
shot in raw with 
my camera.

It's to me a bit surprising (but understandable) that almost
_all_ the free 
software projects use the dcraw from Mr. Coffin. However,
Mr. Coffin doesn't 
want to make dcraw as a library. In general, all the
projects modify the 
dcraw code or encapsulate it in some kind of library.

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. 
However, maybe it's the most easy thing, do it your self
from zero.

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. 

I don't use digikam but I like very much this application.
Also, I like the qt 
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.

After this introduction I would like to ask you if it would
be possible that 
_all_ of you will try to collaborate as possible as you can.
For example, I 
respect very much the ideas of Mr. Coffin, but:

- what do you think if the other people send you little
modifications of the 
dcraw in the manner to help it to integrate in a library? (I
have in mind the 
little  modification that the libkdcraw have to do obtain
the model and 
camera

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

- Mr. Fuchs, what do you think to begin to modify ufraw in a
way that use  
this possible library or another in common?

- Mr. Figuière what do you think about to make libopenraw
in a similar way or 
compatible, or whatever?

I think that it could be more interesting to have some kind
of libraw (the 
idea of libopenraw), with all the features that have ufraw,
easily integrated 
in kde and gnome, probably pure c++, or minor dependencies
(exif ...) and 
multi-platform  with also some kind of public xml (as ufraw
file format) to 
convert (adjust) any raw to something desirable, based in
dcraw than having: 
dcraw + libopenraw + ufraw (libufraw) + libkdcraw?

Please think about it.

Best regards,

Leo

-- 
--
Linux User 152692
PGP: 0xF944807E
Catalonia

_______________________________________________
Kde-imaging mailing list
Kde-imagingkde.org
htt
ps://mail.kde.org/mailman/listinfo/kde-imaging

A Dilluns 02 Abril 2007 19:16, Gilles Caulier va escriure:
> 2007/4/2, Leopold Palomo Avellaneda <lepalomwol.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

_______________________________________________
Kde-imaging mailing list
Kde-imagingkde.org
htt
ps://mail.kde.org/mailman/listinfo/kde-imaging

A Dimecres 04 Abril 2007 11:09, Gilles Caulier va escriure:
> 2007/4/3, Leopold Palomo Avellaneda <lepalomwol.es>:
> > A Dilluns 02 Abril 2007 19:16, Gilles Caulier va
escriure:
> > > 2007/4/2, Leopold Palomo Avellaneda
<lepalomwol.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

_______________________________________________
Kde-imaging mailing list
Kde-imagingkde.org
htt
ps://mail.kde.org/mailman/listinfo/kde-imaging