Dear list and Hi Greg,
In the recent raw2hdr bundle you packaged for Yulia
http://www.radiance-online.org/pipermail/hdri/2012-February/000363.html
there's a man page for hdrgen that list some options which do not appear in the man page that comes with the LINUX download you have on http://anyhere.com/
I have just discovered that the -x option does actually exist in the LINUX version of hdrgen, which is from around 2006, I think.
In the more recent (MacOS) version, the -x option is described as
"-x Toggle over- and under-exposed image removal. Normally “off,” this option causes unnecessary exposures that are too light or too dark to contribute useful information to be automatically ignored."
I have always lived under the impression that 'useful information' is limited by pixel values of 200 in the darkest JPEG, and 20 (out of 255) in the brightest. I really don't remember where I took this from, but it must have been a post on the hdri list which I am unable to find now. Sorry.
In your message to hdri just recently,
http://www.radiance-online.org/pipermail/hdri/2012-February/000365.html
you stated
"Specifically, all values in the short exposure's histogram should be be below 245."
which is different to the 200 threshold I mentioned above.
I have been experimenting with HDR photography for glare studies (think UGR), and have noticed some discrepancies in the results that one gets if hdrgen is run with and without the -x option. I was therefore wondering what hdrgen considers as
"too light or too dark to contribute useful information". I would think that this is decision is made based on the value of the darkest/brightest pixel in the image. Is this assumption correct, and if so, what are the threshold values that are used with the -x option?
Kind regards
Axel
Hi Axel,
I tend not to use the -x option for critical work, as it's mostly a time-saver as opposed to a way to improve accuracy.
That said, the value range I consider "safe" extends from 27 to 228 in the 8-bit domain. I have found this empirically to be above the noise floor (provided the ISO setting is not too high) and below where some cameras introduce highlight roll-off.
I cannot use a strict cut-off for image values. Up to 0.2% of the pixels below the minimum are ignored and 0.05% of pixels above the maximum, likewise. This avoids issues with stuck pixels, which would otherwise make the -x option useless. This is also why it is better not to use -x for critical work, because you may lose the peak highlight in your image if it happens to be very small.
Note also that hdrgen would never discard an input exposure off the end because it was "in range." Only the exposures shorter than first one below the safe maximum and the exposures longer than last one above the safe minimum that are considered superfluous.
I have a Lubuntu installation running under VMWare with gcc version 4.6.1-9ubuntu3. I could use it to recompile hdrgen if you like, but I'm not sure what machines it would run on....
Cheers,
-Greg
···
From: Axel Jacobs <[email protected]>
Date: February 27, 2012 3:49:40 PM PST
Dear list and Hi Greg,
In the recent raw2hdr bundle you packaged for Yulia
http://www.radiance-online.org/pipermail/hdri/2012-February/000363.html
there's a man page for hdrgen that list some options which do not appear in the man page that comes with the LINUX download you have on http://anyhere.com/
I have just discovered that the -x option does actually exist in the LINUX version of hdrgen, which is from around 2006, I think.
In the more recent (MacOS) version, the -x option is described as
"-x Toggle over- and under-exposed image removal. Normally “off,” this option causes unnecessary exposures that are too light or too dark to contribute useful information to be automatically ignored."
I have always lived under the impression that 'useful information' is limited by pixel values of 200 in the darkest JPEG, and 20 (out of 255) in the brightest. I really don't remember where I took this from, but it must have been a post on the hdri list which I am unable to find now. Sorry.
In your message to hdri just recently,
http://www.radiance-online.org/pipermail/hdri/2012-February/000365.html
you stated
"Specifically, all values in the short exposure's histogram should be be below 245."
which is different to the 200 threshold I mentioned above.
I have been experimenting with HDR photography for glare studies (think UGR), and have noticed some discrepancies in the results that one gets if hdrgen is run with and without the -x option. I was therefore wondering what hdrgen considers as
"too light or too dark to contribute useful information". I would think that this is decision is made based on the value of the darkest/brightest pixel in the image. Is this assumption correct, and if so, what are the threshold values that are used with the -x option?
Kind regards
Axel
Hello Greg,
I tend not to use the -x option for critical work, as it's mostly a time-saver as opposed to a way to improve accuracy.
That said, the value range I consider "safe" extends from 27 to 228 in the 8-bit domain. I have found this empirically to be above the noise floor (provided the ISO setting is not too high) and below where some cameras introduce highlight roll-off.
Interesting. Will have to update the heat map on WebHDR, then. It's
set to 20 and 200 at the moment.
I cannot use a strict cut-off for image values. Up to 0.2% of the pixels below the minimum are ignored and 0.05% of pixels above the maximum, likewise. This avoids issues with stuck pixels, which would otherwise make the -x option useless. This is also why it is better not to use -x for critical work, because you may lose the peak highlight in your image if it happens to be very small.
This is probably what happened with my sequences. Since hdrgen copes
admirably with completely black frames (as far as the human eye can
tell), it's probably best to use them all, rather than make a
pre-selection.
Note also that hdrgen would never discard an input exposure off the end because it was "in range." Only the exposures shorter than first one below the safe maximum and the exposures longer than last one above the safe minimum that are considered superfluous.
I have a Lubuntu installation running under VMWare with gcc version 4.6.1-9ubuntu3. I could use it to recompile hdrgen if you like, but I'm not sure what machines it would run on....
That would be absolutely super-fantastic. I understand from
http://www.hdrlabs.com/news/index.php?id=8369771879810293991
that the ghost removal in Photosphere is now second to none, and that
it can even handle breaking waves and swaying palm trees on tropical
beaches. This is really exciting!
I volunteer to update the man page, if you like.
Thank you so much
Axel
Hi Axel,
Responses inline...
From: Axel Jacobs <[email protected]>
Date: February 27, 2012 11:42:09 PM PST
...
I cannot use a strict cut-off for image values. Up to 0.2% of the pixels below the minimum are ignored and 0.05% of pixels above the maximum, likewise. This avoids issues with stuck pixels, which would otherwise make the -x option useless. This is also why it is better not to use -x for critical work, because you may lose the peak highlight in your image if it happens to be very small.
This is probably what happened with my sequences. Since hdrgen copes
admirably with completely black frames (as far as the human eye can
tell), it's probably best to use them all, rather than make a
pre-selection.
This is more true of the latest code. In some cases, the old version would allow noise from short exposures to leak into the final result. The new code has a couple of different strategies to mitigate this problem.
Note also that hdrgen would never discard an input exposure off the end because it was "in range." Only the exposures shorter than first one below the safe maximum and the exposures longer than last one above the safe minimum that are considered superfluous.
I have a Lubuntu installation running under VMWare with gcc version 4.6.1-9ubuntu3. I could use it to recompile hdrgen if you like, but I'm not sure what machines it would run on....
That would be absolutely super-fantastic. I understand from
http://www.hdrlabs.com/news/index.php?id=8369771879810293991
that the ghost removal in Photosphere is now second to none, and that
it can even handle breaking waves and swaying palm trees on tropical
beaches. This is really exciting!
I don't fully agree with the comment on Christian Bloch's site. I worked on the Photoshop CS5 ghost removal as well, and the algorithm is very similar, with the added ability to control which exposure serves as reference in CS5. It may have worked better on this one example, but I sometimes find myself using Photoshop when Photosphere doesn't do what I want it to.
I've fooled around with compiling a bit now, and I don't know that I can get the TIFF library to build for me under Lubuntu. It will probably be easiest to compile a Linux version of hdrgen that only produces Radiance (.hdr) output. Would this be sufficient?
I volunteer to update the man page, if you like.
I think I have one already, but any fixes you have would be welcome!
Cheers,
-Greg
Hi Greg,
I've fooled around with compiling a bit now, and I don't know that I can get the TIFF library to build for me under Lubuntu. It will probably be easiest to compile a Linux version of hdrgen that only produces Radiance (.hdr) output. Would this be sufficient?
Yes, it would. I have never churned out TIFFs -- quite happy with
RGBE. Guess that means it can only read JPEGs, too?
Cheers
Axel
No problem, Christian -- I'll take any publicity I can get!
And yes, Photosphere *used* to use different hero exposures for different regions, but I eventually abandoned the approach for something more similar to what I implemented in Photoshop. It doesn't always work better, but 90% of the time it does.
Cheers,
-Greg
···
From: Christian Bloch <[email protected]>
Date: February 28, 2012 8:51:17 AM PST
Hi Greg,
On Feb 28, 2012, at 8:21 AM, Gregory J. Ward wrote:
I don't fully agree with the comment on Christian Bloch's site. I worked on the Photoshop CS5 ghost removal as well, and the algorithm is very similar, with the added ability to control which exposure serves as reference in CS5. It may have worked better on this one example, but I sometimes find myself using Photoshop when Photosphere doesn't do what I want it to.
Sorry to disappoint you, Greg. The brevity of the blog format often forces me to simplify facts in a black-and-white manner, and leave out the more subtle nuances. In this case I was purposely trying to raise awareness for Photosphere, because it is rather underrated among my photographer audience.
From observation it seems that Photoshop tends take the chosen hero exposure very literal, eventually dismissing useful information from the side exposures. Whereas Photosphere seems to be more adaptive in the choice of hero exposures and may pick different ones for different image areas.
Christian Bloch
From observation it seems that Photoshop tends take the chosen hero exposure
very literal, eventually dismissing useful information from the side exposures.
No, that is not the case. Photoshop uses all the exposures that aren't
close to clipped as part of a best fit function.
Chris
···
On 2/28/12 8:51 AM, "Christian Bloch" <[email protected]> wrote:
From observation it seems that Photoshop tends take the chosen hero exposure
very literal, eventually dismissing useful information from the side
exposures.