positive exposure shift may be non-linear (highlights compression), while auto-bright is linear.

BTW, LibRaw's dcraw_process() is only 'sample' processing. It is not ideal and not in development. We hope developers will implement own processing on top of LibRaw::open_file/unpack.

We use LibRaw in 64-bit windows projects (Visual Studio 2010 and 2013) without any problem.

Could you please describe the problem in more details?

Seems like this is due to

    imgdata.params.no_auto_bright = 0;

Using no_auto_bright = 1 seems to allow using values of 0.25 <= exp_shift < 1.0 !?
API docu doesn't indicate this constraint.

data_size is not used in kodak_jpeg_load_raw(), so it is not critical.

All Kodak files from your link are processed OK by our FastRawViewer and RawDigger (LibRaw used internally).

You can download the RAW here.

The output of the following command looks ok.

dcraw_emu -w -6 -T 01.cr2

Find a thumbnail of the output here

Seems like I don't use the correct options on LibRaw or GraphicsMagick is causing the problem.

I find it interesting that the latest EXIFTool incorrectly reports the camera manufacturer as "Canon" and the model as "Inc.". Any reference to the actual camera model (which appears to be properly encoded in the data) is missing. I looked (briefly) at the EXIFTool source and it is far, far beyond what I want to get into.

If you have an EXIFTool which reports the name of the camera model correctly, can you please share? (if nothing else, you can upload it to ftp.infinadyne.com - it takes anonymous uploads in the root.

I could run EXIFTool against all the raw files I have from various sources, but if they do not properly reflect the camera model, it isn't really all that useful.

See a downscaled version of the output here.
This used to be a picture of a beach incl. bright sun light.

1) no_auto_bright will do not do any auto-brigten, so for 10-bit images (for example) you'll get 0...1023 data range whilt 16-bit data range is 0..64k. Most likely you need some data scaling

2) gamm[0]=gamm[1] = 1.0 is NOT 'gamma corrected' image. It is gamma=1.0 with slope (linear part) 1.0

OK, magic is completely resolved:
- on 64-bit compile everything is OK because of 64-bit size_t
- on unix 32 bit compile all is OK because fseek's offset is long, so 32 bit
- on 32-bit LibRaw with file interface, LibRaw_file_datastream is used by default. It is based on 32-bit std::streambuf, so out-of-range offset is converted back to 32-bit '-53' (for the sample).

So, only bigfile_datastream (not used for small files by default) and buffer_datastream (read from memory) are affected.

Fortunately, this is the only place where strlen is used as fseek() parameter.

BTW, best way to fix looks like (in the beginning of dcraw_common.cpp):

int my_strlen(const char *str)
{
	return (int)strnlen(str,0x7fffffff);
}
#define strlen(a) my_strlen((a))

Yes, I tracked it down to that as well.

There is the odd construct (odd? For dcraw? Whatever!) that is making some interesting assumptions:

fread (make, 64, 1, ifp);
fseek (ifp, strlen(make) - 63, SEEK_CUR);
fread (model, 64, 1, ifp);

With VC 2013 (and probably many others) the return value from strlen() is size_t, which is unsigned. What we want here is to back up the data pointer with a signed offset. The fseek memory buffer implementation wants a signed 64-bit value, but the result of (10u - 63) promoted as an unsigned value to 64 bits is 0x00000000ffffffcb which doesn't work at all.

I suspect there are a few other places where a signed offset for fseek is used as well and anywhere it occurs with an unsigned 32-bit value being promoted to 64 bits is going to have problems.

One way to get this working is:

fread (make, 64, 1, ifp);
fseek (ifp, (INT64)strlen(make) - 63, SEEK_CUR);
fread (model, 64, 1, ifp);

By casting the size_t to an int the promotion of the value from 32 to 64 bits works properly. Unfortunately, this is in the base dcraw code. I suspect there might be a way to fix this in the LibRaw code. I do not believe that the define:

#define strlen(x) (INT64)strlen(x)

is the right way to go, but it would at least get the cast out of the dcraw code. Alex, I'll let you figure out a way to accomplish this with the least amount of work.

This sample is from PowerShot 600 camera, so decoder is canon_600_load_raw()

That does make things tough to figure out. I will pull the error count to check for things like this - I can see the counter at 255110 after unpack() with what I have. I think any non-zero value is likely to be fatal.

What is failing is the line:

if ((pixel[(block << 6) + i] = base[i & 1] += diffbuf[i]) >> 10)
derror();

I am not at all sure I understand this line of code. If one separates out things in parentheses, we have an assignment to pixel[block << 6> + I] which makes sense, but the condition being tested is, at best, a little odd. This does not appear in older versions of dcraw, so I have nothing to compare against. But why would anyone form a conditional expression which comes down to (x >> 10)???

I suppose this could be a rather strange way of saying (x > 1023), but why make it so cryptic? I know, that is the dcraw/dave coffin way of things. But I can complain, can't I? It has been a long time since I actually found obfuscated C to be all that funny.

Does this pixel-content test actually make sense in this context?

One thing occurs to me with this - I am thinking that it is a typical debug/release sort of problem. I am working with DEBUG builds right now and building the library as a static library in DEBUG mode. I am wondering if the problem might disappear with a release build - perhaps because of initializing memory with zeros instead of CDCDCDCD, or just because of different stack layout.

I will do some more digging since I now have a much better handle on why it is failing. Maybe it should fail, but there is an image buried in there that can be rendered, so it would be nice to be able to get it out.