About dcraw, libufraw, libopenraw and libkdcraw

[Leopold Palomo Avellaneda]

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

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Hi,
Alle 01:38, lunedì 2 aprile 2007, Leopold Palomo Avellaneda ha scritto:
> - 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
As far as I can say we're inside an open model, so any modifications are welcome,
and added if it's ok.
 
> - 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?

About that libkdcraw is  a sort of KDE/QT interface of dcraw. The real point is
to have a libdcraw or something like that (libufraw/libdcraw/libfoo-raw, etc).

I'm quite sure Gilles has already disccussed that time ago and, to meet our
(kipi & co./digikam) needs, he produced a libkdcraw based on dcraw code.

Regards,
        Angelo

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/4/2, Leopold Palomo Avellaneda <[hidden email]>:

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.

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

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
 

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. 

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.

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

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.

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?

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 ?
 

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

Regards

Gilles Caulier
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/4/2, Angelo Naselli <[hidden email]>:

Hi,
Alle 01:38, lunedì 2 aprile 2007, Leopold Palomo Avellaneda ha scritto:
> - 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
As far as I can say we're inside an open model, so any modifications are welcome,
and added if it's ok.

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

About that libkdcraw is  a sort of KDE/QT interface of dcraw. The real point is
to have a libdcraw or something like that (libufraw/libdcraw/libfoo-raw, etc).

This is exactly the real problem: dcraw is not available like a library.

I'm quite sure Gilles has already disccussed that time ago and, to meet our
(kipi & co./digikam) needs, he produced a libkdcraw based on dcraw code.

... And this is why libkdcraw have been created : to produce a KDE/QT  like C++ wrapper  around dcraw.

libkdcraw provide a dcraw binary program named kdcraw witch is an exact copy of dcraw (currently 8.60) fully tested with the C++ interface.

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Leopold Palomo Avellaneda]

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

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/4/3, Leopold Palomo Avellaneda <[hidden email]>:

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

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Leopold Palomo Avellaneda]

A Dimecres 04 Abril 2007 11:09, Gilles Caulier va escriure:
> 2007/4/3, Leopold Palomo Avellaneda <[hidden email]>:
> > A Dilluns 02 Abril 2007 19:16, Gilles Caulier va escriure:
> > > 2007/4/2, Leopold Palomo Avellaneda <[hidden email]>:
[....]

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

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel