But you have successfully used RawSpeed in FastRawViewer under the Mac, right? I'm a registered user of FastRawViewer, and my DNG file doesn't crash it.

But anyway, here is the link to the DNG file:

https://www.dropbox.com/s/zg6785bm9err9gf/DJI_0329.DNG?dl=0

Thanks.

After half a day of playing around with it, I still get a crash whenever a DNG file is decoded.

Below is how I compile librawspeed and libraw (this is under macOS):

For RawSpeed:
- Unpack the rawspeed-master.zip file
- Copy it to the same folder that stores LibRaw-x.xx.x
- Rename it to RawSpeed
- Copy the patch files from LibRaw/RawSpeed to RawSpeed/RawSpeed directory
- Run patch < rawspeed.cpucount-unix.patch
- Edit Common.cpp and cut and paste the the function int rawspeed_get_number_of_processor_cores() to the end of the file, outside of the #elif
- Run patch < rawspeed.qmake-pro-files.patch
- Run qmake -makefile rawspeed-lib.pro
- Edit DngDecoderSlices, find the line with jpeg_read_header(&info, TRUE). Cast TRUE with (boolean)
- Edit RawDecoderThread.h, change 'uint32 taskNo' to 'int32 taskNo'
- Edit the Makefile. Change -mmacosx-version-min= to the version you want (such as 10.9)
- Run make

For LibRaw:
- Edit Makefile.dist
- Uncomment the two lines under '# RawSpeed Support'
- Add -mmacosx-version-min=xx.x to CFLAGS+=
- Uncomment the lines 'Demosaic Pack GPL2 and GPL3'
- Run make -f Makefile.dist

There were some warnings when compiling RawSpeed. The most notable one is bit shifting a negative number. This is undefined by the gcc compiler. This warning is in LJpegDecompressor.cpp. I tried changing -32768 to 0b1000000000000000, but the crash persists.

I found that sometime I can decode the DNG file and have it displayed on the screen. But my app crashes just by sitting there idle for a few seconds. Other times, my app crashes right at the line "rawProcessor.unpack()". It seems that the code in RawSpeed in decoding DNG file is corrupting some memory locations, and when some background garbage collection occurs, the app crashed.

As soon as I set 'imgdata.params.use_rawspeed = 0', DNG files are decoded correctly without any crash at all.

Perhaps you have fixed something in the master branch of RawSpeed to allow successful decoding of DNG files?

I just experienced crashes when I decoded DNG and Olympus ORF files with RawSpeed turned on.

I've installed the rawspeed.uncompressed-color-dng.patch. So what else am I missing?

if rawspeed has decoded the file, this bit is turned on:

imgdata.process_warnings |= LIBRAW_WARN_RAWSPEED_PROCESSED;

(this is not warning, just info)

Although README.RawSpeed.txt does not look fresh, RawSpeed master branch was not updated from 2014 too.

Slightly more details are here: https://github.com/LibRaw/LibRaw/blob/master/README.RawSpeed.txt

Thank you.

I do not think it is possible. So, only 3rd party apps may help (like our FastRawViewer, for example)

Hi Alex,
We're preforming some noise suppression prior to passing the raw buffer into the demosaicing chain, so yes, we have raw pixel values in the neighborhood of 0.

Falka, As the guy who sat in the office next to yours, i figured i'd come on and say thank you for your help this summer!

On a more technical note, taking a closer look at the imagery generated utilizing DHT, we found some artifacts in near-nodata (CFA ~= 0) regions of an image (or if you just hack off the bottom end prior to passing it into DHT). I believe these are just integer wrap-arounds.

lexa, we'll be sure to look into compiling with OpenMP!

Sorry, API documentation is incomplete for COLOR() call and needs to be updated.

the row,col parameters you feed to COLOR() call should be relative to image visible area, not full sensor area.

So, the intended use is (pseudocode, there is no raw_image call!)

  for(row = 0; row < height; row++)
     for(col = 0; col < width; col++)
{ 
     color = COLOR(row,col);
     data[... ][color] = raw_image(row+top_margin, col+left_margin);
 }

For most cameras this does not matter because top_margin,left_margin are multiple of 2, but both 60D and 1Ds2 use odd top_margin.

dcraw.c is self-documented (in computer code). The function you need to analyze is scale_colors()