brite_eye... I've been looking at the patent application that I found and looking at the RAW files.
So far the RAW files seem consistent with the patent app - though I haven't worked through the details yet to prove or disprove this. Basically the patent app. seems to describe a hardware mechanism for losslessly compressing the data coming from an image sensor and writing it to FLASH memory. It doesn't describe the lossless compression mechanism with enough detail to easily reproduce it or write a decoder... but, more on that later.
I think that SMaL has made some reasonable design decisions... For many digital cameras the goal is to take pictures and then write JPEG or TIFF files to an accessible flash memory card. But, I think SMaL's approach is to take pictures and save them with "enough" compression on the camera - then rely on driver software to convert the images to TIFF or JPEG later. While the described arithemetic coding is fairly complicated, it is no where near the complexity of JPEG - and maybe better than the compression schemes available in TIFF.
The patent app. covers a method where data is compressed as it is read from the image sensor - in one pass. This is a) fast and b) un-complicated enough that it can be implemented in their custom hardware. While the compression isn't as good as lossy JPEG, it just needs to be good enough to store the advertised number of images on the camera's memory. The real complexity (i.e. JPEG) can be done later in a software driver.
The uncompressed data would be around 3.15Mb (1280 x 860 x 24-bit image) - but the compressed files of the RAW bayer image data come out under 650Kb. This is pretty good. If we figure out the compression then we'll be able to take an uncompressed image and try compressing it ourselves (using JPEG, TIFF, etc.) to see how good this RAW compression really is. But considering that most other compression schemes can't be done in hardware easily... this is probably a pretty good design compromise.
Also, if SMaL develops a unique compression scheme then they _might_ be able to patent it - that seems to be part of the "design" here.
I've read the compression patent app. a good bit. It doesn't seem - to me - to be well written. There's a lot of background and discourse about the mechanism - but at a number of points it provides general "hand waving" at presumably well-known arithmetic coding techniques instead of actual descriptions of what is going on. Also, the claims part - which I think is the "meat" of the thing - seems to have the same paragraph copied multiple times in a row. Perhaps this is how patents need to be written, but it seems like a much less clear description of the thing being patented than the other patents I've been reading to try to understand arithmetic coding. I wonder if it will be granted... 
Assuming that this patent app. describes the encryption in the Dakota Digital PV2, there is definitely a gap to be bridged between what's "described" in the patent app. and what's implemented in the camera. The patent app. may be intentionally vague in order to cover a range of specific implementations. Or, the patent application may be intentionally obfuscated in order to avoid revealing their product's compression mechanism (though that seems at cross purposes with getting a patent).
- sailpix
