Firstly you need to consider bit depth. Currently digital cameras are ~12 bits per pixel, but this is likely to increase. So to be completely general, your file format cannot make any assumptions about the size of the integers that represent the pixels. If you've ever tried to design a file format, you'll know that that is already a serious problem.
Secondly, consider the Bayer mask. Sony have already come out with a four-colour mask, and while there are good reasons why >4 colours in a mask is unlikely, I don't see how you can rule it out, so your format needs to be flexible enough to describe any possible mask layout and any number of mask colours.
Thirdly, consider the number of colours recorded by each pixel. Foveon sensors record three. From what I know of the technology I can't see why you couldn't record a larger number, and there would be some interesting benefits in doing so, eg the ability to implement optical filters digitally.
These are just the first three problems that come to mind in ten minutes of thinking about the issue. I'm sure there are many more. I think the best you can do is to make your RAW format similar to an existing format so that it becomes relatively easy for software makers to support it, which according to John in a separate email on the subject is exactly what Pentax have done.
S
[EMAIL PROTECTED] wrote:
My understanding is that the RAW format is literally the raw data read straight off the sensor. A "standard" RAW format would be next to impossible, as it would have to take into account every possible future advance in sensor technology.
Probably not quite the case.
Consider what the camera is likely to actually store as "raw". The data
straight off the sensor would presumably be a collection of small
integers indicating the amount of light that struck each pixel, plus perhaps some data about how the camera was set up and how the bayer
grid was arranged.
If you had a header that accounted for camera parameters (as the JPEG
header can hold EXIF) and then a raw format body that began with a simple header that said "a times b integers 0-255 follow" you could handle
any resolution sensor trivially. You could use the same data organization
(file format) regardless of the amount of data. Really all a CCD does
is to react simply to light exposure, just as a film "grain" does.
DJE
