 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| High Dynamic Range Environment Mapping On Mainstream Graphics Hardware |
|
 |
SirKnight Member since: 1/7/2001 |
|||
 Posted - 2/22/2005 6:17:55 PM |
||||
| I'm having some issues running this demo. At first it would crash but then I realized I needed to comment out that define since my Athlon XP does not support SSE2. I did that and the program runs but it looks extremely fudged. The screen is mostly black with some wierdly colored squares in various places. My specs are AMD Athlon XP 2600, 512MB ram, GeForce 6800 GT w/ 66.93 drivers and WinXP Pro SP2. -SirKnight |
||||
|
||||
|
SirKnight Member since: 1/7/2001 |
|||
 Posted - 2/22/2005 7:33:48 PM |
||||
| Also I think Figure 1 is wrong. What the description says does not correlate to what the picture is. I think the two images are supposed to be swapped. |
||||
|
||||
|
bleyblue2 Member since: 11/5/2004 |
|||
|
Posted - 2/22/2005 9:01:12 PM |
||||
| I think figure 1 is wrong too. |
||||
|
||||
|
qazlop Member since: 1/4/2005 |
|||
|
Posted - 2/22/2005 11:32:23 PM |
||||
| figure 1 is completly wrong. Both images are HDR since they are taken with a camera. One exposed for indoor detail (ie the darker stuff) and the other image exposed to retain the detail of the brighter areas. The caption should be changed to refect this. A better example would be to show to compter images. one with HDR rendering and the ability to change the exposure while maintaing a consistent and correct rendering (the main reason HDR rendering is worth anything), and a computer image that does not use HDR rendering thus is cant express changes in intensity as well. Non hdr games would have the combination of the two shown images. Clear outside AND inside colors objects which clearly wrong. It is the reason HDR is being used. Not to make the scene darker so you can see the overbright areas like yoru figure suggests, but to be able to dynamicaly decide a good exposure so that when you are closer to the window, the inside gets darker and you can see the details outside. However in the camera position you show, the left image is closer to what game devs would display ingame using HDR. |
||||
|
||||
 |
Emmanuel Deloget GDNet News Lead Member since: 8/27/2003 From: France |
|||
 Posted - 2/23/2005 3:26:27 AM |
||||
Quote: @qazlop: No offense intented but you are wrong. Fig1 is completely right. It basically says that even if you are saturating (clamping) the HDR is used to improve the dynamic range of an image. it has its use in videogames but it also has its use in the photo industry too, which I'm part of at this time - and where I'm constantly playing with 12 or 14 bits-per-color images. There are a lot of reasons why we use HDR in the photo industry. One of them is to take advantages of this improved dynamic range to continue to hold informations in the very dark or very light areas of the photo. That's clearly what is demonstrated here. I tend to prefer a "I think fig1 is wrong" to a plain "fig1 is completely wrong". Especially when it is not true. Yours, [Edited by - Emmanuel Deloget on February 24, 2005 1:26:17 AM] -- Emmanuel D. [blog, in French] [blog, very bad googlized translation] [NEW: English version of teh blog! (WIP)] |
||||
|
||||
|
SirKnight Member since: 1/7/2001 |
|||
|
Posted - 2/23/2005 9:48:08 PM |
||||
| heh, I just noticed they swapped the images. So we WERE right but it has now been fixed. I thought I wasn't going crazy. -SirKnight |
||||
|
||||
|
Emmanuel Deloget GDNet News Lead Member since: 8/27/2003 From: France |
|||
 Posted - 2/24/2005 2:35:53 AM |
||||
| Oh... Since they are still in the same order that when I saw them first, I have to assume that they were wrong when you posted then. Therefore you were right. And I were right too, but my post was based upon false assumption. I feel stupid.  My apologies. Not to mention that I inverted left and right in my comment, which was useless. You have to do a #define right _left_ #define left _right_ Before reading my answer. That was not intended and is a mistake. I really feel stupid. -- Emmanuel D. [blog, in French] [blog, very bad googlized translation] [NEW: English version of teh blog! (WIP)] |
||||
|
||||
 |
Myopic Rhino Staff Member since: The dawn of time
From: Temecula, CA, United States |
|||
 Posted - 2/24/2005 12:48:16 PM |
