Dear all,
I was reading though webHDR's calibration page and it is mentioned that
images should not have RGB values above 200 or below 20.
I took a range of photographs of a series of daylit spaces and it looks
like that for some series there isn't a single image without values
either below or above those limits. In fact, quite often the same image
has values both above and below
There's indeed considerable contrast in my scenes, in some cases
composed of dark corridors and rooflights. Some of them also have direct
sunlight getting into the spaces.
However, I'm surprised for not being able to get a single image within
those limits from a range of 15 exposures.
I used a Cannon EOS 20D and my White Balance was set to Daylight.
Does anyone have the same experience of trying to make HDR images of
(shall I call it) "extremely" daylit spaces and coming to the same
problem?
Is there a range of luminances that would deliver
Does this mean that these images are not good to be converted to HDR?
Also, would like to know if the above mentioned limits are general
thresholds or just applicable to HDR images generated using hdrgen?
Thanks in advance,
Raquel
Hi,
I think there is a misunderstanding here. I am sure that the
documentation you refer to is related to the source images. These are
8-bit coded, and allow values from 0-255. This means that below 20 and
over 200 you get into the edges of this range. As the jpg's you get from
a digital camera are not linear mappings from luminance to pixel values,
and a slight change in these edge pixel values is related to a huge
change in the luminance of the recorded scene, it gets impossible to
reconstruct luminance values from such values. Have a look at the
s-shaped response curve of your camera, it should explain this problem.
So hdr tools can use only this "middle" range, and this means that you
must make sure that the ranges of your overlap have a sufficient
overlap. Also, of course, the darkest (shortest exposure time) image
should not contain any very bright pixels, and the brightest one
(longest exposure time) no very dark ones. So if e.g. your brightest
image was taken with 1/2sec and has significant pixel values below 20,
take one more with 1sec time.
Cheers, Lars.
Hi Raquel,
Generally agreeing with Lars, I would like to add that it should not be
impossible
to create a useful HDR image if the input exposures have RGB values greater
than
200 or smaller than 20. Actually, as you pointed out it should be very
difficult to
capture bracketed sequences where any exposure fits into these limits.
The HDR creation algorithms generally employ a weighting scheme to underplay
the influence of over- and under-exposed pixels. This is usually a smooth
function
giving higher weights to midtones and lower weights to extreme darks and
lights.
I think any tool that employs such a weighting scheme should be able to cope
with input images that have pixel values close to the edges of the RGB
range.
Cheers,
Oguz
···
On Wed, Sep 9, 2009 at 9:53 AM, Lars O. Grobe <[email protected]> wrote:
Hi,
I think there is a misunderstanding here. I am sure that the
documentation you refer to is related to the source images. These are
8-bit coded, and allow values from 0-255. This means that below 20 and
over 200 you get into the edges of this range. As the jpg's you get from
a digital camera are not linear mappings from luminance to pixel values,
and a slight change in these edge pixel values is related to a huge
change in the luminance of the recorded scene, it gets impossible to
reconstruct luminance values from such values. Have a look at the
s-shaped response curve of your camera, it should explain this problem.
So hdr tools can use only this "middle" range, and this means that you
must make sure that the ranges of your overlap have a sufficient
overlap. Also, of course, the darkest (shortest exposure time) image
should not contain any very bright pixels, and the brightest one
(longest exposure time) no very dark ones. So if e.g. your brightest
image was taken with 1/2sec and has significant pixel values below 20,
take one more with 1sec time.
Cheers, Lars.
_______________________________________________
HDRI mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/hdri
Hi Raquel,
I think there is a misunderstanding here. I am sure that the
documentation you refer to is related to the source images. These are
8-bit coded, and allow values from 0-255. This means that below 20 and
over 200 you get into the edges of this range. As the jpg's you get from
a digital camera are not linear mappings from luminance to pixel values,
and a slight change in these edge pixel values is related to a huge
change in the luminance of the recorded scene, it gets impossible to
reconstruct luminance values from such values. Have a look at the
s-shaped response curve of your camera, it should explain this problem.
So hdr tools can use only this "middle" range, and this means that you
must make sure that the ranges of your overlap have a sufficient
overlap. Also, of course, the darkest (shortest exposure time) image
should not contain any very bright pixels, and the brightest one
(longest exposure time) no very dark ones. So if e.g. your brightest
image was taken with 1/2sec and has significant pixel values below 20,
take one more with 1sec time.
Lars is absolutely correct in what he is saying. WebHDR is mostly concerned with using HDR for (reasonably) reliable luminance measurements, so it's important that the entire dynamic range of the scene is captured in the photos. When you tone-map a scene with very bright lights (electric lighting fittings), then in theory you should be able to see details of those light sources: filaments in tungsten lamps, the uneven luminance of diffusers, mirror images of the lamps on the reflector etc. If, however, on the darkest image (shortest exposure), some or all parts of the bright sources are either over-exposed (they have a value of 255 in the JPEG), or even if they are above 200, then the HDR engine can't reliably work out the true luminance and will simply cut it off.
In reality, the HDR stitcher will even produce an HDR image from JPEGs that have only slightly different exposures. It'll work, but will be useless for our particular application. If you use HDR for anything other than luminance measurement, and find that the results are visually pleasing, you may simply ignore this 20/200 rule.
For a while, WebHDR did actually display the dynamic range of the HDR image (the more the better: I was even thinking about implementing an all-time highscore list!), but then decided to remove it. The lowest luminance values in an image (below desks, in dark corners) are too much affected by camera noise, so it didn't really say a lot about the quality of the HDR. So in a sense, the 200-rule is more important than the 20-rule, but depending on your application, feel free to ignore both.
I actually don't remember where I got this 20/200 from, maybe Greg hinted at it in a message on this list, or I might have read it in the HDR book. I didn't make it up, though. Honestly!
Regards
Axel
Hi Lars, Oguz, Axel,
Thanks for your emails.
Yes, I intend to obtain luminance values from my HDRs, that the reason
for asking and making sure I'm using the right range. It's all clear to
me now.
Thanks,
Raquel
···
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Axel Jacobs
Sent: 09 September 2009 22:32
To: [email protected]
Subject: [HDRI] Re: RGB values out of range
Hi Raquel,
I think there is a misunderstanding here. I am sure that the
documentation you refer to is related to the source images. These are
8-bit coded, and allow values from 0-255. This means that below 20
and
over 200 you get into the edges of this range. As the jpg's you get
from
a digital camera are not linear mappings from luminance to pixel
values,
and a slight change in these edge pixel values is related to a huge
change in the luminance of the recorded scene, it gets impossible to
reconstruct luminance values from such values. Have a look at the
s-shaped response curve of your camera, it should explain this
problem.
So hdr tools can use only this "middle" range, and this means that
you
must make sure that the ranges of your overlap have a sufficient
overlap. Also, of course, the darkest (shortest exposure time) image
should not contain any very bright pixels, and the brightest one
(longest exposure time) no very dark ones. So if e.g. your brightest
image was taken with 1/2sec and has significant pixel values below
20,
take one more with 1sec time.
Lars is absolutely correct in what he is saying. WebHDR is mostly
concerned with using HDR for (reasonably) reliable luminance
measurements, so it's important that the entire dynamic range of the
scene is captured in the photos. When you tone-map a scene with very
bright lights (electric lighting fittings), then in theory you should be
able to see details of those light sources: filaments in tungsten lamps,
the uneven luminance of diffusers, mirror images of the lamps on the
reflector etc. If, however, on the darkest image (shortest exposure),
some or all parts of the bright sources are either over-exposed (they
have a value of 255 in the JPEG), or even if they are above 200, then
the HDR engine can't reliably work out the true luminance and will
simply cut it off.
In reality, the HDR stitcher will even produce an HDR image from JPEGs
that have only slightly different exposures. It'll work, but will be
useless for our particular application. If you use HDR for anything
other than luminance measurement, and find that the results are visually
pleasing, you may simply ignore this 20/200 rule.
For a while, WebHDR did actually display the dynamic range of the HDR
image (the more the better: I was even thinking about implementing an
all-time highscore list!), but then decided to remove it. The lowest
luminance values in an image (below desks, in dark corners) are too much
affected by camera noise, so it didn't really say a lot about the
quality of the HDR. So in a sense, the 200-rule is more important than
the 20-rule, but depending on your application, feel free to ignore
both.
I actually don't remember where I got this 20/200 from, maybe Greg
hinted at it in a message on this list, or I might have read it in the
HDR book. I didn't make it up, though. Honestly!
Regards
Axel
_______________________________________________
HDRI mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/hdri