on my libraw port on android, I'm getting a SIGSEGV (signal 11 (SIGSEGV), code 2 (SEGV_ACCERR)) in the xtrans_decode_block function when trying to call "libraw_unpack" on a raf file reported by an user (X-T20)(see link below). What I tried is to check at which point exactly it crashes (it's a little tricky under android), and found out that it fails somewhere in the last loop (logged the state at line 712, the last output before it fails is:
xtrans_decode_block 22 15 512 (22 = g_even_pos, 15 = g_odd_pos, 512 = line_width)
I want to decode a raw image to produce a pgm file that has merged the 4 Bayer photosites with no pre-processing (like color balance, gamma, etc.) into a 16-bit grayscale pixel.
My first attempt was dcraw -4 -D which resulted in an image, but with the characteristic "blockiness" due to the unmerged photosites.
I know Libraw is based on dcraw code, so I thought I'd ask here if anyone has any suggestions on how to use dcraw in the above scenario.
Is there a way to specify libraw to use the L-star gamma function? Or do I need to manually apply the function, and then specify the libraw linear function?
I mean this formula (from lindblum.com): (linear <= (216.0 / 24389.0)) ? (linear * 24389.0 / 2700.0) : (1.16 * Math.pow(linear, 1.0 / 3.0) - 0.16);
Now I want to add support for RawSpeed. I read that FastRawViewer is using RawSpeed. So how do I get RawSpeed support in LibRaw 0.18.3?
I've been trying all weekend without success. I can get it to compile, but in the linking stage, it always comes back with error on "-lrawspeed". Since RawSpeed is not a library, I'm not sure why the Makefile.dist has this as an option?
When I let DCRAW apply demosaicing, a color transformation based on the rgb_cam matrix is carried out in convert_to_rgb().
This transformation (within sRGB color space) gives my images a warm and slightly greenish look, which is not present in accompanying JPGs (taken with 'sunny' color balance).
For my camera, a Canon EOS 1100D, I found the rgb_cam matrix to be filled in by the adobe_coeff() function.
Should I really use this transformation? Or is there a better way to correct the cross-sensitivity of the color filters?
When I use image demosaicing with color filter array got by LibRaw::COLOR(row, column) most outputs looks consistent apart from some Canon images, which looks too purple.
For those files obtained color filter array (by COLOR(row, col)) looks like simple RGGB:
R G
G B
However if I use row offset instead:
G B
R G
the results seems to be OK.
Does LibRaw return correct cfa pattern for those files?
At the completion of a project that uses LibRaw, I want to share the more intense algorithm artifact analysis to be helpful for anyone hoping to use LibRaw in the future, and as a thank-you to Alex for the direct support.
To summarize, algorithm (user_qual) 11, DHT, is the best. It's better than the best offered by RawTherapee, too.
Here are the most important examinations I performed!
I noticed that for .dng files with bitmap thumbnail LibRaw claims that there is no color in the preview (thumbnail.tcolors = 0 after open_file() + unpack_thumb()).
Shouldn't it return 3 colors (tcolors = 3) as from documentation LIBRAW_THUMBNAIL_BITMAP preview contains RGB bitmap?
Recent comments