Say, if they were of 16 bit type I'll pretty sure and pretty soon get the digital values, summed up, bounce against MAX.
Better yet, they probably wrap around
Would You mind to denote that limitation in the documentation?
The official documentation is the wiki, which anyone can edit. I can confirm the merge operations use unsigned 16 bit numbers.
Note that the raw may be 10 (mostly old digic II/III cameras), 12 (most cameras), or 14 (g1x) bits, so the number of images it takes to overflow will vary.
Could You think of a workaround? If it were possible to calculate with floating point types internally that prob would be levered out.
Averaging in groups should be roughly equivalent: e.g. average 5 sets of 10 images, and then average the resulting 5.
It wouldn't be hugely difficult to use a different type in the code (see modules/raw_merge.c in the source), but I'm not sure it's worth it. If you are serious about this kind of thing, you are probably much better off doing it on a PC.
