dlRaw - First Beta release
Jon Smid
Today dlRaw has reached a stage where it can be considered beta.
dlRaw is a feature rich , open-source, free raw convertor.
Besides the usual dcraw functionality it does include :
- color management using lcms
- lensfun corrections
- Crop/Resize/Rotate
- Curves in RGB and Lab.
- Refocus and USM sharpening in Lab.
- Contrast and Saturation control in Lab.
- Several stages of noise reduction.
- Greycstoration noise reduction.
- Output generation in jpeg and ppm.
A source package for linux is available as well as building instructions
for windows (and a simple windows package).
All feedback is welcome.
Floyd L. Davidson
>Dear,
>
>Today dlRaw has reached a stage where it can be considered beta.
>dlRaw is a feature rich , open-source, free raw convertor.
>A source package for linux is available as well as building instructions
>for windows (and a simple windows package).
>All feedback is welcome.
>
>See : http://dlraw.sourceforge.net
I downloaded the package... but it is incomplete. There are no
instructions for compiling. Indeed, there is no configuration
at all, and no Makefile either.
The file layout was amusing too... :-)
--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) fl...@apaflo.com
ray
Perhaps you could explain the advantages of this package over ufraw?
Jon Smid
> Jon Smid <Varke...@hotmail.com> wrote:
>> Dear,
>>
>> Today dlRaw has reached a stage where it can be considered beta.
>> dlRaw is a feature rich , open-source, free raw convertor.
> ...
>> A source package for linux is available as well as building instructions
>> for windows (and a simple windows package).
>> All feedback is welcome.
>>
>> See : http://dlraw.sourceforge.net
>
> I downloaded the package... but it is incomplete. There are no
> instructions for compiling. Indeed, there is no configuration
> at all, and no Makefile either.
>
> The file layout was amusing too... :-)
>
Jon Smid
- Refocus sharpen
- USM sharpen
- Luminance & Color noise reduction
- Greycstoration
- Highlights , although this will always be subject to debate.
Many things will be probably poorer to.
Alternatives, you know ...
Jon Smid
- Refocus sharpen
Paul Furman
> Jon Smid <Varke...@hotmail.com> wrote:
>> ...building instructions
>> for windows (and a simple windows package).
Most Windows people need a simple install. The word 'build' does not
have meaning to windows users, it should be a file named dlRaw_setup.exe
or people won't have the slightest clue how to proceed.
Alex Monro
> Dear,
>
> Today dlRaw has reached a stage where it can be considered beta.
> dlRaw is a feature rich , open-source, free raw convertor.
>
Looks interesting - rather more comprehensive processing (lens
corrections etc.) at the conversion stage in 16 bit than UFraw. I'll
probably give it a try when I've got the time & disk space to build
it! :)
--
Alex Monro
Exeter, UK
Running on Linux (Kubuntu 7.1)
Jon Smid
> Jon Smid <Varke...@hotmail.com> wrote:
>> Dear,
>>
>> Today dlRaw has reached a stage where it can be considered beta.
>> dlRaw is a feature rich , open-source, free raw convertor.
> ...
>> A source package for linux is available as well as building instructions
>> for windows (and a simple windows package).
>> All feedback is welcome.
>>
>> See : http://dlraw.sourceforge.net
>
> I downloaded the package... but it is incomplete. There are no
> instructions for compiling. Indeed, there is no configuration
> at all, and no Makefile either.
>
> The file layout was amusing too... :-)
By the way : what do you mean with 'amusing' ? I'm not sure what you mean.
>
Floyd L. Davidson
>> I downloaded the package... but it is incomplete.
>> There are no
>> instructions for compiling. Indeed, there is no configuration
>> at all, and no Makefile either.
>> The file layout was amusing too... :-)
>
>By the way : what do you mean with 'amusing' ? I'm not sure what you mean.
Non-standard. (I'm an old Unix weenie.)
I haven't had time to really get into what is going on
yet, but I've made at least some effort to install it on
a Slackware based system (it's not an out of the box
Slackware though, but right now there isn't a great deal
of difference). I compile, and occasionally diddle with
the source code, for the development versions of both
UFRAW and GIMP, so all of the libraries they depend on
are generally at the latest revision. But I'm a C
person, and don't grok C++ at all, so that's a serious
impediment too.
Right now what I'm getting is an error like this:
/usr/local/qt/bin/uic ../Sources/dlMainWindow.ui -o ../Objects/dlMainWindow.h
make[1]: /usr/local/qt/bin/uic: Command not found
I had qt-3.3, so I went out and downloaded qt-4.4. The
make and install apparently went okay, as there were no
errors, but it didn't solve the problem. However, qt is
not installed on /usr/local, and uic is located in /usr/bin.
But I have't figured out where the above path is coming from,
because it is not showing up in anything when I grep for it
in the dlraw directories. It must be wired into things
via some configuration file somewhere, but so far it has
escaped me... :-)
Note that I use a very complexly configured fvwm2, and
do not run either KDE or GNOME. I'm not particularly
familiar with qmake either, so the mechanism for
generating a Makefile is not obvious to me.
I'll keep poking away at it as time permits, because I
really do want to see what you've got.
Jon Smid
> Jon Smid <Varke...@hotmail.com> wrote:
>>> I downloaded the package... but it is incomplete.
>>> There are no
>>> instructions for compiling. Indeed, there is no configuration
>>> at all, and no Makefile either.
>>> The file layout was amusing too... :-)
>> By the way : what do you mean with 'amusing' ? I'm not sure what you mean.
>
> Non-standard. (I'm an old Unix weenie.)
>
> I haven't had time to really get into what is going on
> yet, but I've made at least some effort to install it on
> a Slackware based system (it's not an out of the box
> Slackware though, but right now there isn't a great deal
> of difference). I compile, and occasionally diddle with
> the source code, for the development versions of both
> UFRAW and GIMP, so all of the libraries they depend on
> are generally at the latest revision. But I'm a C
> person, and don't grok C++ at all, so that's a serious
> impediment too.
>
> Right now what I'm getting is an error like this:
>
> /usr/local/qt/bin/uic ../Sources/dlMainWindow.ui -o ../Objects/dlMainWindow.h
> make[1]: /usr/local/qt/bin/uic: Command not found
For reference, my qt, very recently compiled and installed on an ubuntu
box :
/usr/local/Trolltech/Qt-4.4.3/bin/uic ../Sources/dlMainWindow.ui -o
../Objects/ui_dlMainWindow.h
Just for your reference.
>
> I had qt-3.3, so I went out and downloaded qt-4.4. The
> make and install apparently went okay, as there were no
> errors, but it didn't solve the problem. However, qt is
> not installed on /usr/local, and uic is located in /usr/bin.
> But I have't figured out where the above path is coming from,
> because it is not showing up in anything when I grep for it
> in the dlraw directories. It must be wired into things
> via some configuration file somewhere, but so far it has
> escaped me... :-)
>
> Note that I use a very complexly configured fvwm2, and
> do not run either KDE or GNOME. I'm not particularly
> familiar with qmake either, so the mechanism for
> generating a Makefile is not obvious to me.
As described on the webpage, qmake followed by make should do it ...
(provided a 4.4.3 Qt installation)
There are no dependencies to KDE or GNOME per se.
It does use qt and glib though. (yes both : glib for the lensfun function)
Floyd L. Davidson
Well, mine is were it actually should be (because it is
part of the Slackware distribution), at /usr/bin/uic. I
copied it to /usr/local/qt/bin and that worked.
However...
Past that there were repeated problems with finding the
included headers for qt. I copied half a dozen or more
to the Sources directory because they were all included
with
#include "filename"
and that allowed things to work. But I gave up because
one source file alone included half a dozen headers that
were not being found, some of which have names that
exist in multiple directories, and it appeared that I
might be doing that for an hour just to find that
picking the wrong one at any point along the way would
probably result in compiling a program that would crash
or be non-functional.
That's just more effort than I'm willing to exert...
>> I had qt-3.3, so I went out and downloaded qt-4.4. The
>> make and install apparently went okay, as there were no
>> errors, but it didn't solve the problem. However, qt is
>> not installed on /usr/local, and uic is located in /usr/bin.
>> But I have't figured out where the above path is coming from,
>> because it is not showing up in anything when I grep for it
>> in the dlraw directories. It must be wired into things
>> via some configuration file somewhere, but so far it has
>> escaped me... :-)
>> Note that I use a very complexly configured fvwm2, and
>> do not run either KDE or GNOME. I'm not particularly
>> familiar with qmake either, so the mechanism for
>> generating a Makefile is not obvious to me.
>
>As described on the webpage, qmake followed by make should do it ...
>(provided a 4.4.3 Qt installation)
And that is exactly what I do have, but no it doesn't come
close. It's fairly obvious that some of the included files
should have been #include <filename>, but it still isn't
able to find all of them.
>There are no dependencies to KDE or GNOME per se.
>It does use qt and glib though. (yes both : glib for the lensfun function)
Obviously I use glib for other progs too. :-) I keep
gimp 2.4 and gimp 2.6 source code and binaries
available, just so that I can check to see what others
are experiencing when they ask questions. That is in
addition to the latest gimp 2.7 that I upgrade to about
once a week.
Jon Smid
It still looks to me that you have a qt installation problem.
Can you actually compile (qmake) the 'hello world' equivalent in Qt ?
What might help too in case previous runs messed it up :
cd dlRawProject
qmake
cd ..
qmake
make
(and make sure there is no mess up between qmake from older and newer
versions).
This is just too far away from any problem I heard before.
Jon Smid
>
> It still looks to me that you have a qt installation problem.
> Can you actually compile (qmake) the 'hello world' equivalent in Qt ?
>
> What might help too in case previous runs messed it up :
> cd dlRawProject
> qmake
> cd ..
> qmake
> make
>
> (and make sure there is no mess up between qmake from older and newer
> versions).
>
> This is just too far away from any problem I heard before.
Actually, after a night of sleep, my best guess is that you used the
'wrong' qmake after all. (the older version that pulls in some older paths).
Can you try and run qmake with an absolute path to rule out that ?
By the way , I'm not sure what's your story about includes in the source
directory. All QStuff is included correctly via #include <QFoo>.
Floyd L. Davidson
>It still looks to me that you have a qt installation problem.
>Can you actually compile (qmake) the 'hello world' equivalent in Qt ?
Donno.
>What might help too in case previous runs messed it up :
>cd dlRawProject
>qmake
>cd ..
>qmake
>make
Well, that was interesting... In dlRawProject it can
find /usr/bin/uic. Which sugggests that particular
problem is a simple case of qmake can't clean up after
itself properly when there is a configuration change, so
I just deleted the entire distribution directory tree
and recreated it from the downloaded tgz. That problem
went away. (That does not bode well though, as I would
normally want to compile programs like this on multiple
platforms using the same disk files mounted nfs.)
And unfortunately that just advanced to the next
problem:
g++ -c -pipe -O2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include \
-O3 -ffast-math -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB \
-DQT_CORE_LIB -DQT_SHARED -I/usr/mkspecs/linux-g++ -I. \
-I/usr/include/QtCore -I/usr/include/QtCore -I/usr/include/QtGui \
-I/usr/include/QtGui -I/usr/include -I../Objects -I../Objects
-o ../Objects/dlMain.o ../Sources/dlMain.cpp
../Sources/dlMain.cpp: In function 'void ReadExifBuffer()':
../Sources/dlMain.cpp:1255: error: \
'class Exiv2::ExifData' has no member named 'copy'
../Sources/dlMain.cpp:1265: error: \
'class Exiv2::ExifData' has no member named 'copy'
../Sources/dlMain.cpp:1269: error: \
'class Exiv2::ExifData' has no member named 'eraseThumbnail'
../Sources/dlMain.cpp:1272: error: \
'class Exiv2::ExifData' has no member named 'copy'
I have the latest version of exiv2, and it works well
when other programs use it. The odd thing in the above
is that there is no indication that it can't find a
header file or the library. As I said, I'm not a C++
programmer, but the syntax etc looks right, and the
indication I get is that it does find some of the
prototypes related to exiv.
The Royal Spam
I drive to jobs, my car has a double overhead camshaft fuel injected engine
with a displacement of 1995cc. It needs servicing sometimes because I am not
interested in looking under the bonnet. I am also not interested in
non-photography related programming code. This group is called
alt.photography
Floyd L. Davidson
>I am also not interested in
>non-photography related programming code. This group is called
>alt.photography
Then you most certainly, if the above is true, have been
facinated by this discussion so far. If you don't know,
on the other hand, what a raw converter is, what qt is
or what Exif is... then you have either made a
misstatement above or you have a lot of catching up to
do in the world of photography related programming.
Note that it is alt.photography, and isn't meant to be
alt.photography_only_at_the_level_a_royal_spam_understands.
Jon Smid
> Jon Smid <Varke...@hotmail.com> wrote:
>> It still looks to me that you have a qt installation problem.
>> Can you actually compile (qmake) the 'hello world' equivalent in Qt ?
>
> Donno.
>
>> What might help too in case previous runs messed it up :
>> cd dlRawProject
>> qmake
>> cd ..
>> qmake
>> make
>
> Well, that was interesting... In dlRawProject it can
> find /usr/bin/uic. Which sugggests that particular
> problem is a simple case of qmake can't clean up after
> itself properly when there is a configuration change, so
Well, that's debateable, as it most likely was induced by using two
qmake versions in a mixed way. But I would agree with you this needs to
be more robust. Someone is working on that, I understood.
This is a known issue meanwhile. Apparently later (0.18) versions of
exiv2 are not compatible with earlier versions (that I used). Methods
that were available pre 0.18 are not in 0.18. I'll release a patch soon
for that.
Jon Smid
A version patched for the exiv2 issue is available at the site.
Floyd L. Davidson
>Floyd L. Davidson schreef:
>> Jon Smid <Varke...@hotmail.com> wrote:
>>> It still looks to me that you have a qt installation problem.
>>> Can you actually compile (qmake) the 'hello world' equivalent in Qt ?
>> Donno.
>>
>>> What might help too in case previous runs messed it up :
>>> cd dlRawProject
>>> qmake
>>> cd ..
>>> qmake
>>> make
>> Well, that was interesting... In dlRawProject it can
>> find /usr/bin/uic. Which sugggests that particular
>> problem is a simple case of qmake can't clean up after
>> itself properly when there is a configuration change, so
>
>Well, that's debateable, as it most likely was induced by using two
>qmake versions in a mixed way. But I would agree with you this needs to
>be more robust. Someone is working on that, I understood.
Not debateable. I ran the older version and determined
that I need a newer version. I then installed a new
version of qmake, and it failed to configure it
properly. I do exactly the same thing with other
configuration programs on a regular basis. It is
absolutely *essential* that there be a way, short of
re-installing the software the way I had to to, to do a
complete baseline reconfiguration.
>> I just deleted the entire distribution directory tree
>> and recreated it from the downloaded tgz. That problem
>> went away. (That does not bode well though, as I would
>> normally want to compile programs like this on multiple
>> platforms using the same disk files mounted nfs.)
That is a typical example of why the above is valid.
I have 5 computers here, each slightly different, that
will be using most of the photography related software
that I have. The source code is only physically on two
of them, and actual development is only done on one.
When it is ready for "distribution" to the others, I
simply nfs mount that filesystem and compile it using
the target system. If the package's development tools
do what qmake did, it simply won't work.
>> I have the latest version of exiv2, and it works well
>> when other programs use it. The odd thing in the above
>> is that there is no indication that it can't find a
>> header file or the library. As I said, I'm not a C++
>> programmer, but the syntax etc looks right, and the
>> indication I get is that it does find some of the
>> prototypes related to exiv.
>>
>
>This is a known issue meanwhile. Apparently later (0.18) versions of
>exiv2 are not compatible with earlier versions (that I used). Methods
>that were available pre 0.18 are not in 0.18. I'll release a patch soon
>for that.
Okay. I'll back out to 0.17 and give it a try that way.
You need to have a configuration tool that detects
version issues and kicks out complaints. The GNU tools
(autoconf et al) do that fairly well, though it is an
excessively complex mechanism to learn and use.
Jon Smid
<snip>
>
> Not debateable. I ran the older version and determined
> that I need a newer version. I then installed a new
> version of qmake, and it failed to configure it
> properly. I do exactly the same thing with other
> configuration programs on a regular basis. It is
> absolutely *essential* that there be a way, short of
> re-installing the software the way I had to to, to do a
> complete baseline reconfiguration.
Looking in hindsight : make distclean should have done the job.
<snip>
>
> Okay. I'll back out to 0.17 and give it a try that way.
You can save yourself the effort. The patched version is available
already. (for j.f. : that's called support in OSS world ;))
>
> You need to have a configuration tool that detects
> version issues and kicks out complaints. The GNU tools
> (autoconf et al) do that fairly well, though it is an
> excessively complex mechanism to learn and use.
>
Another project member is working on that. It will be cmake based though.
Floyd L. Davidson
>A version patched for the exiv2 issue is available at the site.
I linked to libexiv2 version 0.17 and that worked. I also had
to embed #include <jpeglib.h> like this
extern "C" {
#include <libjpeg.h>
}
And then it compiled!
Of course that's where the real problems start! :-)
The major items are that it will not execute except in
the directory where it is compiled! It looks there for
the dlCreateAdobeProfilesProject and LensFunDatabase
directories. Those need to be put into stardard places.
Icc profiles generally go into /usr/share/color/icc, and
the lensfun database would be either /usr/share/lensfun
or /usr/local/share/lensfun. Both /usr and /usr/local
need to be checked in either case.
Of course it is just barely past alpha software, so I'm
not going to give you a list of all the obvious
problems...
It segfaulted on me twice, once the first time I loaded
an NEF file (it loaded the next one fine though), and
then again when I tried to write the output to a JPEG
file.
Right now you have only JPEG and PPM output options.
Note that PPM does not support Exif data, and if for no
other reason a TIFF output format should be available.
It isn't Xinerama aware. The initial display of the
image was not very high, but extended across the screen
and onto the 2nd monitor. It of course eventually needs
to size the image window depending on the size of the
display window, taking into account that it might be
spread across multiple monitors.
I didn't see a blink on over/under exposure display
option.
It needs to remember various configuration settings
between invocations too. And it needs to be able to
work in a non-interactive batch mode.
A number of things simply don't work yet.
It's still just way to crude to suggest anyone actually
use it, but certainly it has a lot of potential.
Jon Smid
> Jon Smid <Varke...@hotmail.com> wrote:
>> A version patched for the exiv2 issue is available at the site.
>
> I linked to libexiv2 version 0.17 and that worked. I also had
> to embed #include <jpeglib.h> like this
>
> extern "C" {
> #include <libjpeg.h>
> }
>
> And then it compiled!
>
> Of course that's where the real problems start! :-)
>
:)
> The major items are that it will not execute except in
> the directory where it is compiled! It looks there for
> the dlCreateAdobeProfilesProject and LensFunDatabase
> directories. Those need to be put into stardard places.
> Icc profiles generally go into /usr/share/color/icc, and
> the lensfun database would be either /usr/share/lensfun
> or /usr/local/share/lensfun. Both /usr and /usr/local
> need to be checked in either case.
>
Yes. Correct. That's on the todo.
> Of course it is just barely past alpha software, so I'm
> not going to give you a list of all the obvious
> problems...
>
> It segfaulted on me twice, once the first time I loaded
> an NEF file (it loaded the next one fine though), and
> then again when I tried to write the output to a JPEG
> file.
Are you able to share the NEF file ?
Is it on any JPEG or a specific JPEG ?
>
> Right now you have only JPEG and PPM output options.
> Note that PPM does not support Exif data, and if for no
> other reason a TIFF output format should be available.
Yes. Agreed. That's for sure on the todo.
>
> It isn't Xinerama aware. The initial display of the
> image was not very high, but extended across the screen
> and onto the 2nd monitor. It of course eventually needs
> to size the image window depending on the size of the
> display window, taking into account that it might be
> spread across multiple monitors.
Dunno. No knowledge on that. I'll try and find out later.
>
> I didn't see a blink on over/under exposure display
> option.
Would be interesting indeed.
>
> It needs to remember various configuration settings
> between invocations too. And it needs to be able to
> work in a non-interactive batch mode.
Remembering configuration settings : on the todo.
Batch mode is there : dlRaw -j JobFile (where JobFile can be created by
the Gui)
>
> A number of things simply don't work yet.
>
> It's still just way to crude to suggest anyone actually
> use it, but certainly it has a lot of potential.
>
Early Beta indeed. But I really appreciate your feedback.
I think most of it can be addressed in a matter of some weeks.
Floyd L. Davidson
>Floyd L. Davidson schreef:
>> Jon Smid <Varke...@hotmail.com> wrote:
>>> A version patched for the exiv2 issue is available at the site.
>> I linked to libexiv2 version 0.17 and that worked. I
>> also had
>> to embed #include <jpeglib.h> like this
>> extern "C" {
>> #include <libjpeg.h>
>> }
>Where did you need that ?
In *every* file that includes libjpeg.h!
>> It segfaulted on me twice, once the first time I loaded
>> an NEF file (it loaded the next one fine though), and
>> then again when I tried to write the output to a JPEG
>> file.
>
>Are you able to share the NEF file ?
>Is it on any JPEG or a specific JPEG ?
Well, it didn't segfault when I tried the second time to load
an NEF, and I didn't try writing again. I'll have to figure
out how to compile it with symbols and then run it with gdb
a few times and see where it dumps at. Maybe tomorrow...
>> It isn't Xinerama aware. The initial display of the
>> image was not very high, but extended across the screen
>> and onto the 2nd monitor. It of course eventually needs
>> to size the image window depending on the size of the
>> display window, taking into account that it might be
>> spread across multiple monitors.
>
>Dunno. No knowledge on that. I'll try and find out later.
It's the X extension for using multiple monitors. Just
about everything these days is aware.
>> I didn't see a blink on over/under exposure display
>> option.
>
>Would be interesting indeed.
Absolutely the best way to set "exposure"!
>Batch mode is there : dlRaw -j JobFile (where JobFile can be created by
>the Gui)
Ah! I missed that.
>Early Beta indeed. But I really appreciate your feedback.
>I think most of it can be addressed in a matter of some weeks.
Well, I'm glad to help. It is just impossible for one
guy to realize all the strange other things out there...
so the only way is just what you've done, let people
play with it and cuss at you for not getting it right
the first time!
A few months from now, when you've polished the shiney
version, that is going to be interesting!
Jon Smid
> Jon Smid <Varke...@hotmail.com> wrote:
>> Floyd L. Davidson schreef:
>>> Jon Smid <Varke...@hotmail.com> wrote:
>>>> A version patched for the exiv2 issue is available at the site.
>>> I linked to libexiv2 version 0.17 and that worked. I
>>> also had
>>> to embed #include <jpeglib.h> like this
>>> extern "C" {
>>> #include <libjpeg.h>
>>> }
>> Where did you need that ?
>
> In *every* file that includes libjpeg.h!
>
This is puzzling me ...
I , for instance, do not have a libjpeg.h at all ! (and googling around
I'm not unique in that respect). I do have however jpeglib.h and that's
containing
#ifdef __cplusplus
extern "C" {
#endif
near the top.
So I'm wondering what's going on ... Does one of us have a drastically
different jpeg library and if so, is it a version issue or is it just
another library ?
Thanks for all your feedback so far by the way !
Do you mind me following up in private mails ?