by the way, i did some experiments. first, i am making the assumption that you are calling dcraw as follows:

dcraw -4 -o 0 -r 1 1 1 1 -d -t 0 -c

little d being the key here, which causes the scaling (vs -D, which does not)

if this is not the case, then the following analysis is pure BS.

i read dcraw.c and while it’s a little hard to follow with all the globals, it’s clear that the scaling is not simply expanding 0…16383 to 0…65535 by multiplying by 4. instead it’s finding out the value of the “blackest” pixel and the value of the most saturated pixel, and then expanding the data to fill that range. i think the “black” pixel must be coming from an overscan region because in light frames i tested the lowest scaled value in the actual image is still much greater than 0.

i tested 139 CR2 files from my canon 50D (taken over 3 consecutive nights), and found that the “black” pixel value was not constant. here is a sorted list showing how many frames had identical scaling:

`1 Scaling with darkness 1001, saturation 15763, and 1 Scaling with darkness 1003, saturation 15763, and 1 Scaling with darkness 1005, saturation 15763, and 1 Scaling with darkness 1008, saturation 15763, and 1 Scaling with darkness 1018, saturation 15763, and 1 Scaling with darkness 911, saturation 15763, and 1 Scaling with darkness 946, saturation 15763, and 1 Scaling with darkness 954, saturation 15763, and 1 Scaling with darkness 965, saturation 15763, and 1 Scaling with darkness 971, saturation 15763, and 1 Scaling with darkness 982, saturation 15763, and 1 Scaling with darkness 988, saturation 15763, and 1 Scaling with darkness 992, saturation 15763, and 1 Scaling with darkness 998, saturation 15763, and 2 Scaling with darkness 1006, saturation 15763, and 2 Scaling with darkness 1007, saturation 15763, and 2 Scaling with darkness 1015, saturation 15763, and 3 Scaling with darkness 1021, saturation 15763, and 4 Scaling with darkness 1019, saturation 15763, and 6 Scaling with darkness 1009, saturation 15763, and 7 Scaling with darkness 1011, saturation 15763, and 7 Scaling with darkness 1014, saturation 15763, and 10 Scaling with darkness 1010, saturation 15763, and 10 Scaling with darkness 1020, saturation 15763, and 11 Scaling with darkness 1012, saturation 15763, and 12 Scaling with darkness 1013, saturation 15763, and 13 Scaling with darkness 1022, saturation 15763, and 16 Scaling with darkness 1016, saturation 15763, and 20 Scaling with darkness 1023, saturation 15763, and`

granted these are not huge differences, but the spread here is pretty significant (112 counts).

so anyway, my point is that the scaling is not a constant function, but is somehow dependent on the data in the frame.

secondly, DCRAW is outputting 16-bit integers… which means that all this floating-point division and multiplication is happening, and then the decimal places end up truncated (or maybe rounded, i don’t know what happens when a ushort is assigned from a RHS containing floats). either way, this means that multiple ADU values in the 14-bit space map to a single ADU value in the 16-bit space.

both taken together it’s quite a bit of modification of the raw sensor data, and the changes are not reversible.

anyway in practice does any of this matter? i don’t know. i just feel that a capture program should avoid touching the camera data as much as possible. assuming this analysis is correct, -d touches the data in somewhat unpredictable ways.

rob