The Grumpy Editor's guide to HDR with Linux [LWN.net]

The Grumpy Editor's guide to HDR with Linux

Posted Mar 15, 2007 11:15 UTC (Thu) by scarabaeus (guest, #7142)
Parent article: The Grumpy Editor's guide to HDR with Linux

With regard to making cameras create HDR images: It would be interesting to see a camera that "inverts" the way pictures are taken. Instead of this way:

Expose the sensor to light for n milliseconds, then measure the amount of light

..the camera ought to work this way:

Expose the sensor to light. For each pixel, measure the time in milliseconds until the pixel is fully saturated

I'm aware that a sensor like this would be, er, "not straightforward" to build. Still: No blooming, automatic HDR, exposure can be corrected at a later time without quality loss... *sigh* (The above wouldn't really work; you need an upper bound on the exposure time, so you need to measure both the time and saturation => complex per-pixel logic => unacceptable resolution :-( )

to post comments

The Grumpy Editor's guide to HDR with Linux

Posted Mar 15, 2007 15:08 UTC (Thu) by smurf (subscriber, #17840) [Link]

That method would also get you rather interesting effects when you photograph moving objects -- motion blur would be smaller for the brighter parts.

Still, at four transistors per bit, and a minimum of 12 bits per pixel and three MPixel, that's a whole damn lot of transistors. :-/

(That's the minimum level I'd personally like to have if I wanted to experiment with that kind of technology. 12 bits are sufficient, by the way, because nobody forces you to keep the clock rate constant.)

The Grumpy Editor's guide to HDR with Linux

Posted Mar 16, 2007 8:22 UTC (Fri) by wstfgl (guest, #42907) [Link]

> Expose the sensor to light. For each pixel, measure the time in
> milliseconds until the pixel is fully saturated

There's quite a bit of research currently in progress to develop cameras
that do just that (Google for "Address Event Representation Camera") - I
remember a couple of my engineering friends did their honours thesis on
the topic.

AFAIK, the technology is better than regular CMOS imagers in terms of
power consumption, but tends to have a lower resolution and dynamic
range - good for embedded devices, not so good for photography. Also since
the time available for each frame needs to be bounded, you tend to get a
lot of pixels 'squashed' against either the upper or lower bound of the
intensity range.

The Grumpy Editor's guide to HDR with Linux

Posted Jul 8, 2007 3:20 UTC (Sun) by ralatalo (guest, #46131) [Link]

Well... two (big) problems...

1) How do you turn these numbers into a picture? Essentially you are still measuring the brightness of each pixel, so if you have the following:

Light Level | Photons in Exposure | Millisecond till Fill
1 | 1 | 100
2 | 2 | 50
3 | 3 | 33
4 | 4 | 25
5 | 5 | 20
....
....
10 | 10 | 10
20 | 20 | 5
30 | 30 | 3 (or 3.3)
40 | 40 | 2 (or 2.5)
50 | 50 | 2 (really 2)
....
....
100 | 100 | 1

So, all you are really doing is inverting the brightness and you still have the same problems... How do you record a subject that is bright enough that it fills the buffer in under your measurable time? And how do you deal with a subject so dark that it takes more time that you can record in your counter.

The Jpeg and other formats use 8 bits to record brightness which gives 256 different levels, so no matter what else you do you will have trouble when you try to record the 257th level. Nikon's raw format uses 11 bits and I assume other raw formats use more than 8 as well. HDR uses 16 or maybe 32 bits which allow them to record a wider range. If the camera manufactures wanted to they could (and are) working on sensors which require less light which means that the could/will be able to measure more on the lower range and in turn could be make to record a wider range.

The second big problem is that is your scheme imposes an exposure timing on pictures. There would be so more fast shutter speeds to freeze action or show shutter speeds to blur movement.