checking for jas_init in -ljasper... no
configure: WARNING: libjasper not found
./configure: line 12807: syntax error near unexpected token `ZLIB,zlib,'
./configure: line 12807: ` PKG_CHECK_MODULES(ZLIB,zlib,'
Your file has data corruption, so processing result may depend on how such corruption is handled in the calling code, please contact your library developers for details.
C-API is just a thin layer over C++ API, so no difference here.
Based on your source code (w/ built-in filename) I assume you use normal/unaltered bayer-pattern Sony-produced image.
For such images, decoded data is in libRaw->rawdata.raw_image
Dear sir or madam,
I am an enthusiastic user of all of your products. I use it for my Sony and Canon cameras successfully. I also Use a 360 VR Insta360 X3 and older One X2 cameras and I would be delighted if your package would support the RAW DNG files captured by these two cameras.
Best regards,
Frank Tornyai
No cameras produces floating-point data raw images (yet?), one may use (different) HDR-convertor software to create floating point images.
Regarding color3/color4:
- full-color images unpacked by LibRaw itself are (mostly) color4_image, you may use any full-color (not bayer) RAW file for that, for example Canon sRAW/mRAW CR2
- full-color images unpacked by 3rd-party decoders (Adobe DNG SDK, RawSpeed) are usually color3_image images. You may use the same sRAW/mRAW CR2 and RawSpeed decoder (via LibRaw)
Thanks I don't as yet have one, looking into what might be problems in getting one with Black Friday savings! I have been told as it uses DNG it should be OK though.
Libraw uses DNG SDK only for data decoding. Metadata decoding is performed by LibRaw's code.
So, if you do not provide ZLIB and/or JPEG support to LibRaw it will refuse ZLIB and/or JPEG compressed DNG files at parse stage.
Hi, I hope you're doing fine. Can you please add support for Xiaomi mi 10t. I've captured insane astrophotographs using this phone and it also has burst long exposure mode but deep sky stacking isn't possible without you. the outcome i can either do is trailing OR timelapse of milky way. This phone also has astrophotography mode in builtin camera.
Thanks.
Although your code is in "C" and you're (most probably) using LibRaw C-API, LibRaw itself is created in C++ so it needs C++ standard library to be linked with.
I made a small test code sample which is simply reading a .cr2 image using libraw. When doing make -f makefile.dist and then compiling my code with "-lraw" I get this error message. https://pastebin.com/rjcuut1d
Thank you for your reply. After further analysis, it seems that this kind of histogram is to be expected. I think part of the confusion for me was because I initially assumed that the values coming from the camera will occupy the first 14 bits of the 16-bit range. They are instead spread over 16 bits. I recreated an histogram but this time without any debayering, so directly on the sensor data. In this case we can see that the values are always even numbers (at least most of them) and are spaced evenly on 16-bit range (between 0 and 65533). The gap between each value is 4 which is logical since only 16384 values are possible with 14-bit. I also went back to the histogram that I produced using the PhaseOne SDK and gaps were present too (but less obvious). In this case, they seems to use some kind of contrast correction which I don't have control over. So that's it, I suppose I just need now to divide the pixel values by 4 so all the data will be concentrated on the first 16384 values. Thanks again.
Do you use ./configure provided with LibRaw distiibution or generate own configure script?
Hi, same problem here, but different line:
checking for jas_init in -ljasper... no
configure: WARNING: libjasper not found
./configure: line 12807: syntax error near unexpected token `ZLIB,zlib,'
./configure: line 12807: ` PKG_CHECK_MODULES(ZLIB,zlib,'
any ideas? Thanks very much, Jan
Your file has data corruption, so processing result may depend on how such corruption is handled in the calling code, please contact your library developers for details.
Here are processing results using LibRaw's dcraw_emu -w -T: https://www.dropbox.com/s/d7g25khy96nw4z8/20221010163318528158294_ori_00...
Thank you for the clarification, I was confused by the documentation, but now I understand.
raw_image is also an '*_image' field
From the documentation (which can be sometimes confusing, I agree): "After call to unpack() only one of *_image fields is non-NULL."
C-API is just a thin layer over C++ API, so no difference here.
Based on your source code (w/ built-in filename) I assume you use normal/unaltered bayer-pattern Sony-produced image.
For such images, decoded data is in libRaw->rawdata.raw_image
LibRaw supports most DNG files (all DNG files if compiled w/ DNG SDK)
Dear sir or madam,
I am an enthusiastic user of all of your products. I use it for my Sony and Canon cameras successfully. I also Use a 360 VR Insta360 X3 and older One X2 cameras and I would be delighted if your package would support the RAW DNG files captured by these two cameras.
Best regards,
Frank Tornyai
No cameras produces floating-point data raw images (yet?), one may use (different) HDR-convertor software to create floating point images.
Regarding color3/color4:
- full-color images unpacked by LibRaw itself are (mostly) color4_image, you may use any full-color (not bayer) RAW file for that, for example Canon sRAW/mRAW CR2
- full-color images unpacked by 3rd-party decoders (Adobe DNG SDK, RawSpeed) are usually color3_image images. You may use the same sRAW/mRAW CR2 and RawSpeed decoder (via LibRaw)
Thanks I don't as yet have one, looking into what might be problems in getting one with Black Friday savings! I have been told as it uses DNG it should be OK though.
Please share some example file(s)
Libraw uses DNG SDK only for data decoding. Metadata decoding is performed by LibRaw's code.
So, if you do not provide ZLIB and/or JPEG support to LibRaw it will refuse ZLIB and/or JPEG compressed DNG files at parse stage.
USE_ZLIB USE_JPEG must be used together when using DNG_SDK
AFAIK, Xiaomi smartphones record RAW in DNG format, it is supported.
Hi, I hope you're doing fine. Can you please add support for Xiaomi mi 10t. I've captured insane astrophotographs using this phone and it also has burst long exposure mode but deep sky stacking isn't possible without you. the outcome i can either do is trailing OR timelapse of milky way. This phone also has astrophotography mode in builtin camera.
Thanks.
Yes I'm using C code only. I understand why I won't work the way I do, however I'm not familiar at all with this.
Do you mind explaining me in more details the steps? Thanks.
Also, you need to add librawspeed.a to linker input.
Although your code is in "C" and you're (most probably) using LibRaw C-API, LibRaw itself is created in C++ so it needs C++ standard library to be linked with.
I made a small test code sample which is simply reading a .cr2 image using libraw. When doing make -f makefile.dist and then compiling my code with "-lraw" I get this error message. https://pastebin.com/rjcuut1d
The same way you use LibRaw w/o rawspeed.
once I "make -f makefile.dist", how am I supposed to use the libraw/rawspeed compiled code with my code?
Makefile.dist does not contain any reference to CMake/CMakeLists.txt so I do not know what the problem source is, sorry.
Hi Alex,
Thank you for your reply. After further analysis, it seems that this kind of histogram is to be expected. I think part of the confusion for me was because I initially assumed that the values coming from the camera will occupy the first 14 bits of the 16-bit range. They are instead spread over 16 bits. I recreated an histogram but this time without any debayering, so directly on the sensor data. In this case we can see that the values are always even numbers (at least most of them) and are spaced evenly on 16-bit range (between 0 and 65533). The gap between each value is 4 which is logical since only 16384 values are possible with 14-bit. I also went back to the histogram that I produced using the PhaseOne SDK and gaps were present too (but less obvious). In this case, they seems to use some kind of contrast correction which I don't have control over. So that's it, I suppose I just need now to divide the pixel values by 4 so all the data will be concentrated on the first 16384 values. Thanks again.
Could you please provide RAW file sample for analysis?
BTW, 'minimum processing done' is no processing at al. Consider use LibRaw's unprocessed_raw sample or RawDigger.
Pages