||||
| Sorry about that. I swapped the images a little while before your post. |
||||
|
||||
|
Mulligan Member since: 2/11/2002 From: Virginia |
|||
|
Posted - 2/24/2005 2:16:43 PM |
||||
| Good article, I'd like to see more of these |
||||
|
||||
|
qazlop Member since: 1/4/2005 |
|||
|
Posted - 2/25/2005 4:32:19 AM |
||||
| I can see where you are coming from, and probably should not have said completly wrong. I apoligize if I insulted you. I just felt it would confuse some people when they see the blooming effects, and oversaturation used in many games when they are HDR enabled. Many current game devs tend to create the image on the left for their games when using HDR (just check out farcry, the HL2 hdr pics/video, the hdr samples with directx, nvidia demos, etc). The main use of HDR currently is that you have an oversaturate area so you can easily apply bloom effects to it. You know exactly what areas are overbright so such effects becoming easier. Sure you can decrease the exposure so that you get a less saturated image, however this is currently a rare use of HDR. Its used sparingly when you are about to leave a cave so you get that "omg this game is adjusting like my eyes would when I leave a dark area" effect. yes HDR is great in the photo industry. While I am only a hobbyist, I do know a little bit. HDR is useful because you dont have to worry as much about getting the right exposure when taking the image. You get more leeway with the ability to adjust the image and mantain details. Even the possibilty of using such a mapping that both the light and dark areas have equal detail and clarity little over or under stauration. Overall I think the article is great, and probably should had mentioned that in my first post. I tend to jump the gun on critisim in order to improve on things as much as possible. As a side note, there is work of being able to use a regular digital camera that does not support HDR yet HDR images. Basically you snap a few pictures at different exposures and combine them to form a full HDR image. I forget where i read about that, but if i find the link I wil post it here. Since i doubt many of us have a HDR camera since they are quite expensive. |
||||
|
||||
|
SirKnight Member since: 1/7/2001 |
|||
|
Posted - 2/25/2005 1:57:27 PM |
||||
| You can do that with HDR Shop. http://www.debevec.org/HDRShop/ -SirKnight |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 3/15/2005 12:55:46 PM |
||||
| In equation 2, I think the exponent should be before normalization. From this: image_key = (1 / number_of_pixels) * exp( .. ) To this: image_key = exp * ((1 / number_of_pixels)*( .. )) The reason is the expononent becomes larger as the number of pixels with luminance increases. If I change the for loop that sums the lumininace values from this for(int i=0;i sum += (float)log((double)(L_NormalizedFloats[i]+1.0f)); } to this: for(int i=0;i sum += (float)log((double)(L_NormalizedFloats[i%N]+1.0f)); } The program fails because the exponent becomes out of range. But if I do the exponent after normalizing the sum,like this: int RUN = N*10000; for(i=0;i sum += (float)log((double)(L_NormalizedFloats[i%N]+1.0f)); } sum = sum / (RUN); log_avg_L = (1.0f/((float)N)); log_avg_L *= exp(sum); Then I get the right lumininace values no matter what I put for RUN. I am curious if the authors agree? |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 3/15/2005 12:58:43 PM |
||||
| In the above post, the code snippets are fro mthe appendix code. Also, the for loops that are erroneus should be for(i=0; i (less than) RUN; ++i) where RUN is N * (a large number) |
||||
|
||||
 |
Ysaneya GDNet+ Member since: 1/7/2000 From: Brussels, Belgium |
|||
|
Posted - 7/7/2005 8:38:17 AM |
||||
| No offense to the author, but i think this article needs some serious work. It's good in theory, but there are so many subtle errors/imprecisions that it makes it unusable. The most obvious ones i've found: 1. After equation 2, the author is talking of a small delta value to "avoid taking the log of a completely black pixel whose luminance is zero". In the code, the value 1.0 is used. To avoid getting a negative number with the log function, you need to have a number bigger then 1.0, which suggests the code is right. So, why talking of a "small value" when that value should be 1.0 (and is not "small" by my own definition) ? 2. What is the use of the macro "MAX_LUMINANCE" in the code ? It is always equal to "MAX_RGB". 3. Why is the luminance divided by the max. luminance in the code ? This is mentionned nowhere in the article, so it's very confusing. Which one is right ? 4. Back to equation 2, the sum of logarithmic luminances of each pixel is exponentiated. Since this sum is already big, the exponent of it becomes an infinitely big number (NaN). The code has the same problem. Is the division by the amount of pixels supposed to be done before exponentiating as the previous poster suggested ? 5. Finally, the most confusing for me is the part about "Mapping luminance to RGB". So i've got the final luminance. The author suggests to simply multiply it by the RGB float values. I tried to do this but the end result was looking bad (very saturated colors). What am i missing here ? Y. |
||||
|
||||
|
arunvb Member since: 2/28/2000 From: Union City, CA, United States |
|||
|
Posted - 7/9/2005 6:25:01 PM |
||||
| Yes, according to Reinhard's calculation of average luminance in a scene, the sum of the the logs needs to be divided by the number of pixels BEFORE taking the exponent. |
||||
|
||||
|
martix Member since: 4/4/2009 From: montreal, Canada |
|||
|
Posted - 4/4/2009 1:24:57 PM |
||||
hi everybody, does anyone know how to do tone mapping using the brightness and contrast in the gpu with glsl? thanks mart |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
