It seems to me that black and white isn't really an adequate test in this area. I'm thinking in terms of the poor buttercup yellow gradation many cameras can have due to the fact that it's a mix of the basic bayer colours. I get the impression at times that colour mixes including yellows for instance can cause a lack of sharpness.
Just use make -f Makefile.dist to build LibRaw. You may need to edit Makefile.dist to suit your needs.
./configure script is created by running autoreconf --install
It works fine on my FreeBSD test machine (autoconf 2.69 and automake 1.14), is your autoconf/automake stuff is fresh enough?
RawSpeed/development looks very unstable. For example, Nikon small-NEF support is definitely broken; multi-sample DNG support (Fuji SuperCCD dngs) is not compatible with LibRaw in data layout and many other things looks strange (e.g. 'unprocessed raw' concept without tone curve).
So, to use development RawSpeed with LibRaw it needs heavy make-up.
Just one more question:
Are you planning to include RAF support in rawspeed?
It would seem that only the development branch of Rawspeed is actually developing things at this moment...
LibRaw uses RawSpeed only for selected (tested) formats. Fuji RAF is not in this list yet, so you'll need to change more source code.
If you change the source, you can remove libxml2 from dependencies on your copy.
Yes, I could do that, but I really would like to use the updated rawspeed, with FUJIFILM X-trans support.
I already 'translated' camers.xml to the correct format.
Now I need to alter the code in "libraw_cxx.cpp" to use pugixml instead of libxml2 in order to load the (updated) "rawspeed_xmldata.cpp" into the 'CameraMetaData' class.
Could you perhaps point me into the right direction for that?
For desktop windows: use provided Visual Studio 2008 project files (and convert them to VS2013).
For windows phone: I do not know. Never used and/or developed for Windows Phone
Frontpage is outdated (it is funny :).
Actual licensing information is in actual libraw tar.gz/zip bundle and/or on documentation page.
Current versions are triple licensed, all three licenses (LGPL, CDDL, LibRaw) allows use in closed-source commercial (and non-commercial) apps.
Uhh, forgot to mention that by linking I mean linking to it's compiled file (libraw.dylib) which is going to be located in the program folder of the program and the application is going to be using the functions in the library :)
We discussed this in private communication.
use_auto_wb has priority over camera_wb. If it set, auto-wb will be used.
If auto_wb is unset, than as-shot wb will be used if use_camera_wb is non-zero, otherwise daylight wb is used.
Ahh. Yes, tons more I need to learn. Can you recommend a Libraw process to derive linear RGB and BW images from D7000 NEF? I'm looking for a "no-frills" kind of implementation if possible. The output is for a 3D structured light setup which is dependent on capturing a series of linear images.
Thanks again for your help!
Generally, you need to apply WB before demosaic (if your demosaic method use something like luminosity maps, the components should be balanced before).
Also, bias subtraction should be done before WB (and demosaic).
I do not think, that max(R,G,B) will give you good BW image. Better use something like RGB to Y[CC] or Lab conversion and use Y or L channel as BW image.
To follow up. If I demosaic, subtract black, scale with normalized multipliers(cam_mul), then do a max() of all three color components, I should generally have a linear black and white image, correct? Anything else I should consider or be concerned about?
If you want to use your own processing (demosaic), you need to
- subtract black (bias) level. It is zero for D7000, so if you working with only one camera, skip this step
- multiply to WB coeffs.
To not overflow ushort data, you need multipliers less than 4.0 (16-bit range and 14-bit data), so normalize the multipliers (divide to something) to fit range 0.0..4.0
This is not capture (camera) test, but demosaic test.
It seems to me that black and white isn't really an adequate test in this area. I'm thinking in terms of the poor buttercup yellow gradation many cameras can have due to the fact that it's a mix of the basic bayer colours. I get the impression at times that colour mixes including yellows for instance can cause a lack of sharpness.
You were right, my autoconf/automake stuff was not up to date.
I updated to autoconf 2.69 and automake 1.14, and now i get a working configure script from running
autoreconf --install
Thanks for your quick response, and have a nice day
Johann
Just use make -f Makefile.dist to build LibRaw. You may need to edit Makefile.dist to suit your needs.
./configure script is created by running autoreconf --install
It works fine on my FreeBSD test machine (autoconf 2.69 and automake 1.14), is your autoconf/automake stuff is fresh enough?
What happens if you use dcraw_emu sample with different -g parameters?
RawSpeed/development looks very unstable. For example, Nikon small-NEF support is definitely broken; multi-sample DNG support (Fuji SuperCCD dngs) is not compatible with LibRaw in data layout and many other things looks strange (e.g. 'unprocessed raw' concept without tone curve).
So, to use development RawSpeed with LibRaw it needs heavy make-up.
Thanks for the quick reply.
Just one more question:
Are you planning to include RAF support in rawspeed?
It would seem that only the development branch of Rawspeed is actually developing things at this moment...
Greetings,
Auke
LibRaw uses RawSpeed only for selected (tested) formats. Fuji RAF is not in this list yet, so you'll need to change more source code.
If you change the source, you can remove libxml2 from dependencies on your copy.
Hi,
Yes, I could do that, but I really would like to use the updated rawspeed, with FUJIFILM X-trans support.
I already 'translated' camers.xml to the correct format.
Now I need to alter the code in "libraw_cxx.cpp" to use pugixml instead of libxml2 in order to load the (updated) "rawspeed_xmldata.cpp" into the 'CameraMetaData' class.
Could you perhaps point me into the right direction for that?
Thanks and greetings,
Auke
Use RawSpeed from master branch, not from development (unstable) one.
LibRaw 0.16 does not supports A-6000.
Use master (development) branch from https://github.com/LibRaw/LibRaw
I've see your requests and replied on github.
I've no troubles when compiliing LibRaw by Xcode3 ... Xcode 6.1
For desktop windows: use provided Visual Studio 2008 project files (and convert them to VS2013).
For windows phone: I do not know. Never used and/or developed for Windows Phone
Please, how to make compile and run in visual studio 2013 and windows phone app?
I've answered already in another thread: http://www.libraw.org/comment/3725#comment-3725
If you use CDDL or LibRaw's own license, you may link as you wish, dynamic linking is not mandatory
Frontpage is outdated (it is funny :).
Actual licensing information is in actual libraw tar.gz/zip bundle and/or on documentation page.
Current versions are triple licensed, all three licenses (LGPL, CDDL, LibRaw) allows use in closed-source commercial (and non-commercial) apps.
Uhh, forgot to mention that by linking I mean linking to it's compiled file (libraw.dylib) which is going to be located in the program folder of the program and the application is going to be using the functions in the library :)
We discussed this in private communication.
use_auto_wb has priority over camera_wb. If it set, auto-wb will be used.
If auto_wb is unset, than as-shot wb will be used if use_camera_wb is non-zero, otherwise daylight wb is used.
Simple enough :)
Set output gamma to 1.0 and you'll get linear output.
Ahh. Yes, tons more I need to learn. Can you recommend a Libraw process to derive linear RGB and BW images from D7000 NEF? I'm looking for a "no-frills" kind of implementation if possible. The output is for a 3D structured light setup which is dependent on capturing a series of linear images.
Thanks again for your help!
Generally, you need to apply WB before demosaic (if your demosaic method use something like luminosity maps, the components should be balanced before).
Also, bias subtraction should be done before WB (and demosaic).
I do not think, that max(R,G,B) will give you good BW image. Better use something like RGB to Y[CC] or Lab conversion and use Y or L channel as BW image.
Great! Thanks!
To follow up. If I demosaic, subtract black, scale with normalized multipliers(cam_mul), then do a max() of all three color components, I should generally have a linear black and white image, correct? Anything else I should consider or be concerned about?
Thanks!
If you want to use your own processing (demosaic), you need to
- subtract black (bias) level. It is zero for D7000, so if you working with only one camera, skip this step
- multiply to WB coeffs.
To not overflow ushort data, you need multipliers less than 4.0 (16-bit range and 14-bit data), so normalize the multipliers (divide to something) to fit range 0.0..4.0
I am using the exifprobe version 2.0.1 . That is the one from the official Ubuntu 14.04 repository.
Program: 'exifprobe' version 2.0.1
Compiled: Tue Jun 15 23:17:15 UTC 2010
Copyright (C) 2005 Duane H. Hesser
Pages