LWN.net Logo

The Grumpy Editor's guide to HDR with Linux

The Grumpy Editor's guide to HDR with Linux

Posted Jul 8, 2007 3:20 UTC (Sun) by ralatalo (guest, #46131)
In reply to: The Grumpy Editor's guide to HDR with Linux by scarabaeus
Parent article: The Grumpy Editor's guide to HDR with Linux

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.


(Log in to post comments)

Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds