It's always surprised me that there's not more interest in log-scale/floating-point ADCs built directly into camera sensors. Both humans and algorithms care a lot more about a couple-bit difference in dark areas than light, and we happily use floating point numbers to represent high-range values elsewhere in CS.
There was a company that did this circa 2003 - SMaL. Their "autobrite" sensor is built to capture log-scale natively. They've switched owners twice since then, but it seems like they're getting more traction in car vision systems than in professional video.
Blast from the past. You could do things like that [0] in 2005... Autobrite was the first thing to go out the window, once we knew how the chip worked we did or own exposure control...
From an analog design perspective, I don't think that makes sense. Not that I'm an analog designer, but I worked closely with them as a digital designer on CMOS camera sensors.
You're already extracting as much information you can from the analog signal on the least significant bits. It's not like designing a log-scale ADC lets you pull more information from the least significant bits. So you don't really have anything to gain. Why make a more complicated analog circuit to extract less information? It's generally better to let the digital side decide what to keep, how to compress the signal, etc.
And I should mention that CMOS camera sensors can often do a lot of digital processing right there on the chip. So you can do log-scale conversion or whatever you want before you send the data out of the CMOS camera chip.
It might be possible that you could reduce the power consumption of a SAR (successive approximation) ADC by skipping AD conversion of less significant bits if you have signal on the more significant bits. But I doubt the power savings would be very significant.
A lot of the processing steps expect linearity and would have to be reworked for floating point or log scale data. Most HDR sensors are using some kind of logarithmic compression for sensor readout, but I've never really heard of a floating point adc. Google seems to suggest tbey're not readily available.
Yeah there isn't, it's not that simple, even at sensor level to have that much dynamic range
A linear ADC with enough range is usually fine, you can do the math later. But maybe for this case it needs a non-linear element before the ADC? (no idea how log recording needs anything at the HW level)
Is the quantisation error on a modern 14-something bit sensor really that big of a problem compared to something like the inherent shot noise of dark areas?
Some sensors do this internally, unusual though. The rest of the high-end ones apply curves manually in software directly at the egress of the sensor. The reason they don't in all cases is that it complicates black level correction, gamut transforms and demosaic operations (without some assumptions).
I feel like professional/prosumer photogs, aka the kind of people who buy fancy SLR cameras and serious business lenses, probably already know this stuff. I also suspect that the vast, vast majority of phone users just want subjectively good-looking photos.
Yeah, 100%. About 99% of the customer base just wants to take a good photo with the smallest effort possible. Which makes it even more remarkable the company cares enough to include this kind of functionality in a consumer product.
Whenever someone wants a new feature or gets disrupted by the loss of a previous feature, people go, "you have to think of the consumers. Consumers don't use those features, because consumers are stupid. I can't see why anyone would ever add/keep a feature that's not going to be used by those consumers."
The comment I replied to didn't go nearly that far, but it's an argument I've seen so often that I feel compelled to point out that "consumers" are not the only target audience for Apple - they are trying to also market themselves to creators, as well as professionals, and they absolutely know the difference and notice when things like these become available.
> people go, "you have to think of the consumers. Consumers don't use those features, because consumers are stupid. I can't see why anyone would ever add/keep a feature that's not going to be used by those consumers."
Well, I don't think "people" generally do that. It's nothing to do with stupidity; just lack of need and interest.
> The comment I replied to didn't go nearly that far
Not just "didn't go that far", it wasn't anything to do with that. It was just articulating pleasant surprise.
If I were to return this thread to its objective origin, I would agree that if you're selling a mass-market device, it's surprising to cater to a fractional percentage of that user base. I don't see how that's contentious.
Apple sells a very enticing mix of feeling and product, the good old Jobs distortion field. They always had an enormous influence on what's cool, what's premium, what you should want, what's the baseline, etc.
And it's entirely possible that they got to the point that they are now saying pro stuff is cool. Even is 99.x % of users won't really use it.
See but you don't necessarily want full range logarithmic.
If your darkest pixel is halfway down the ADC range, on linear you're throwing away one bit, on logarithmic you're throwing out way more bits. Just using higher bit linear ADC then converting it to logarithmic in post-processing seems more sensible. Hell you could even go signal magic and merge few photos with different shutter speed together to get most detail.
Also proper log-to-in converter like AD8307 costs like $20 so I'd assume doing that woudl bring the sensor price way up if you needed to have a bunch of them.
From my understanding, the ADC's are still fixed point and linear. Two (or more) then run in parallel over different signal levels to produce the 32-bit float output.
Encoding audio with different log-scale companding has been around for some time too (since the 1970's) with A-law and mu-law in G.711.
It doesn't really matter HOW they do it, as long as you get the advantages of float encoding (practically infinite headroom). Of course if you zoom in enough there will be something in there that uses integers, but this would be true for e.g. a floating point adder as well.
It should matter that "practiaclly infinite headroom" comes from the fact that the raw samples has 64 bit of dynamic range, than output format being float.
(does that mean there is a crossover in the middle of amplitude range that shows LSBs of one of ADCs poking their heads, I mean, in a hypothetical ultra-naive implementation?)
>the advantages of float encoding (practically infinite headroom)
The best implementations have a dynamic range of about 140-150 dBA. Floating point is not needed to achieve that and it isn't always used (look at Stagetec products).
I'm not entirely sure what you mean by floating point for an ADC.
from a super high level all ADCS do is quantize an analog signal. They take in a voltage from say 0 - 1.8V and quantize that on a 12 bit range. Return a value from 0-4095.
You could build one that scales this range with non-linear steps. But this doesn't add any value. We won't get more accuracy at smaller steps. Our noise and accuracy problems won't be solved by this as they are due to thermal noise or mismatch. quantization noise is not the problem.
(We already build segmented ADCs to try and do this)
That was in reference overall ADC stage in abstract, not component. As you note quantisation still maps to integers over some range of the input signal.
It's not my area so would love to correction from someone who is deep in the space. My current perception is the 32 bit float hype in the audio capture world is the marketing reality distortion field in effect. Having that representation expand further upstream than the DSP or DAW makes sense, but it's not magic. Even in 32 bit float there's only 24 bits of precision (assuming IEEE 754).
What is interesting, useful, and lost in that noise is devices have refined the multi-ADC design to enable full usage of that precision matched to the overall dynamic range of the analogue front-end. Previously the ADC would be the bottleneck, but that's now shifted to the upstream circuitry or transducer.
