В darktable собранном с 0.14.0 (в gentoo есть патч с которым можно собрать dt с системным libraw) на многих снимках вылазят цветные точки. Не знаю проблема это со стороны darktable или libraw.
LibRaw-Lite is no longer exists since version 0.9 or so.
There are:
- main LibRaw, distributed under triple licensing
- GPL2+ licensed sources (demosaic-pack-GPL2): Foveon support and some demosaic methods
- GPL3+ licensed sources: several demosaics plus noise reduction.
Depending on your application license, you may use only main LibRaw (if your application is not GPLed), LibRaw+GPL2 pack (for GPL2+ app), LibRaw+GPL2+GPL3 (for GPL3+ apps)
Would it be possible to get support for X3F files from the newer Sigma camera models? Code might be based on the X3F Tools found here: https://github.com/rolkar/x3f
I'm in the very same step, chaining Cam_xyz with xyz_srgb matrixes, but can't get the color right... What am I missing? Also, which coeficients do I have to use to do white balance?
I need to compile LibRaw as a .so (to use on Android) I'm going to try my hand at making these patches, but I have no idea what I'm doing. If you could provide some help, I'd very much appreciate it lexa! ;)
Thank you for your reply. Writing a simple program cannot reproduce the problem (four_color/half_size). So the error is somewhere in my own code. For the moment I cannot find it but I will.
Thanks again.
For -H 2 and -H 9 the results are bitwise the same for dcraw and dcraw_emu (from 0.13.5) and my sample image (something with blown clouds)
The difference may be in auto-maximum feature in LibRaw (very useful for some cameras). To turn this feature off use -c 0 switch when running dcraw_emu:
four_color_rgb value is saved in the beginning of dcraw_process() call, may be changed by half_size setting, but restored again at the end of dcraw_process(), just before return. (LibRaw 0.13.5)
Could you please provide sample code with errorneous four_color_rgb/half_size behaviour?
You're right, positive exposure shift without highlights compression will not affect entire image with default processing options, because data will be scaled to full 0..65535 range on postprocessing.
Anyway, positive exposure correcton is useful if
1) Manual data scaling is selected
2) Or highlights compression is non-zero.
Thank you for four_color/half_size report, I'll check.
Sorry for delayed answer, just returned from long vacation trip to Mongolia without any internet access....
According to configure output, your Xcode package is not installed correctly. The gcc is unable to compile small test program:
configure:2940: g++ conftest.cpp >&5
ld: library not found for -lcrt1.10.6.o
I've tested the configure script under 10.6.8 with Xcode 4.x without any minor problem. I've used Xcode 3.x several months ago without any problem too.
Iliah, You say "It looks like the time spent in postprocessing to get more details and counter-act artifacts might be better spent if demosaicking prepares a cleaner and more detailed image to start with. The processing time difference between integer and floating point implementations of demosaicking most of the times is less than 5 seconds, which is substantially less compared to the time spent on image editing to get close to the same result. Try it, and you will see. "
How does one go about "trying it" to see? What about this comment:
"For float data output we need to change entire processing pipeline to floating point." from http://www.libraw.org/about?
The problem is very simple:
- you have set half_size=1 *after* unpack is called. So for the very first run the half_size is not set for unpack stage but set for postprocessing stage.
But half_size option is heavily used on unpack() stage (only 1/4 of image array allocated, pixel data placement is very different).
You need to move
rawProcessor_.imgdata.params.half_size = 1;
line above of unpack() call.
В darktable собранном с 0.14.0 (в gentoo есть патч с которым можно собрать dt с системным libraw) на многих снимках вылазят цветные точки. Не знаю проблема это со стороны darktable или libraw.
LibRaw-Lite is no longer exists since version 0.9 or so.
There are:
- main LibRaw, distributed under triple licensing
- GPL2+ licensed sources (demosaic-pack-GPL2): Foveon support and some demosaic methods
- GPL3+ licensed sources: several demosaics plus noise reduction.
Depending on your application license, you may use only main LibRaw (if your application is not GPLed), LibRaw+GPL2 pack (for GPL2+ app), LibRaw+GPL2+GPL3 (for GPL3+ apps)
Would it be possible to get support for X3F files from the newer Sigma camera models? Code might be based on the X3F Tools found here: https://github.com/rolkar/x3f
Regards,
Niels Kristian Bech Jensen
I'm in the very same step, chaining Cam_xyz with xyz_srgb matrixes, but can't get the color right... What am I missing? Also, which coeficients do I have to use to do white balance?
Thanks in advance.
ntohs is in libws2_32 library, so you need to add this lib to your linker command line.
libraw.so (generic), and so.2 (generic version 2) should be symlinks to so.2.0.5 (exact version).
You need to specify -lraw to linker command line and linker will do all magic.
Got this to work, cross compiling for android. So I want libraw.so.2? I have libraw.a, libraw.so, libraw.so.2, libraw.so.2.0.5 (all exact same size)
Pentax K5 images works fine since LibRaw 0.11.2 released on November 11, 2010.
Starting with version 0.13.2, LibRaw supports shared libraries.
Just use ./configure (then make && make install) and you'll get libraw.so.2 in your /usr/local/lib
I need to compile LibRaw as a .so (to use on Android) I'm going to try my hand at making these patches, but I have no idea what I'm doing. If you could provide some help, I'd very much appreciate it lexa! ;)
Thank you for your reply. Writing a simple program cannot reproduce the problem (four_color/half_size). So the error is somewhere in my own code. For the moment I cannot find it but I will.
Thanks again.
For -H 2 and -H 9 the results are bitwise the same for dcraw and dcraw_emu (from 0.13.5) and my sample image (something with blown clouds)
The difference may be in auto-maximum feature in LibRaw (very useful for some cameras). To turn this feature off use -c 0 switch when running dcraw_emu:
dcraw_emu -c 0 -H 2
Unfortunately, I'm unable to download your sample, file not found.
four_color_rgb value is saved in the beginning of dcraw_process() call, may be changed by half_size setting, but restored again at the end of dcraw_process(), just before return. (LibRaw 0.13.5)
Could you please provide sample code with errorneous four_color_rgb/half_size behaviour?
You're right, positive exposure shift without highlights compression will not affect entire image with default processing options, because data will be scaled to full 0..65535 range on postprocessing.
Anyway, positive exposure correcton is useful if
1) Manual data scaling is selected
2) Or highlights compression is non-zero.
Thank you for four_color/half_size report, I'll check.
Sorry for delayed answer, just returned from long vacation trip to Mongolia without any internet access....
Thanks for report, to be tested.
Sorry for delayed answer, summer is vacation time.
According to configure output, your Xcode package is not installed correctly. The gcc is unable to compile small test program:
configure:2940: g++ conftest.cpp >&5
ld: library not found for -lcrt1.10.6.o
I've tested the configure script under 10.6.8 with Xcode 4.x without any minor problem. I've used Xcode 3.x several months ago without any problem too.
Well, those comments are for raw converter developers.
Where is the floating point implementation?
Elle Stone
Iliah, You say "It looks like the time spent in postprocessing to get more details and counter-act artifacts might be better spent if demosaicking prepares a cleaner and more detailed image to start with. The processing time difference between integer and floating point implementations of demosaicking most of the times is less than 5 seconds, which is substantially less compared to the time spent on image editing to get close to the same result. Try it, and you will see. "
How does one go about "trying it" to see? What about this comment:
"For float data output we need to change entire processing pipeline to floating point." from http://www.libraw.org/about?
Elle Stone
The data scaling is performed before interpolation.
So, there is no way to get debayered and unscaled data. You may remove call to scale colors or rewrite this call (LibRaw::scale_colors) if you wish.
Take a look at the method "LoadRawImage" at https://valelab.ucsf.edu/svn/micromanager2/trunk/DeviceAdapters/Tethered... )
Perfect, everything works. Thank you!
The problem is very simple:
- you have set half_size=1 *after* unpack is called. So for the very first run the half_size is not set for unpack stage but set for postprocessing stage.
But half_size option is heavily used on unpack() stage (only 1/4 of image array allocated, pixel data placement is very different).
You need to move
rawProcessor_.imgdata.params.half_size = 1;
line above of unpack() call.
The case is confirmed, your code really produces different first image (have not looked into it, but see by different MD5 sums).
Thanks again for your bug report. I'll write another comment here when bug will be fixed
Pages