Hi,
I recently upgraded from 0.19.5 to 0.20.0 and I noticed the difference in rendered sRGB output for many camera phone shot DNG files. I also noticed differences in the rgb_cam, cam_xyz and pre_mul values returned. I wanted to confirm if this is indeed intentional or a bug.
I tried to use the compiled unprocessed_raw in the Mac but it it requesting for libSystem.B.dylib. See attached. I can't find that file.
Is it possible to run unprocessed_raw without installation? The intention is to include unprocessed_raw in my application app. So best option would be to have required libraries, dll included in a single executable file.
I am using libraw for a CR2toFits conversion program i wrote. It extracts either a raw CFA image or a debayered RGB colour image and creates a FITs file. And since it's just for me, it only handles the Canon T2i CR2 files. I had been using libraw v0.19.2 but just upgraded to libraw v0.20.0.
I use librawFile.unpack() to load the raw data.
Then access the raw data use librawFile.imgdata.rawdata.raw_image[b] to read the sensor pixel values.
This camera produces a RAW file that has a REGB layout which means there are 4 colors. This results in a non-square rgb_cam. However, the display code in raw-identify (v 0.19.6) appears to be incorrect. The code is as below:
for (int i = 0; i < P1.colors; i++)
printf("%6.4f\t%6.4f\t%6.4f\n", C.rgb_cam[i][0], C.rgb_cam[i][1], C.rgb_cam[i][2]);
I'm getting pink clouds when trying to convert a RAW to a TIF/JPEG with LibRaw 0.20.0. I've run into this a while ago in fact, when using the RawPy wrapper library for Python.
Hello everyone.
First thank you for your big work on this lib I used for my software.
Since the last version I have issues with some camera (especially canon). This is probably due to a big change you've done.
As stated in Changelog:
* Bayer images: ensure that even margins have the same COLOR() for both the active sensor area and the full sensor area.
I've been sent some CR3 files that were reported as causing my application to freeze.
The problem appears to be that open_file() never returns and just sits there eating CPU.
These same files also cause Windows Explorer to freeze for a number of seconds and then Explorer closes and restarts (maybe they're using LibRaw internally to the raw file codec).
I've placed a zip file containing the bad files on Dropbox:
I am trying to convert CR3 images to 16 bit fits files used RAW2FITS, which uses libraw. I have the newest libraw installed, which supports cr3.
When converting to 8 bit images, everything looks fine. However, when setting the output_bps to 16 everything is garbled, at the libraw level. First of all, pixel values are all still 8 bit (max values of 255) and their coordinates are wrong also.
They fail when calling unpack() with the error "Corrupted data or unexpected EOF". Call to open_file works. Hence raw-identify is able to parse metadata from the file.
Recent comments