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.
Сheck that the toolchain (autotools, libtool) isn't broken.
When the log suggests to run autoupdate, it may make sense to try it (after being sure toolchain is OK, and if the message re autoupdate still appears).
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.
Do you see Hasselblad X2D 100C in LibRaw 0.21 supported camera list?
Thanks guys for this great library!
I have added it to my Photo Management application Tonfotos: https://tonfotos.com
By the way, is there any progress with this "Used by" initiative? I think that is a great tool to promote LibRaw.
Just in case, Tonfotos logo can be found here: https://tonfotos.com/img/logo/icon-ui.webp
Regards,
Andrey
It is supported in LibRaq 0.21-beta available at github (we plan to release it in a month or so)
Any estimated timeline when Canon EOS R7 raw will be supported?
I'm in the same situation too. Did you find any solution to your problem?
Oh, I see. Thanks for the information.
Yes, dt (again) uses LibRaw but (AFAIK) for Canon CR3 files only.
Please contact dt team for details.
Сheck that the toolchain (autotools, libtool) isn't broken.
When the log suggests to run autoupdate, it may make sense to try it (after being sure toolchain is OK, and if the message re autoupdate still appears).
OM-1 is supported by this commit: https://github.com/LibRaw/LibRaw/commit/adcb898a00746c8aa886eb06cc9f5a1c... (dated Mar 13, 2022)
Pages