<br><br><div><span class="gmail_quote">2007/4/3, Leopold Palomo Avellaneda <<a href="mailto:lepalom@wol.es" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">lepalom@wol.es</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

A Dilluns 02 Abril 2007 19:16, Gilles Caulier va escriure:<br>> 2007/4/2, Leopold Palomo Avellaneda <<a href="mailto:lepalom@wol.es" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">lepalom@wol.es

</a>>:<br>[....]<br>><br>> We need a library, not a simple binary program to decode RAW files. This is

<br>> why there are a lots of projects witch re-implemente/re-use dcraw.c from<br>> Dave<br><br>well, I think that there are a more complex needed in this. ...<br><br><br>> >I like the ideas from Mr. Figuière to develop a library to use in the free

<br>> > software projects for the raw. But, to begin a new library from scratch,<br>> > (or<br>> > I understand that it have been developed in this manner) is a lot of<br>> > work.<br>><br>> Exact. This is why i think this project will never out, or perhaps in a far

<br>> far future...<br>><br>><br>> However, maybe it's the most easy thing, do it your self from zero.<br>><br>><br>> no. RAW file decoding is a science of reverse engineering. Dave have used<br>

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

<br>><br>> > I<br>> > like very much Mr. Fuchs application and I think that he have designed<br>> > and developed a very good application to convert raw files. Also, I think<br>> > that the idea to have some kind of job ticket, or convert options that he

<br>> > propose<br>> > in the ufraw xml file it's a very good idea.<br>> ><br>> > I proposed to Mr. Fuchs to try to make the ufraw file description (xml)<br>> > 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?

</blockquote><div><br>why not. But i need to study indeep how UFRAW work exactly...<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

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

<br>><br>> libkdcraw provide and interface for KDE applications. This implementation<br>> come from digiKam core and will be used by digiKam 0.9.2 and kipi-plugins<br>> 0.1.4. In the future, Krita will use it when libkdcraw will be ported to

<br>> QT4/KDE4. I'm sure than KDE KIO slave will use it later...<br><br>ok, interesting.<br><br>> The implementation provide an C++ interafce witch use QT and KDE component<br>> to run. Also, libkdcraw provide a QT/KDE settings widget used by hosts

<br>> application to set RAW decoding parameters.<br>><br>> There is no plan to remove the KDE/Qt. This is a non sence. If a low level<br>> library need to be done, libkdcraw is not the good way.<br>><br>[....]

<br>> > dcraw in the manner to help it to integrate in a library?<br>><br>> This is must be done in a low level library... like an ufraw-lib for<br>> example. This will be easy to fix libkdcraw to support ufraw shared lib

<br>> instead dcraw.c.<br>><br>><br>> (I have in mind the<br>><br>> > little  modification that the libkdcraw have to do obtain the model and<br>> > camera<br>><br>> Already done in libkdcraw, plus others stuff... (:=)))... Are you already

<br>> used digiKam ?<br><br>when the manner to manage raw files change .....</blockquote><div><br>because in digiKam we use Color Management every where.<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

><br>> - Mr. Wiesweg and Mr. Caulier (digikam) what do you think to modify<br>><br>> > libkdcraw<br>> > to avoid any dependency of qt or kde in the way that the gnome team<br>> > (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...

<br>><br>> Question : where is Dave Coffin job in this mail ? This is the main actor<br>> about RAW file format reverse-engineering ! If a low level shared lib is<br>> created for that, Dave is the better guy to do the core. Others developpers

<br>> can maintain and adapt the lib interface...<br><br>Well, I think that the problem or the situation is a bit more complex. Maybe<br>I'm wrong but I think that the ufraw do with the raw files is more<br>interesting that a simple conversion. To me the problem has four parts:

<br><br>1) from raw files from different vendors understand how is the information<br>stored (compressed/ encrypted/ etc) and obtain the data from the files<br><br>2) using this data, apply the adjust that you want as icc/icm, curves, noise

<br>reduction, mask ...<br><br>3) and then convert the data from 1, using the parameters from 2 using some<br>sophisticated method in 3<br><br>4) this result saves it in a tiff, jpeg, compressed, 16 bits, 8 bits, etc.<br>

<br>I think, (but I insist that maybe I'm wrong) that the interesting approach is<br>to set the parameters in 2) from  the original raw data because the result<br>will be better than apply the filters from the result in 4) in krita/gimp or

<br>whatever.</blockquote><div><br>Better... you want mean about White balance correction during decoding ?<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

dcraw do a very good job (the best one) in 1). Do good job in 2) (but using<br>ufraw, the result is better) and do a very good job in 3) and 4).<br><br>The idea of a libraw, or whatever, is taking the good part done in 1) by dcraw

<br>+ adding good part done in ufraw in 2) and 3) and encapsulate it in a library<br>in the way that could be used by gimp, krita, digikam or whatever. Not only a<br>wrap around dcraw as is done by libkdcraw.<br><br>Also, the idea of Mr. Fuchs about the ufraw files could complement the library

<br>in the manner that we could have the same (or very similar) results using the<br>program that we want, because we were using the same criteria (as a<br>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.</blockquote><div> The main question is  : Is UFRAW team is ready to provide the UFRAW core like a shared library ?

<br> </div>This is the first problem to solve...<br><br>The second one is the licence header used in dcraw.c > 8.60 witch is uncompatible with Debian & co dist. Look here :<br><br><a href="https://launchpad.net/ubuntu/+source/dcraw/+bug/86480">

https://launchpad.net/ubuntu/+source/dcraw/+bug/86480</a><br><br>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...<br><br>What do you think about ? Dave any news to solve this license problem ?<br><br></div>Gilles<br>