Demosaicing and bit dimensions

Started 10 months ago | Discussions thread
Contributing MemberPosts: 577
Re: Demosaicing and bit dimensions
In reply to Roland Karlsson, 10 months ago

Roland Karlsson wrote:

The_Suede wrote:

Working that 45º example out to a 36x24mm FF area, that's 96MP, to get a non-aliased 48MP image.


Comparing that to say a 48MP normal 0/90º Bayer image, I doubt you get ANY improvements at all

Hmmmmmm ----

- and I can bet quite a lot that the process to make the pixel structure sqrt(2) smaller involves quite a bit of losses in both angle sensitivity and overall sensitivity.

You shall NOT do that! That was what Fuji was forced to do due to marketing reasons. It is not a good idea.

The image should be stored as 96 MP or 24 MP.

My point is that this 24 MP image might be nearly as good as the 0 degree 48 MP image, saving half the storage.

This will balance out with the Bayer interpolation inaccuracies to get you a net sum of nothing, or 1:1 ratio of improvement if you put it that way. So: Pay more to get nothing.

There you have my total agreement. This is also one of my own favourite subjects in digital imaging: The discrepancy between capture resolution you need to get a correctly sampled image, and the amount of "unnecessary" data this entails. Data redundancy, if you put it that way.

But you're wrong at one point - Bayer saves only one data-point per image point - so it carries a 3:1 compression ratio just by being what it is. A fully populated file has three data points per image point, making it three times "heavier" per image point than the Bayer-coded image.

I want a camera with a ~50-60MP+ capture. For pure image quality reasons. But what I DON'T want is a 60MP = 100MB+ (?) raw file...

In the end, I'd be very satisfied with a ~15-20MP raw format scale of image data, data that has not yet been color-transformed or treated to any other kind of non-linear transform - and I want it in a good tone resolution format. And I want each and every single data point in the raw file I save to have an objective meaning - any surplus weight is dead weight, just megabytes of crap to suffer through in file handling.

We had this discussion before, and 20MP's of a linear-format three-layer data plane saved in a gamma 2.0 data representation in 10-bit depth format gives ~4 bytes per pixel. Without compression, that's 80MB. With any reasonably close-to-lossless compression, it's a 30MB raw file. Where every bit carries real image information.

Since the data is already in three-plane form, it would also speed up the raw conversion by quite a lot - it's the Bayer-interpolation that takes up most of the overhead when reviewing and developing the raw files we have today.


So, oversampling image capture, downsampling before image save. IMO that's the optimal way to go, until we finally get the working full-sampled sensor (three colors per image point) working well. And I'm sorry - the Foveon isn't even close. It has huge color problems, making it useless for any kind of application that demands accurate color reproduction. And it has extremely low light efficiency, making it fairly useless for any low-light scenario. It's a one-trick pony, only able to give good resolution in good light, as long as you don't care about color accuracy. Only a very small part of the photography going on today is covered by that performance envelope.

Reply   Reply with quote   Complain
Keyboard shortcuts:
FForum PPrevious NNext WNext unread UUpvote SSubscribe RReply QQuote BBookmark post MMy threads
Color scheme? Blue / Yellow