Thread: RE: [Algorithms] Dynamic Gamma / Tone Mapping
Brought to you by:
vexxed72
From: Wolfgang E. <wengel@RockstarSanDiego.com> - 2005-11-29 01:09:43
|
For tone mapping you want also to look into High Dynamic Range Lighting example in the DirectX SDK. As far as I can see many post-processing pipelines uses a HDR approach that follows the papers by Eric Rheinhard from 2002 and/or with new ideas from his 2005 paper. Regarding gamma control. If you want to do lighting/texture filtering in gamma 1.0 you can move all the textures as a pre-processing step to gamma 1.0 and then at the end of the post-processing pipeline move everything back to gamma 2.2. This last step is pretty easy. You might use something like Color =3D pow(Color, 1.0/2.2); To move the textures to gamma 1.0 you might give Photogenics a try ... - Wolfgang -----Original Message----- From: gda...@li... [mailto:gda...@li...] On Behalf Of David Whatley Sent: Monday, November 28, 2005 4:11 PM To: gda...@li... Subject: [Algorithms] Dynamic Gamma / Tone Mapping Has anyone seen anything done with dynamic gamma or tone mapping that can be done entirely on the GPU. The solution we're using now requires a texture to be locked (read back) onto the CPU for luminance analysis and then a look up table texture updated from that for remapping the colors. That's a readonly lock and a write lock. So the frame rate becomes a high-frequency oscillation... presumably because of GPU stalls? Turning off one or the two locks to test doesn't improve anything...=20 both have to be vanquished. We've not figured out how to really do this all on the GPU but it would seem that someone has probably done this? -- David ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 |
From: Rowan W. <ro...@ir...> - 2005-11-29 03:37:13
|
Yes, we just do all our luminance analysis on the GPU, and output the results into a texture (which is then sampled by the tone mapping pass over the scene). I must admit I cant really think why you would do it on the CPU :) We found the analysis code much easier to write in a pixel shader, coz it makes filtering, clamping etc operations really simple to implement. rowan > -----Original Message----- > From: David Whatley [mailto:da...@pl...]=20 > Sent: Tuesday, 29 November 2005 11:11 AM > To: gda...@li... > Subject: [Algorithms] Dynamic Gamma / Tone Mapping >=20 > Has anyone seen anything done with dynamic gamma or tone=20 > mapping that can be done entirely on the GPU. The solution=20 > we're using now requires a texture to be locked (read back)=20 > onto the CPU for luminance analysis and then a look up table=20 > texture updated from that for remapping the colors. That's a=20 > readonly lock and a write lock. So the frame rate becomes a=20 > high-frequency oscillation... presumably because of GPU stalls? >=20 > Turning off one or the two locks to test doesn't improve anything...=20 > both have to be vanquished. We've not figured out how to=20 > really do this all on the GPU but it would seem that someone=20 > has probably done this? >=20 > -- David >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep=20 > through log files for problems? Stop! Download the new AJAX=20 > search engine that makes searching your log files as easy as=20 > surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 |
From: David W. <da...@pl...> - 2005-11-29 16:32:40
|
I must have mis-spoke then. We're doing dynamic gamma which requires us to do more analysis than just getting an average luminance value. We need the average, the min and max (where min and max are 95% percentile). To do this we look at all the pixels of a downsampled verison of the backbuffer to create histogram of luminance values and then pull off these three key values. There is some clamping of these values (min never goes above 50% etc). Although it's possible to probably do this in a 2.0 pixel shader.. I think... and output it as three components of a texel in a 1x1 texture... the next steps are more difficult to figure out: We have to keep track of a current min/max/average and then animate moving from the current values to the new values over time (with a smooth in/out curve). This part simulates the iris adjusting to light. Not exactly sure how we'd do that on the GPU. After this we have to create a look up texture that remaps values in the 0-255 range to new color values in the 0-255 range (r,g & b). We compute this from the min/max/average and then also a coefficient that lets us bump up the saturation/contrast. The result is a new gamma curve we want the scene to have. Then process the scene against this in a pixel shader (or use hardware gamma if in full screen mode). Does tone mapping achieve the same thing with just a single luminance value? -- David Rowan Wyborn wrote: >Yes, we just do all our luminance analysis on the GPU, and output the >results into a texture (which is then sampled by the tone mapping pass >over the scene). > >I must admit I cant really think why you would do it on the CPU :) We >found the analysis code much easier to write in a pixel shader, coz it >makes filtering, clamping etc operations really simple to implement. > >rowan > > > >>-----Original Message----- >>From: David Whatley [mailto:da...@pl...] >>Sent: Tuesday, 29 November 2005 11:11 AM >>To: gda...@li... >>Subject: [Algorithms] Dynamic Gamma / Tone Mapping >> >>Has anyone seen anything done with dynamic gamma or tone >>mapping that can be done entirely on the GPU. The solution >>we're using now requires a texture to be locked (read back) >>onto the CPU for luminance analysis and then a look up table >>texture updated from that for remapping the colors. That's a >>readonly lock and a write lock. So the frame rate becomes a >>high-frequency oscillation... presumably because of GPU stalls? >> >>Turning off one or the two locks to test doesn't improve anything... >>both have to be vanquished. We've not figured out how to >>really do this all on the GPU but it would seem that someone >>has probably done this? >> >>-- David >> >> >> >>------------------------------------------------------- >>This SF.net email is sponsored by: Splunk Inc. Do you grep >>through log files for problems? Stop! Download the new AJAX >>search engine that makes searching your log files as easy as >>surfing the web. DOWNLOAD SPLUNK! >>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >>_______________________________________________ >>GDAlgorithms-list mailing list >>GDA...@li... >>https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>Archives: >>http://sourceforge.net/mailarchive/forum.php?forum_id=6188 >> >> >> > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_idv37&alloc_id865&op=click >_______________________________________________ >GDAlgorithms-list mailing list >GDA...@li... >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > |
From: Aras P. <ne...@gm...> - 2005-11-29 19:22:09
|
> Although it's possible to probably do this in a 2.0 pixel shader.. I > think... and output it as three components of a texel in a 1x1 texture... > the next steps are more difficult to figure out: Seems to be doable. > We have to keep track of a current min/max/average and then animate movi= ng > from the current values to the new values over time (with a smooth in/out > curve). This part simulates the iris adjusting to light. Not exactly su= re > how we'd do that on the GPU. Maybe similar to the "traditional way" - have two small (1x1) textures: one holds previous values, the other holds current values. You compute current from the previous one and frame delta-time. Take a look at HDRLighting sample in DX SDK or some other places. I'm not sure about the exact formulas you're using on the CPU, but it should be doable on the GPU as well. > After this we have to create a look up texture that remaps values in the > 0-255 range to new color values in the 0-255 range (r,g & b). We compute > this from the min/max/average and then also a coefficient that lets us bu= mp > up the saturation/contrast. The result is a new gamma curve we want the > scene to have. Then process the scene against this in a pixel shader (or > use hardware gamma if in full screen mode). Here you can probably skip this intermediate "calculate texture" step. In the final scene processing pass, you have values of each pixel (coming from the main rendertarget), and currently adapted average/min/max values (all coming from the small 1x1 texture). For each pixel, just do the math. > Does tone mapping achieve the same thing with just a single luminance > value? Not really. What you're doing is some kind of "auto contrast stretch", whereas now-popular Reinhard's tone mapping does not do that. What gives better results - well, that depends on a lot of factors ;) -- Aras 'NeARAZ' Pranckevicius http://nesnausk.org/nearaz | http://nearaz.blogspot.com |
From: Wesley H. <we...@fu...> - 2005-11-29 21:04:22
|
I'm not sure exactly what math you are using, but I'm more-or-less using the technique that Aras suggests (all GPU-based), and it works fine. There's not many calculations you can't do in the ALU with ps_2_0+. As far as the tonemapping curve itself, if the popular Rheinhard approach doesn't fit your needs, you can pick whatever you want. Rheinhard doesn't do a great job preserving contrast when the scene has a fairly low dynamic range, so I've played with ways of tweaking it a bit to not flatten out the curve so much when there's not so much range to play with. Obviously luminance min/max come into play here to determine how much range there is. If the calculation makes you too ALU-bound (unlikely), put some of it in a texture lookup function to shift the load a little. -Wes ----- Original Message ----- From: "Aras Pranckevicius" <ne...@gm...> To: <gda...@li...> Sent: Tuesday, November 29, 2005 2:21 PM Subject: Re: [Algorithms] Dynamic Gamma / Tone Mapping > Although it's possible to probably do this in a 2.0 pixel shader.. I > think... and output it as three components of a texel in a 1x1 texture... > the next steps are more difficult to figure out: Seems to be doable. > We have to keep track of a current min/max/average and then animate moving > from the current values to the new values over time (with a smooth in/out > curve). This part simulates the iris adjusting to light. Not exactly sure > how we'd do that on the GPU. Maybe similar to the "traditional way" - have two small (1x1) textures: one holds previous values, the other holds current values. You compute current from the previous one and frame delta-time. Take a look at HDRLighting sample in DX SDK or some other places. I'm not sure about the exact formulas you're using on the CPU, but it should be doable on the GPU as well. > After this we have to create a look up texture that remaps values in the > 0-255 range to new color values in the 0-255 range (r,g & b). We compute > this from the min/max/average and then also a coefficient that lets us bump > up the saturation/contrast. The result is a new gamma curve we want the > scene to have. Then process the scene against this in a pixel shader (or > use hardware gamma if in full screen mode). Here you can probably skip this intermediate "calculate texture" step. In the final scene processing pass, you have values of each pixel (coming from the main rendertarget), and currently adapted average/min/max values (all coming from the small 1x1 texture). For each pixel, just do the math. > Does tone mapping achieve the same thing with just a single luminance > value? Not really. What you're doing is some kind of "auto contrast stretch", whereas now-popular Reinhard's tone mapping does not do that. What gives better results - well, that depends on a lot of factors ;) -- Aras 'NeARAZ' Pranckevicius http://nesnausk.org/nearaz | http://nearaz.blogspot.com |
From: <c.s...@ph...> - 2005-11-29 09:24:35
|
The CPU needs luminance information in case you want to do the tone = mapping at the front end of the pipeline, ie. scaling light intensities = before they enter the shader constants. This makes exposure control = possible with an RGBA8 render target. Yes, while experimenting with readbacks in the render loop, I noticed = some totally counterintuitive performance behaviours (on the PC). However, if done properly, you can avoid a stall. Do a readback every 2 = frames and issue the commands that copy and read the data directly after = the rendering, but do lock the data 2 frames after it was copied. Doing so, NVperfHUD shows me 0ms CPU wait for GPU (but still some driver = time penalty when the readback is active) cheers Christian -----Original Message----- From: gda...@li... = [mailto:gda...@li...] On Behalf Of = Rowan Wyborn Sent: Tuesday, November 29, 2005 4:37 AM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping Yes, we just do all our luminance analysis on the GPU, and output the results into a texture (which is then sampled by the tone mapping pass over the scene). I must admit I cant really think why you would do it on the CPU :) We found the analysis code much easier to write in a pixel shader, coz it makes filtering, clamping etc operations really simple to implement. rowan > -----Original Message----- > From: David Whatley [mailto:da...@pl...]=20 > Sent: Tuesday, 29 November 2005 11:11 AM > To: gda...@li... > Subject: [Algorithms] Dynamic Gamma / Tone Mapping >=20 > Has anyone seen anything done with dynamic gamma or tone=20 > mapping that can be done entirely on the GPU. The solution=20 > we're using now requires a texture to be locked (read back)=20 > onto the CPU for luminance analysis and then a look up table=20 > texture updated from that for remapping the colors. That's a=20 > readonly lock and a write lock. So the frame rate becomes a=20 > high-frequency oscillation... presumably because of GPU stalls? >=20 > Turning off one or the two locks to test doesn't improve anything...=20 > both have to be vanquished. We've not figured out how to=20 > really do this all on the GPU but it would seem that someone=20 > has probably done this? >=20 > -- David >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep=20 > through log files for problems? Stop! Download the new AJAX=20 > search engine that makes searching your log files as easy as=20 > surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log = files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 |
From: Will V. <wi...@se...> - 2005-11-29 09:49:17
|
Christian Schüler wrote: > The CPU needs luminance information in case you want to do the tone mapping at the front end of the pipeline, ie. scaling light intensities before they enter the shader constants. This makes exposure control possible with an RGBA8 render target. Another useful CPU-side application is programming the gamma ramp, which is another free, cheap way to effectively tone-map RGB8 render targets. You might also be limited by the number of texture inputs to your tone-map shader if you're on Pixel Shader 1.x hardware. On console, we did this by always rendering exactly one frame behind (using fences) which made all the timing stuff easier. At some point in the frame, we locked the luminance texture and read the data, then immediately did the GPU steps to generate it for the next frame - no stalls. All the locks were set up not to wait, so we didn't care if for some reason we did get dirty data - a bit of latency wasn't a problem. If you are going this route, it's interesting to read back more than one pixel's worth of luminance data (e.g. take 4x4 or something like that). You can then sample the middle of the screen separately from the edges, or do other neat things which take cues from the way a camera's metering system works. For the PC, we didn't do use readback at all. Instead, we used the hardware pixel pixel counter to see how much sky was visible, and turned that into luminance. Ideal for a racing game, where you want the going in and out of tunnels to drive your tone-map. Perhaps not enough if you have atom bombs and flashbangs and the like. HTH, Will |
From: Rowan W. <ro...@ir...> - 2005-11-29 22:19:13
|
Speaking of contrast and the Rheinhard approach... Has anyone implemented the contrast preserving "dodge and burn" operator in this paper? We are just using the basic operator, and its tempting to try to do the dodge and burn, but I'm not sure if it will make much difference in practice. rowan > -----Original Message----- > From: Wesley Hunt [mailto:we...@fu...]=20 > Sent: Wednesday, 30 November 2005 8:04 AM > To: gda...@li... > Subject: Re: [Algorithms] Dynamic Gamma / Tone Mapping >=20 > I'm not sure exactly what math you are using, but I'm=20 > more-or-less using the technique that Aras suggests (all=20 > GPU-based), and it works fine. There's not many calculations=20 > you can't do in the ALU with ps_2_0+. >=20 > As far as the tonemapping curve itself, if the popular=20 > Rheinhard approach doesn't fit your needs, you can pick=20 > whatever you want. Rheinhard doesn't do a great job=20 > preserving contrast when the scene has a fairly low dynamic=20 > range, so I've played with ways of tweaking it a bit to not=20 > flatten out the curve so much when there's not so much range=20 > to play with. Obviously luminance min/max come into play here=20 > to determine how much range there is. >=20 > If the calculation makes you too ALU-bound (unlikely), put=20 > some of it in a texture lookup function to shift the load a little. >=20 > -Wes >=20 > ----- Original Message ----- > From: "Aras Pranckevicius" <ne...@gm...> > To: <gda...@li...> > Sent: Tuesday, November 29, 2005 2:21 PM > Subject: Re: [Algorithms] Dynamic Gamma / Tone Mapping >=20 >=20 > > Although it's possible to probably do this in a 2.0 pixel=20 > shader.. I > > think... and output it as three components of a texel in a=20 > 1x1 texture... > > the next steps are more difficult to figure out: >=20 > Seems to be doable. >=20 > > We have to keep track of a current min/max/average and then animate > moving > > from the current values to the new values over time (with a=20 > smooth in/out > > curve). This part simulates the iris adjusting to light. =20 > Not exactly > sure > > how we'd do that on the GPU. >=20 > Maybe similar to the "traditional way" - have two small (1x1) > textures: one holds previous values, the other holds current values. > You compute current from the previous one and frame delta-time. Take a > look at HDRLighting sample in DX SDK or some other places. I'm not > sure about the exact formulas you're using on the CPU, but it should > be doable on the GPU as well. >=20 > > After this we have to create a look up texture that remaps=20 > values in the > > 0-255 range to new color values in the 0-255 range (r,g &=20 > b). We compute > > this from the min/max/average and then also a coefficient=20 > that lets us > bump > > up the saturation/contrast. The result is a new gamma=20 > curve we want the > > scene to have. Then process the scene against this in a=20 > pixel shader (or > > use hardware gamma if in full screen mode). >=20 > Here you can probably skip this intermediate "calculate texture" step. > In the final scene processing pass, you have values of each pixel > (coming from the main rendertarget), and currently adapted > average/min/max values (all coming from the small 1x1 texture). For > each pixel, just do the math. >=20 > > Does tone mapping achieve the same thing with just a single=20 > luminance > > value? >=20 > Not really. What you're doing is some kind of "auto contrast stretch", > whereas now-popular Reinhard's tone mapping does not do that. What > gives better results - well, that depends on a lot of factors ;) >=20 > -- > Aras 'NeARAZ' Pranckevicius > http://nesnausk.org/nearaz | http://nearaz.blogspot.com >=20 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep=20 > through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. =20 > DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 |
From: Peter-Pike S. <pp...@wi...> - 2005-11-30 07:02:07
|
I know that the authors (at least Pete Shirley) were really surprised how well the "simple" operator worked, and felt the high level take home from the paper is that the simple operator works quite well (I've just talked with Pete about this, Erik might have a different opinion...) -Peter-Pike Sloan=20 -----Original Message----- From: gda...@li... [mailto:gda...@li...] On Behalf Of Rowan Wyborn Sent: Tuesday, November 29, 2005 2:19 PM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping Speaking of contrast and the Rheinhard approach... Has anyone implemented the contrast preserving "dodge and burn" operator in this paper? We are just using the basic operator, and its tempting to try to do the dodge and burn, but I'm not sure if it will make much difference in practice. rowan > -----Original Message----- > From: Wesley Hunt [mailto:we...@fu...] > Sent: Wednesday, 30 November 2005 8:04 AM > To: gda...@li... > Subject: Re: [Algorithms] Dynamic Gamma / Tone Mapping >=20 > I'm not sure exactly what math you are using, but I'm more-or-less=20 > using the technique that Aras suggests (all GPU-based), and it works=20 > fine. There's not many calculations you can't do in the ALU with=20 > ps_2_0+. >=20 > As far as the tonemapping curve itself, if the popular Rheinhard=20 > approach doesn't fit your needs, you can pick whatever you want.=20 > Rheinhard doesn't do a great job preserving contrast when the scene=20 > has a fairly low dynamic range, so I've played with ways of tweaking=20 > it a bit to not flatten out the curve so much when there's not so much > range to play with. Obviously luminance min/max come into play here to > determine how much range there is. >=20 > If the calculation makes you too ALU-bound (unlikely), put some of it=20 > in a texture lookup function to shift the load a little. >=20 > -Wes >=20 > ----- Original Message ----- > From: "Aras Pranckevicius" <ne...@gm...> > To: <gda...@li...> > Sent: Tuesday, November 29, 2005 2:21 PM > Subject: Re: [Algorithms] Dynamic Gamma / Tone Mapping >=20 >=20 > > Although it's possible to probably do this in a 2.0 pixel > shader.. I > > think... and output it as three components of a texel in a > 1x1 texture... > > the next steps are more difficult to figure out: >=20 > Seems to be doable. >=20 > > We have to keep track of a current min/max/average and then animate > moving > > from the current values to the new values over time (with a > smooth in/out > > curve). This part simulates the iris adjusting to light. =20 > Not exactly > sure > > how we'd do that on the GPU. >=20 > Maybe similar to the "traditional way" - have two small (1x1) > textures: one holds previous values, the other holds current values. > You compute current from the previous one and frame delta-time. Take a > look at HDRLighting sample in DX SDK or some other places. I'm not=20 > sure about the exact formulas you're using on the CPU, but it should=20 > be doable on the GPU as well. >=20 > > After this we have to create a look up texture that remaps > values in the > > 0-255 range to new color values in the 0-255 range (r,g & > b). We compute > > this from the min/max/average and then also a coefficient > that lets us > bump > > up the saturation/contrast. The result is a new gamma > curve we want the > > scene to have. Then process the scene against this in a > pixel shader (or > > use hardware gamma if in full screen mode). >=20 > Here you can probably skip this intermediate "calculate texture" step. > In the final scene processing pass, you have values of each pixel=20 > (coming from the main rendertarget), and currently adapted=20 > average/min/max values (all coming from the small 1x1 texture). For=20 > each pixel, just do the math. >=20 > > Does tone mapping achieve the same thing with just a single > luminance > > value? >=20 > Not really. What you're doing is some kind of "auto contrast stretch", > whereas now-popular Reinhard's tone mapping does not do that. What=20 > gives better results - well, that depends on a lot of factors ;) >=20 > -- > Aras 'NeARAZ' Pranckevicius > http://nesnausk.org/nearaz | http://nearaz.blogspot.com >=20 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files for problems? Stop! Download the new AJAX search engine that=20 > makes searching your log files as easy as surfing the web. > DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 |
From: Wolfgang E. <wengel@RockstarSanDiego.com> - 2005-11-30 16:54:04
|
I think good ideas for contrast improvements can be found in Erik = Reinhardt's 2005 paper ... just forgot the name, but he also talked on = SIGGRAPH this year about it. You might for example interpolate the luminance of a pixel with the = scene luminance or you might store luminance not for RGB per scene, but = for each color channel separately. This should help with contrast. Anyone tried this? =20 - Wolfgang ________________________________ From: gda...@li... on behalf of = Peter-Pike Sloan Sent: Tue 11/29/2005 11:02 PM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping I know that the authors (at least Pete Shirley) were really surprised how well the "simple" operator worked, and felt the high level take home from the paper is that the simple operator works quite well (I've just talked with Pete about this, Erik might have a different opinion...) -Peter-Pike Sloan -----Original Message----- From: gda...@li... [mailto:gda...@li...] On Behalf Of Rowan Wyborn Sent: Tuesday, November 29, 2005 2:19 PM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping Speaking of contrast and the Rheinhard approach... Has anyone implemented the contrast preserving "dodge and burn" operator in this paper? We are just using the basic operator, and its tempting to try to do the dodge and burn, but I'm not sure if it will make much difference in practice. rowan > -----Original Message----- > From: Wesley Hunt [mailto:we...@fu...] > Sent: Wednesday, 30 November 2005 8:04 AM > To: gda...@li... > Subject: Re: [Algorithms] Dynamic Gamma / Tone Mapping > > I'm not sure exactly what math you are using, but I'm more-or-less > using the technique that Aras suggests (all GPU-based), and it works > fine. There's not many calculations you can't do in the ALU with > ps_2_0+. > > As far as the tonemapping curve itself, if the popular Rheinhard > approach doesn't fit your needs, you can pick whatever you want. > Rheinhard doesn't do a great job preserving contrast when the scene > has a fairly low dynamic range, so I've played with ways of tweaking > it a bit to not flatten out the curve so much when there's not so much > range to play with. Obviously luminance min/max come into play here to > determine how much range there is. > > If the calculation makes you too ALU-bound (unlikely), put some of it > in a texture lookup function to shift the load a little. > > -Wes > > ----- Original Message ----- > From: "Aras Pranckevicius" <ne...@gm...> > To: <gda...@li...> > Sent: Tuesday, November 29, 2005 2:21 PM > Subject: Re: [Algorithms] Dynamic Gamma / Tone Mapping > > > > Although it's possible to probably do this in a 2.0 pixel > shader.. I > > think... and output it as three components of a texel in a > 1x1 texture... > > the next steps are more difficult to figure out: > > Seems to be doable. > > > We have to keep track of a current min/max/average and then animate > moving > > from the current values to the new values over time (with a > smooth in/out > > curve). This part simulates the iris adjusting to light.=20 > Not exactly > sure > > how we'd do that on the GPU. > > Maybe similar to the "traditional way" - have two small (1x1) > textures: one holds previous values, the other holds current values. > You compute current from the previous one and frame delta-time. Take a > look at HDRLighting sample in DX SDK or some other places. I'm not > sure about the exact formulas you're using on the CPU, but it should > be doable on the GPU as well. > > > After this we have to create a look up texture that remaps > values in the > > 0-255 range to new color values in the 0-255 range (r,g & > b). We compute > > this from the min/max/average and then also a coefficient > that lets us > bump > > up the saturation/contrast. The result is a new gamma > curve we want the > > scene to have. Then process the scene against this in a > pixel shader (or > > use hardware gamma if in full screen mode). > > Here you can probably skip this intermediate "calculate texture" step. > In the final scene processing pass, you have values of each pixel > (coming from the main rendertarget), and currently adapted > average/min/max values (all coming from the small 1x1 texture). For > each pixel, just do the math. > > > Does tone mapping achieve the same thing with just a single > luminance > > value? > > Not really. What you're doing is some kind of "auto contrast stretch", > whereas now-popular Reinhard's tone mapping does not do that. What > gives better results - well, that depends on a lot of factors ;) > > -- > Aras 'NeARAZ' Pranckevicius > http://nesnausk.org/nearaz | http://nearaz.blogspot.com > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files for problems? Stop! Download the new AJAX search engine that > makes searching your log files as easy as surfing the web. > DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log = files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 |
From: Rowan W. <ro...@ir...> - 2005-11-30 22:32:38
|
do you have links to either of those papers online? (siggraph or 2005 paper)=20 =20 :) =20 thanks, rowan =20 =20 _____ =20 From: Wolfgang Engel [mailto:gda...@li...] On Behalf Of Wolfgang Engel Sent: Thursday, 1 December 2005 3:52 AM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping =09 =09 I think good ideas for contrast improvements can be found in Erik Reinhardt's 2005 paper ... just forgot the name, but he also talked on SIGGRAPH this year about it. You might for example interpolate the luminance of a pixel with the scene luminance or you might store luminance not for RGB per scene, but for each color channel separately. This should help with contrast. Anyone tried this? =20 - Wolfgang _____ =20 From: gda...@li... on behalf of Peter-Pike Sloan Sent: Tue 11/29/2005 11:02 PM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping =09 =09 I know that the authors (at least Pete Shirley) were really surprised how well the "simple" operator worked, and felt the high level take home from the paper is that the simple operator works quite well (I've just talked with Pete about this, Erik might have a different opinion...) =09 -Peter-Pike Sloan =09 -----Original Message----- From: gda...@li... [mailto:gda...@li...] On Behalf Of Rowan Wyborn Sent: Tuesday, November 29, 2005 2:19 PM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping =09 Speaking of contrast and the Rheinhard approach... Has anyone implemented the contrast preserving "dodge and burn" operator in this paper? We are just using the basic operator, and its tempting to try to do the dodge and burn, but I'm not sure if it will make much difference in practice. =09 rowan =09 > -----Original Message----- > From: Wesley Hunt [mailto:we...@fu...] > Sent: Wednesday, 30 November 2005 8:04 AM > To: gda...@li... > Subject: Re: [Algorithms] Dynamic Gamma / Tone Mapping > > I'm not sure exactly what math you are using, but I'm more-or-less > using the technique that Aras suggests (all GPU-based), and it works > fine. There's not many calculations you can't do in the ALU with > ps_2_0+. > > As far as the tonemapping curve itself, if the popular Rheinhard > approach doesn't fit your needs, you can pick whatever you want. > Rheinhard doesn't do a great job preserving contrast when the scene > has a fairly low dynamic range, so I've played with ways of tweaking > it a bit to not flatten out the curve so much when there's not so much =09 > range to play with. Obviously luminance min/max come into play here to =09 > determine how much range there is. > > If the calculation makes you too ALU-bound (unlikely), put some of it > in a texture lookup function to shift the load a little. > > -Wes > > ----- Original Message ----- > From: "Aras Pranckevicius" <ne...@gm...> > To: <gda...@li...> > Sent: Tuesday, November 29, 2005 2:21 PM > Subject: Re: [Algorithms] Dynamic Gamma / Tone Mapping > > > > Although it's possible to probably do this in a 2.0 pixel > shader.. I > > think... and output it as three components of a texel in a > 1x1 texture... > > the next steps are more difficult to figure out: > > Seems to be doable. > > > We have to keep track of a current min/max/average and then animate > moving > > from the current values to the new values over time (with a > smooth in/out > > curve). This part simulates the iris adjusting to light.=20 > Not exactly > sure > > how we'd do that on the GPU. > > Maybe similar to the "traditional way" - have two small (1x1) > textures: one holds previous values, the other holds current values. > You compute current from the previous one and frame delta-time. Take a =09 > look at HDRLighting sample in DX SDK or some other places. I'm not > sure about the exact formulas you're using on the CPU, but it should > be doable on the GPU as well. > > > After this we have to create a look up texture that remaps > values in the > > 0-255 range to new color values in the 0-255 range (r,g & > b). We compute > > this from the min/max/average and then also a coefficient > that lets us > bump > > up the saturation/contrast. The result is a new gamma > curve we want the > > scene to have. Then process the scene against this in a > pixel shader (or > > use hardware gamma if in full screen mode). > > Here you can probably skip this intermediate "calculate texture" step. > In the final scene processing pass, you have values of each pixel > (coming from the main rendertarget), and currently adapted > average/min/max values (all coming from the small 1x1 texture). For > each pixel, just do the math. > > > Does tone mapping achieve the same thing with just a single > luminance > > value? > > Not really. What you're doing is some kind of "auto contrast stretch", =09 > whereas now-popular Reinhard's tone mapping does not do that. What > gives better results - well, that depends on a lot of factors ;) > > -- > Aras 'NeARAZ' Pranckevicius > http://nesnausk.org/nearaz | http://nearaz.blogspot.com > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log =09 > files for problems? Stop! Download the new AJAX search engine that > makes searching your log files as easy as surfing the web. > DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > =09 =09 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 =09 =09 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 =09 =09 |
From: Wolfgang E. <wengel@RockstarSanDiego.com> - 2005-12-01 00:43:08
|
Yep, the paper title is "Dynamic Range Reduction Inspired by Photoreceptor Physiology". It is published in the IEEE 2005 Vol. 11, No.1 January/February 2005, page 13. A short google search only showed up the IEEE website where you can buy the paper ... I think I bought it from there. Having bought my third paper from this website now, I am thinking about a membership ... =20 - Wolfgang ________________________________ From: gda...@li... [mailto:gda...@li...] On Behalf Of Rowan Wyborn Sent: Wednesday, November 30, 2005 2:32 PM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping do you have links to either of those papers online? (siggraph or 2005 paper)=20 =20 :) =20 thanks, rowan =20 =20 ________________________________ From: Wolfgang Engel [mailto:gda...@li...] On Behalf Of Wolfgang Engel Sent: Thursday, 1 December 2005 3:52 AM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping =09 =09 I think good ideas for contrast improvements can be found in Erik Reinhardt's 2005 paper ... just forgot the name, but he also talked on SIGGRAPH this year about it. You might for example interpolate the luminance of a pixel with the scene luminance or you might store luminance not for RGB per scene, but for each color channel separately. This should help with contrast. Anyone tried this? =20 - Wolfgang ________________________________ From: gda...@li... on behalf of Peter-Pike Sloan Sent: Tue 11/29/2005 11:02 PM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping =09 =09 I know that the authors (at least Pete Shirley) were really surprised how well the "simple" operator worked, and felt the high level take home from the paper is that the simple operator works quite well (I've just talked with Pete about this, Erik might have a different opinion...) =09 -Peter-Pike Sloan =09 -----Original Message----- From: gda...@li... [mailto:gda...@li...] On Behalf Of Rowan Wyborn Sent: Tuesday, November 29, 2005 2:19 PM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping =09 Speaking of contrast and the Rheinhard approach... Has anyone implemented the contrast preserving "dodge and burn" operator in this paper? We are just using the basic operator, and its tempting to try to do the dodge and burn, but I'm not sure if it will make much difference in practice. =09 rowan =09 > -----Original Message----- > From: Wesley Hunt [mailto:we...@fu...] > Sent: Wednesday, 30 November 2005 8:04 AM > To: gda...@li... > Subject: Re: [Algorithms] Dynamic Gamma / Tone Mapping > > I'm not sure exactly what math you are using, but I'm more-or-less > using the technique that Aras suggests (all GPU-based), and it works > fine. There's not many calculations you can't do in the ALU with > ps_2_0+. > > As far as the tonemapping curve itself, if the popular Rheinhard > approach doesn't fit your needs, you can pick whatever you want. > Rheinhard doesn't do a great job preserving contrast when the scene > has a fairly low dynamic range, so I've played with ways of tweaking > it a bit to not flatten out the curve so much when there's not so much =09 > range to play with. Obviously luminance min/max come into play here to =09 > determine how much range there is. > > If the calculation makes you too ALU-bound (unlikely), put some of it > in a texture lookup function to shift the load a little. > > -Wes > > ----- Original Message ----- > From: "Aras Pranckevicius" <ne...@gm...> > To: <gda...@li...> > Sent: Tuesday, November 29, 2005 2:21 PM > Subject: Re: [Algorithms] Dynamic Gamma / Tone Mapping > > > > Although it's possible to probably do this in a 2.0 pixel > shader.. I > > think... and output it as three components of a texel in a > 1x1 texture... > > the next steps are more difficult to figure out: > > Seems to be doable. > > > We have to keep track of a current min/max/average and then animate > moving > > from the current values to the new values over time (with a > smooth in/out > > curve). This part simulates the iris adjusting to light.=20 > Not exactly > sure > > how we'd do that on the GPU. > > Maybe similar to the "traditional way" - have two small (1x1) > textures: one holds previous values, the other holds current values. > You compute current from the previous one and frame delta-time. Take a =09 > look at HDRLighting sample in DX SDK or some other places. I'm not > sure about the exact formulas you're using on the CPU, but it should > be doable on the GPU as well. > > > After this we have to create a look up texture that remaps > values in the > > 0-255 range to new color values in the 0-255 range (r,g & > b). We compute > > this from the min/max/average and then also a coefficient > that lets us > bump > > up the saturation/contrast. The result is a new gamma > curve we want the > > scene to have. Then process the scene against this in a > pixel shader (or > > use hardware gamma if in full screen mode). > > Here you can probably skip this intermediate "calculate texture" step. > In the final scene processing pass, you have values of each pixel > (coming from the main rendertarget), and currently adapted > average/min/max values (all coming from the small 1x1 texture). For > each pixel, just do the math. > > > Does tone mapping achieve the same thing with just a single > luminance > > value? > > Not really. What you're doing is some kind of "auto contrast stretch", =09 > whereas now-popular Reinhard's tone mapping does not do that. What > gives better results - well, that depends on a lot of factors ;) > > -- > Aras 'NeARAZ' Pranckevicius > http://nesnausk.org/nearaz | http://nearaz.blogspot.com > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log =09 > files for problems? Stop! Download the new AJAX search engine that > makes searching your log files as easy as surfing the web. > DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > =09 =09 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 =09 =09 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 =09 =09 |
From: Aaron L. <le...@cs...> - 2005-12-01 02:12:55
|
It looks like you can also get the paper from Erik's web page: http://www.cs.ucf.edu/~reinhard/pubs.html Aaron On 11/30/05, Wolfgang Engel <we...@ro...> wrote: > > Yep, the paper title is "Dynamic Range Reduction Inspired by Photorecepto= r > Physiology". It is published in the IEEE 2005 Vol. 11, No.1January/Februa= ry 2005, page 13. A short google search only showed up the > IEEE website where you can buy the paper ... I think I bought it from the= re. > Having bought my third paper from this website now, I am thinking about a > membership ... > > - Wolfgang > > ------------------------------ > *From:* gda...@li... [mailto: > gda...@li...] *On Behalf Of *Rowan Wybor= n > *Sent:* Wednesday, November 30, 2005 2:32 PM > *To:* gda...@li... > *Subject:* RE: [Algorithms] Dynamic Gamma / Tone Mapping > > do you have links to either of those papers online? (siggraph or 2005 > paper) > > :) > > thanks, > rowan > > > > ------------------------------ > *From:* Wolfgang Engel [mailto: > gda...@li...] *On Behalf Of *Wolfgang > Engel > *Sent:* Thursday, 1 December 2005 3:52 AM > *To:* gda...@li... > *Subject:* RE: [Algorithms] Dynamic Gamma / Tone Mapping > > I think good ideas for contrast improvements can be found in Erik > Reinhardt's 2005 paper ... just forgot the name, but he also talked on > SIGGRAPH this year about it. > You might for example interpolate the luminance of a pixel with the scene > luminance or you might store luminance not for RGB per scene, but for eac= h > color channel separately. > This should help with contrast. Anyone tried this? > > - Wolfgang > > ------------------------------ > *From:* gda...@li... on behalf of > Peter-Pike Sloan > *Sent:* Tue 11/29/2005 11:02 PM > *To:* gda...@li... > *Subject:* RE: [Algorithms] Dynamic Gamma / Tone Mapping > > I know that the authors (at least Pete Shirley) were really surprised > how well the "simple" operator worked, and felt the high level take home > from the paper is that the simple operator works quite well (I've just > talked with Pete about this, Erik might have a different opinion...) > > -Peter-Pike Sloan > > -----Original Message----- > From: gda...@li... > [mailto:gda...@li...<gdalgorithms-list-a= dm...@li...>] > On Behalf Of > Rowan Wyborn > Sent: Tuesday, November 29, 2005 2:19 PM > To: gda...@li... > Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping > > Speaking of contrast and the Rheinhard approach... Has anyone > implemented the contrast preserving "dodge and burn" operator in this > paper? We are just using the basic operator, and its tempting to try to > do the dodge and burn, but I'm not sure if it will make much difference > in practice. > > rowan > > > -----Original Message----- > > From: Wesley Hunt [mailto:we...@fu... <we...@fu...>] > > Sent: Wednesday, 30 November 2005 8:04 AM > > To: gda...@li... > > Subject: Re: [Algorithms] Dynamic Gamma / Tone Mapping > > > > I'm not sure exactly what math you are using, but I'm more-or-less > > using the technique that Aras suggests (all GPU-based), and it works > > fine. There's not many calculations you can't do in the ALU with > > ps_2_0+. > > > > As far as the tonemapping curve itself, if the popular Rheinhard > > approach doesn't fit your needs, you can pick whatever you want. > > Rheinhard doesn't do a great job preserving contrast when the scene > > has a fairly low dynamic range, so I've played with ways of tweaking > > it a bit to not flatten out the curve so much when there's not so much > > > range to play with. Obviously luminance min/max come into play here to > > > determine how much range there is. > > > > If the calculation makes you too ALU-bound (unlikely), put some of it > > in a texture lookup function to shift the load a little. > > > > -Wes > > > > ----- Original Message ----- > > From: "Aras Pranckevicius" <ne...@gm...> > > To: <gda...@li...> > > Sent: Tuesday, November 29, 2005 2:21 PM > > Subject: Re: [Algorithms] Dynamic Gamma / Tone Mapping > > > > > > > Although it's possible to probably do this in a 2.0 pixel > > shader.. I > > > think... and output it as three components of a texel in a > > 1x1 texture... > > > the next steps are more difficult to figure out: > > > > Seems to be doable. > > > > > We have to keep track of a current min/max/average and then animate > > moving > > > from the current values to the new values over time (with a > > smooth in/out > > > curve). This part simulates the iris adjusting to light. > > Not exactly > > sure > > > how we'd do that on the GPU. > > > > Maybe similar to the "traditional way" - have two small (1x1) > > textures: one holds previous values, the other holds current values. > > You compute current from the previous one and frame delta-time. Take a > > > look at HDRLighting sample in DX SDK or some other places. I'm not > > sure about the exact formulas you're using on the CPU, but it should > > be doable on the GPU as well. > > > > > After this we have to create a look up texture that remaps > > values in the > > > 0-255 range to new color values in the 0-255 range (r,g & > > b). We compute > > > this from the min/max/average and then also a coefficient > > that lets us > > bump > > > up the saturation/contrast. The result is a new gamma > > curve we want the > > > scene to have. Then process the scene against this in a > > pixel shader (or > > > use hardware gamma if in full screen mode). > > > > Here you can probably skip this intermediate "calculate texture" step. > > In the final scene processing pass, you have values of each pixel > > (coming from the main rendertarget), and currently adapted > > average/min/max values (all coming from the small 1x1 texture). For > > each pixel, just do the math. > > > > > Does tone mapping achieve the same thing with just a single > > luminance > > > value? > > > > Not really. What you're doing is some kind of "auto contrast stretch", > > > whereas now-popular Reinhard's tone mapping does not do that. What > > gives better results - well, that depends on a lot of factors ;) > > > > -- > > Aras 'NeARAZ' Pranckevicius > > http://nesnausk.org/nearaz | http://nearaz.blogspot.com > > > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > > > files for problems? Stop! Download the new AJAX search engine that > > makes searching your log files as easy as surfing the web. > > DOWNLOAD SPLUNK! > > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files for problems? Stop! Download the new AJAX search engine that > makes searching your log files as easy as surfing the web. DOWNLOAD > SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > |
From: Emanuele S. <in...@fo...> - 2005-12-01 03:01:44
|
RE: [Algorithms] Dynamic Gamma / Tone Mapping A question about the model based on the eye perception, and new = consoles. Considering X360 and PS3 are HDTV-ready and HDTV screens usually have = far higher contrast and luminosity than standard PC monitors or TVs, is = it useful to tone map with that model ? At the end of the day, isn't an HDR scene well represented by a 1000:1 = contrast for most games...? I'm suspecting it's gonna be a waste of cycles. Best, Emanuele Salvucci Maya|Lightwave Game Technical Artist Lscript developer www.forwardgames.com ema...@fo... "#3. He causes things to look different so it would appear time has = passed." -------------------------------------------------------------------------= ------- ----- Original Message -----=20 From: Wolfgang Engel=20 To: gda...@li...=20 Sent: Thursday, December 01, 2005 1:42 AM Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping Yep, the paper title is "Dynamic Range Reduction Inspired by = Photoreceptor Physiology". It is published in the IEEE 2005 Vol. 11, = No.1 January/February 2005, page 13. A short google search only showed = up the IEEE website where you can buy the paper ... I think I bought it = from there. Having bought my third paper from this website now, I am thinking = about a membership ... - Wolfgang -------------------------------------------------------------------------= ----- From: gda...@li... = [mailto:gda...@li...] On Behalf Of = Rowan Wyborn Sent: Wednesday, November 30, 2005 2:32 PM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping do you have links to either of those papers online? (siggraph or 2005 = paper)=20 :) thanks, rowan -------------------------------------------------------------------------= --- From: Wolfgang Engel = [mailto:gda...@li...] On Behalf Of = Wolfgang Engel Sent: Thursday, 1 December 2005 3:52 AM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping I think good ideas for contrast improvements can be found in Erik = Reinhardt's 2005 paper ... just forgot the name, but he also talked on = SIGGRAPH this year about it. You might for example interpolate the luminance of a pixel with the = scene luminance or you might store luminance not for RGB per scene, but = for each color channel separately. This should help with contrast. Anyone tried this? - Wolfgang |
From: Will V. <wi...@se...> - 2005-12-01 07:44:40
|
You always end up needing to store your HDR values into the 8-bit output buffer for scanout, which means doing something to fit the wider range into the narrower one. It might be very simple (e.g. clip to [0, 1]) or it might be more complex, but it has to happen. So HDR implies a tone-map of some kind. Of course, if your HDR scene always looks nice with just a clip or divide-by-constant tone-map, you probably aren't getting any value out of the extra dynamic range. Cheers, Will |
From: Wolfgang E. <wengel@RockstarSanDiego.com> - 2005-12-01 16:23:32
|
The idea is to choose 256 luminance values out of the 64k that are = possible by using 16-bit textures. Choosing the 256 values can happen = over this whole range and under different criteria. You have a = middle-grey value that helps you to emphasize a specific range of = luminance values and with the light adaption result, you move the 256 = values you choose up and down through the 64k luminance value range. So the main idea is to choose the best suitable luminance range that = fits to the scene. The practical problems are - you do not really have 64k luminance values anywhere. The reason for = this is that we do not have the tools and teams do not have necessary = the experience on how to do this. So you end up with a much lower range = of values. - as already mentioned: color contrast gets lost - what I can see in some 360 games now: the light adaption process is = not very precise it stutters sometimes =20 I think the most difficult part about HDR/tone-mapping is to establish = an art pipeline that can produce predictable results. The problem starts = just by using Photoshop. Try to open up a HDR texture with CS2 and save = it ... it took some time until this really worked. At the same time we = tried the latest beta of Photogenics but while trying to adjust the = gamma value we bumped into a bug ............. =20 One of the things I would love to hear is, how VALVE did that for Lost = Coast, but I can understand that they do not want to share this :-) ________________________________ From: gda...@li... on behalf of = Emanuele Salvucci Sent: Wed 11/30/2005 7:01 PM To: gda...@li... Subject: Re: [Algorithms] Dynamic Gamma / Tone Mapping =20 A question about the model based on the eye perception, and new = consoles. =20 Considering X360 and PS3 are HDTV-ready and HDTV screens usually have = far higher contrast and luminosity than standard PC monitors or TVs, is = it useful to tone map with that model ? =20 At the end of the day, isn't an HDR scene well represented by a 1000:1 = contrast for most games...? =20 I'm suspecting it's gonna be a waste of cycles. =20 =20 =20 Best, =20 Emanuele Salvucci Maya|Lightwave Game Technical Artist Lscript developer =20 www.forwardgames.com <http://www.forwardgames.com>=20 ema...@fo... =20 "#3. He causes things to look different so it would appear time has = passed." ________________________________ ----- Original Message -----=20 From: Wolfgang Engel <mailto:wengel@RockstarSanDiego.com> =20 To: gda...@li...=20 Sent: Thursday, December 01, 2005 1:42 AM Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping Yep, the paper title is "Dynamic Range Reduction Inspired by = Photoreceptor Physiology". It is published in the IEEE 2005 Vol. 11, = No.1 January/February 2005, page 13. A short google search only showed = up the IEEE website where you can buy the paper ... I think I bought it = from there. Having bought my third paper from this website now, I am thinking about = a membership ... =20 - Wolfgang ________________________________ From: gda...@li... = [mailto:gda...@li...] On Behalf Of = Rowan Wyborn Sent: Wednesday, November 30, 2005 2:32 PM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping =09 =09 do you have links to either of those papers online? (siggraph or 2005 = paper)=20 =20 :) =20 thanks, rowan =20 =20 =09 =09 ________________________________ From: Wolfgang Engel = [mailto:gda...@li...] On Behalf Of = Wolfgang Engel Sent: Thursday, 1 December 2005 3:52 AM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping =09 =09 I think good ideas for contrast improvements can be found in Erik = Reinhardt's 2005 paper ... just forgot the name, but he also talked on = SIGGRAPH this year about it. You might for example interpolate the luminance of a pixel with the = scene luminance or you might store luminance not for RGB per scene, but = for each color channel separately. This should help with contrast. Anyone tried this? =20 - Wolfgang =20 |
From: Emanuele S. <in...@fo...> - 2005-12-01 17:41:06
|
I agree with the tools. In fact we have custom ones...and use Lightwave = as it's native HDR. (sky generation, volumetric particle baking, to name = a couple) I also agree on the limited dynamic range needed. The original = St.Peter's basilica probe has got a maximum luminance value of ~1100. Not sure what you mean with "color contrast" ...but if you can generate = the whole data in HDR and keep it in realtime, you shouldn't experience = such a loss. What VALVE did on their last "not-quite-HDR show" could be a simple = gamma add operation. Once you have the overall frame's luminance, as said by someone else = previously, you could proceed like this: - RTT the framebuffer - Pass it to a gamma operator (pixel shader) just once - Add the result on a fullscreen quad N times The gamma operator is obviously the key to the desired effect. You might want to have a function that enhances bright values and = darkens midtones when you get a high overall frame luminance, or maybe = the other way around, to never get over-exposed nor pitch-black = lighting....but the latter is against the current common "desired look", = it seems. :) Unless they've dropped lightmapping, I doubt they've used real HDR data = in that demo. As you can see from our website, we instead manage HDR lightmaps, = together with dynamic lighting. Emanuele Salvucci Maya|Lightwave Game Technical Artist Lscript developer www.forwardgames.com ema...@fo... "#3. He causes things to look different so it would appear time has = passed." -------------------------------------------------------------------------= ------- ----- Original Message -----=20 From: "Wolfgang Engel" <wengel@RockstarSanDiego.com> To: <gda...@li...> Sent: Thursday, December 01, 2005 5:23 PM Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping The idea is to choose 256 luminance values out of the 64k that are = possible by using 16-bit textures. Choosing the 256 values can happen = over this whole range and under different criteria. You have a = middle-grey value that helps you to emphasize a specific range of = luminance values and with the light adaption result, you move the 256 = values you choose up and down through the 64k luminance value range. So the main idea is to choose the best suitable luminance range that = fits to the scene. The practical problems are - you do not really have 64k luminance values anywhere. The reason for = this is that we do not have the tools and teams do not have necessary = the experience on how to do this. So you end up with a much lower range = of values. - as already mentioned: color contrast gets lost - what I can see in some 360 games now: the light adaption process is = not very precise it stutters sometimes =20 I think the most difficult part about HDR/tone-mapping is to establish = an art pipeline that can produce predictable results. The problem starts = just by using Photoshop. Try to open up a HDR texture with CS2 and save = it ... it took some time until this really worked. At the same time we = tried the latest beta of Photogenics but while trying to adjust the = gamma value we bumped into a bug ............. =20 One of the things I would love to hear is, how VALVE did that for Lost = Coast, but I can understand that they do not want to share this :-) ________________________________ From: gda...@li... on behalf of = Emanuele Salvucci Sent: Wed 11/30/2005 7:01 PM To: gda...@li... Subject: Re: [Algorithms] Dynamic Gamma / Tone Mapping =20 A question about the model based on the eye perception, and new = consoles. =20 Considering X360 and PS3 are HDTV-ready and HDTV screens usually have = far higher contrast and luminosity than standard PC monitors or TVs, is = it useful to tone map with that model ? =20 At the end of the day, isn't an HDR scene well represented by a 1000:1 = contrast for most games...? =20 I'm suspecting it's gonna be a waste of cycles. =20 =20 =20 Best, =20 Emanuele Salvucci Maya|Lightwave Game Technical Artist Lscript developer =20 www.forwardgames.com <http://www.forwardgames.com>=20 ema...@fo... =20 "#3. He causes things to look different so it would appear time has = passed." ________________________________ ----- Original Message -----=20 From: Wolfgang Engel <mailto:wengel@RockstarSanDiego.com> =20 To: gda...@li...=20 Sent: Thursday, December 01, 2005 1:42 AM Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping Yep, the paper title is "Dynamic Range Reduction Inspired by = Photoreceptor Physiology". It is published in the IEEE 2005 Vol. 11, = No.1 January/February 2005, page 13. A short google search only showed = up the IEEE website where you can buy the paper ... I think I bought it = from there. Having bought my third paper from this website now, I am thinking about = a membership ... - Wolfgang ________________________________ From: gda...@li... = [mailto:gda...@li...] On Behalf Of = Rowan Wyborn Sent: Wednesday, November 30, 2005 2:32 PM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping do you have links to either of those papers online? (siggraph or 2005 = paper)=20 :) thanks, rowan ________________________________ From: Wolfgang Engel = [mailto:gda...@li...] On Behalf Of = Wolfgang Engel Sent: Thursday, 1 December 2005 3:52 AM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping I think good ideas for contrast improvements can be found in Erik = Reinhardt's 2005 paper ... just forgot the name, but he also talked on = SIGGRAPH this year about it. You might for example interpolate the luminance of a pixel with the = scene luminance or you might store luminance not for RGB per scene, but = for each color channel separately. This should help with contrast. Anyone tried this? - Wolfgang |
From: David W. <da...@pl...> - 2005-12-01 17:26:00
|
In our case, we're not using HDR. We're dynamically adapting the scene, 8 bit per component, based on scene luminance. The idea is, of course, to simulate the eyes response to light and dark areas. We have to cap this adaptation because in very dark areas... for example... spreading that out to the full 256 values yields some pretty awful looking stuff. So, for now, we've capped the dynamic range to 50% luminance. So the max won't go below 50% and the min won't go above it. Works sorta good. The issue we're fighting with now is the effect where, as you move about the scene, the virtual iris is constantly adjusting up and down based on the luminance of the scene. That's what its supposed to do... but the problem is that you get this sort of effect whree it seems like there is a bad light bulb in the room somewhere that is constantly dimming and brightening because of bad wiring or something (I get the same effect when a space heater turns on..grin). It's a product of just where you happen to be looking... For example, if the sky is bright... looking down at the ground will cut it out of your view and it will dynamically adjust and the ground colors will blossom. Look straight ahead and 25% of the sky comes into view and it darkens the ground to adjust for the brightness. Now this is "correct" yet looks completely wrong. Emperically, trying this outside with real eyes instead of virtual doesn't give such a dramatic effect. One thing I surmise is that our eyes take in light from a much wider field of view than the "horse blinders" view of a video game. A real iris seems to be adjusted to almost 180 degree FOV (beyond the visual peripheral vision). Further, your eyes can dart around a lot as you look at things so they are getting something of an average luminance input (thus why I said 180 degrees even though that's probably not physically correct for a stationary eye). Perhaps this is part of the problem? If so, how do we compensate for this? Or cheat to keep things more stable as you look around a given area... but still have the nice dramatic effect when going from indoors to outdoors, say. Ideas? -- David Wolfgang Engel wrote: >The idea is to choose 256 luminance values out of the 64k that are possible by using 16-bit textures. Choosing the 256 values can happen over this whole range and under different criteria. You have a middle-grey value that helps you to emphasize a specific range of luminance values and with the light adaption result, you move the 256 values you choose up and down through the 64k luminance value range. >So the main idea is to choose the best suitable luminance range that fits to the scene. The practical problems are >- you do not really have 64k luminance values anywhere. The reason for this is that we do not have the tools and teams do not have necessary the experience on how to do this. So you end up with a much lower range of values. >- as already mentioned: color contrast gets lost >- what I can see in some 360 games now: the light adaption process is not very precise it stutters sometimes > >I think the most difficult part about HDR/tone-mapping is to establish an art pipeline that can produce predictable results. The problem starts just by using Photoshop. Try to open up a HDR texture with CS2 and save it ... it took some time until this really worked. At the same time we tried the latest beta of Photogenics but while trying to adjust the gamma value we bumped into a bug ............. > >One of the things I would love to hear is, how VALVE did that for Lost Coast, but I can understand that they do not want to share this :-) > >________________________________ > >From: gda...@li... on behalf of Emanuele Salvucci >Sent: Wed 11/30/2005 7:01 PM >To: gda...@li... >Subject: Re: [Algorithms] Dynamic Gamma / Tone Mapping > > > >A question about the model based on the eye perception, and new consoles. > >Considering X360 and PS3 are HDTV-ready and HDTV screens usually have far higher contrast and luminosity than standard PC monitors or TVs, is it useful to tone map with that model ? > >At the end of the day, isn't an HDR scene well represented by a 1000:1 contrast for most games...? > >I'm suspecting it's gonna be a waste of cycles. > > > >Best, > >Emanuele Salvucci >Maya|Lightwave >Game Technical Artist >Lscript developer > >www.forwardgames.com <http://www.forwardgames.com> >ema...@fo... > >"#3. He causes things to look different so it would appear time has passed." >________________________________ > > > ----- Original Message ----- > From: Wolfgang Engel <mailto:wengel@RockstarSanDiego.com> > To: gda...@li... > Sent: Thursday, December 01, 2005 1:42 AM > Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping > > Yep, the paper title is "Dynamic Range Reduction Inspired by Photoreceptor Physiology". It is published in the IEEE 2005 Vol. 11, No.1 January/February 2005, page 13. A short google search only showed up the IEEE website where you can buy the paper ... I think I bought it from there. > Having bought my third paper from this website now, I am thinking about a membership ... > > - Wolfgang > >________________________________ > > From: gda...@li... [mailto:gda...@li...] On Behalf Of Rowan Wyborn > Sent: Wednesday, November 30, 2005 2:32 PM > To: gda...@li... > Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping > > > do you have links to either of those papers online? (siggraph or 2005 paper) > > :) > > thanks, > rowan > > > > > >________________________________ > > From: Wolfgang Engel [mailto:gda...@li...] On Behalf Of Wolfgang Engel > Sent: Thursday, 1 December 2005 3:52 AM > To: gda...@li... > Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping > > > I think good ideas for contrast improvements can be found in Erik Reinhardt's 2005 paper ... just forgot the name, but he also talked on SIGGRAPH this year about it. > You might for example interpolate the luminance of a pixel with the scene luminance or you might store luminance not for RGB per scene, but for each color channel separately. > This should help with contrast. Anyone tried this? > > - Wolfgang > > > > |
From: <c.s...@ph...> - 2005-12-01 08:36:09
|
I can hear you there, I'm divided between getting an ACM or an IEEE = subscription.=20 -----Original Message----- From: gda...@li... = [mailto:gda...@li...] On Behalf Of = Wolfgang Engel Sent: Thursday, December 01, 2005 1:43 AM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping =09 =09 Yep, the paper title is "Dynamic Range Reduction Inspired by = Photoreceptor Physiology". It is published in the IEEE 2005 Vol. 11, = No.1 January/February 2005, page 13. A short google search only showed = up the IEEE website where you can buy the paper ... I think I bought it = from there. Having bought my third paper from this website now, I am thinking about = a membership ... =20 - Wolfgang _____ =20 From: gda...@li... = [mailto:gda...@li...] On Behalf Of = Rowan Wyborn Sent: Wednesday, November 30, 2005 2:32 PM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping =09 =09 do you have links to either of those papers online? (siggraph or 2005 = paper)=20 =20 :) =20 thanks, rowan =20 =20 _____ =20 From: Wolfgang Engel = [mailto:gda...@li...] On Behalf Of = Wolfgang Engel Sent: Thursday, 1 December 2005 3:52 AM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping =09 =09 I think good ideas for contrast improvements can be found in Erik = Reinhardt's 2005 paper ... just forgot the name, but he also talked on = SIGGRAPH this year about it. You might for example interpolate the luminance of a pixel with the = scene luminance or you might store luminance not for RGB per scene, but = for each color channel separately. This should help with contrast. Anyone tried this? =20 - Wolfgang _____ =20 From: gda...@li... on behalf of = Peter-Pike Sloan Sent: Tue 11/29/2005 11:02 PM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping =09 =09 I know that the authors (at least Pete Shirley) were really surprised how well the "simple" operator worked, and felt the high level take = home from the paper is that the simple operator works quite well (I've just talked with Pete about this, Erik might have a different opinion...) =09 -Peter-Pike Sloan =09 -----Original Message----- From: gda...@li... [mailto:gda...@li...] On Behalf Of Rowan Wyborn Sent: Tuesday, November 29, 2005 2:19 PM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping =09 Speaking of contrast and the Rheinhard approach... Has anyone implemented the contrast preserving "dodge and burn" operator in this paper? We are just using the basic operator, and its tempting to try = to do the dodge and burn, but I'm not sure if it will make much = difference in practice. =09 rowan =09 > -----Original Message----- > From: Wesley Hunt [mailto:we...@fu...] > Sent: Wednesday, 30 November 2005 8:04 AM > To: gda...@li... > Subject: Re: [Algorithms] Dynamic Gamma / Tone Mapping > > I'm not sure exactly what math you are using, but I'm more-or-less > using the technique that Aras suggests (all GPU-based), and it works > fine. There's not many calculations you can't do in the ALU with > ps_2_0+. > > As far as the tonemapping curve itself, if the popular Rheinhard > approach doesn't fit your needs, you can pick whatever you want. > Rheinhard doesn't do a great job preserving contrast when the scene > has a fairly low dynamic range, so I've played with ways of tweaking > it a bit to not flatten out the curve so much when there's not so = much =09 > range to play with. Obviously luminance min/max come into play here = to =09 > determine how much range there is. > > If the calculation makes you too ALU-bound (unlikely), put some of = it > in a texture lookup function to shift the load a little. > > -Wes > > ----- Original Message ----- > From: "Aras Pranckevicius" <ne...@gm...> > To: <gda...@li...> > Sent: Tuesday, November 29, 2005 2:21 PM > Subject: Re: [Algorithms] Dynamic Gamma / Tone Mapping > > > > Although it's possible to probably do this in a 2.0 pixel > shader.. I > > think... and output it as three components of a texel in a > 1x1 texture... > > the next steps are more difficult to figure out: > > Seems to be doable. > > > We have to keep track of a current min/max/average and then = animate > moving > > from the current values to the new values over time (with a > smooth in/out > > curve). This part simulates the iris adjusting to light.=20 > Not exactly > sure > > how we'd do that on the GPU. > > Maybe similar to the "traditional way" - have two small (1x1) > textures: one holds previous values, the other holds current values. > You compute current from the previous one and frame delta-time. Take = a =09 > look at HDRLighting sample in DX SDK or some other places. I'm not > sure about the exact formulas you're using on the CPU, but it should > be doable on the GPU as well. > > > After this we have to create a look up texture that remaps > values in the > > 0-255 range to new color values in the 0-255 range (r,g & > b). We compute > > this from the min/max/average and then also a coefficient > that lets us > bump > > up the saturation/contrast. The result is a new gamma > curve we want the > > scene to have. Then process the scene against this in a > pixel shader (or > > use hardware gamma if in full screen mode). > > Here you can probably skip this intermediate "calculate texture" = step. > In the final scene processing pass, you have values of each pixel > (coming from the main rendertarget), and currently adapted > average/min/max values (all coming from the small 1x1 texture). For > each pixel, just do the math. > > > Does tone mapping achieve the same thing with just a single > luminance > > value? > > Not really. What you're doing is some kind of "auto contrast = stretch", =09 > whereas now-popular Reinhard's tone mapping does not do that. What > gives better results - well, that depends on a lot of factors ;) > > -- > Aras 'NeARAZ' Pranckevicius > http://nesnausk.org/nearaz | http://nearaz.blogspot.com > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through = log =09 > files for problems? Stop! Download the new AJAX search engine that > makes searching your log files as easy as surfing the web. > DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > =09 =09 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 =09 =09 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log = files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD = SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 =09 =09 |
From: <c.s...@ph...> - 2005-12-01 08:38:50
|
Not if you want to model transitions from the outdoors into dark = cellars. That's more than a 1000:1 adaptation necessary. =20 -----Original Message----- From: gda...@li... = [mailto:gda...@li...] On Behalf Of = Emanuele Salvucci Sent: Thursday, December 01, 2005 4:01 AM To: gda...@li... Subject: Re: [Algorithms] Dynamic Gamma / Tone Mapping =09 =09 =20 A question about the model based on the eye perception, and new = consoles. =20 Considering X360 and PS3 are HDTV-ready and HDTV screens usually have = far higher contrast and luminosity than standard PC monitors or TVs, is = it useful to tone map with that model ? =20 At the end of the day, isn't an HDR scene well represented by a 1000:1 = contrast for most games...? =20 I'm suspecting it's gonna be a waste of cycles. =20 =20 =20 Best, =20 Emanuele Salvucci Maya|Lightwave Game Technical Artist Lscript developer =20 www.forwardgames.com <http://www.forwardgames.com>=20 ema...@fo... =20 "#3. He causes things to look different so it would appear time has = passed." =09 _____ =20 ----- Original Message -----=20 From: Wolfgang Engel <mailto:wengel@RockstarSanDiego.com> =20 To: gda...@li...=20 Sent: Thursday, December 01, 2005 1:42 AM Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping Yep, the paper title is "Dynamic Range Reduction Inspired by = Photoreceptor Physiology". It is published in the IEEE 2005 Vol. 11, = No.1 January/February 2005, page 13. A short google search only showed = up the IEEE website where you can buy the paper ... I think I bought it = from there. Having bought my third paper from this website now, I am thinking = about a membership ... =20 - Wolfgang _____ =20 From: gda...@li... = [mailto:gda...@li...] On Behalf Of = Rowan Wyborn Sent: Wednesday, November 30, 2005 2:32 PM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping =09 =09 do you have links to either of those papers online? (siggraph or 2005 = paper)=20 =20 :) =20 thanks, rowan =20 =20 =09 =09 _____ =20 From: Wolfgang Engel = [mailto:gda...@li...] On Behalf Of = Wolfgang Engel Sent: Thursday, 1 December 2005 3:52 AM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping =09 =09 I think good ideas for contrast improvements can be found in Erik = Reinhardt's 2005 paper ... just forgot the name, but he also talked on = SIGGRAPH this year about it. You might for example interpolate the luminance of a pixel with the = scene luminance or you might store luminance not for RGB per scene, but = for each color channel separately. This should help with contrast. Anyone tried this? =20 - Wolfgang =20 |
From: Wolfgang E. <wengel@RockstarSanDiego.com> - 2005-12-02 18:45:54
|
<<< What VALVE did on their last "not-quite-HDR show" could be a simple gamma add operation. <<< I believe they used HDR textures that are good for 16 different exposure values and as far as I can see they use the same Erik Reinhard tone-mapping operator like most people do. They might work in gamma 1.0, but other than this I would not think that there is something that is surprising from a technical point of view.=20 =20 Overall they managed to get the whole art workflow running and release a complete level that looks great.=20 =20 I saw your website before. I think one guy from your company featured your compressed HDR. =20 - Wolf ________________________________ From: gda...@li... [mailto:gda...@li...] On Behalf Of Emanuele Salvucci Sent: Thursday, December 01, 2005 9:41 AM To: gda...@li... Subject: Re: [Algorithms] Dynamic Gamma / Tone Mapping =20 I agree with the tools. In fact we have custom ones...and use Lightwave as it's native HDR. (sky generation, volumetric particle baking, to name a couple) I also agree on the limited dynamic range needed. The original St.Peter's basilica probe has got a maximum luminance value of ~1100. Not sure what you mean with "color contrast" ...but if you can generate the whole data in HDR and keep it in realtime, you shouldn't experience such a loss. =20 What VALVE did on their last "not-quite-HDR show" could be a simple gamma add operation. Once you have the overall frame's luminance, as said by someone else previously, you could proceed like this: =20 - RTT the framebuffer - Pass it to a gamma operator (pixel shader) just once - Add the result on a fullscreen quad N times =20 The gamma operator is obviously the key to the desired effect. You might want to have a function that enhances bright values and darkens midtones when you get a high overall frame luminance, or maybe the other way around, to never get over-exposed nor pitch-black lighting....but the latter is against the current common "desired look", it seems. :) =20 Unless they've dropped lightmapping, I doubt they've used real HDR data in that demo. =20 As you can see from our website, we instead manage HDR lightmaps, together with dynamic lighting. =20 =20 =20 =20 Emanuele Salvucci Maya|Lightwave Game Technical Artist Lscript developer =20 www.forwardgames.com <http://www.forwardgames.com>=20 ema...@fo... =20 "#3. He causes things to look different so it would appear time has passed." ________________________________ =20 =20 =20 ----- Original Message -----=20 From: "Wolfgang Engel" <wengel@RockstarSanDiego.com <mailto:wengel@RockstarSanDiego.com> > To: <gda...@li... <mailto:gda...@li...> > Sent: Thursday, December 01, 2005 5:23 PM Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping The idea is to choose 256 luminance values out of the 64k that are possible by using 16-bit textures. Choosing the 256 values can happen over this whole range and under different criteria. You have a middle-grey value that helps you to emphasize a specific range of luminance values and with the light adaption result, you move the 256 values you choose up and down through the 64k luminance value range. So the main idea is to choose the best suitable luminance range that fits to the scene. The practical problems are - you do not really have 64k luminance values anywhere. The reason for this is that we do not have the tools and teams do not have necessary the experience on how to do this. So you end up with a much lower range of values. - as already mentioned: color contrast gets lost - what I can see in some 360 games now: the light adaption process is not very precise it stutters sometimes =20 I think the most difficult part about HDR/tone-mapping is to establish an art pipeline that can produce predictable results. The problem starts just by using Photoshop. Try to open up a HDR texture with CS2 and save it ... it took some time until this really worked. At the same time we tried the latest beta of Photogenics but while trying to adjust the gamma value we bumped into a bug ............. =20 One of the things I would love to hear is, how VALVE did that for Lost Coast, but I can understand that they do not want to share this :-) ________________________________ From: gda...@li... <mailto:gda...@li...> on behalf of Emanuele Salvucci Sent: Wed 11/30/2005 7:01 PM To: gda...@li... <mailto:gda...@li...>=20 Subject: Re: [Algorithms] Dynamic Gamma / Tone Mapping =20 A question about the model based on the eye perception, and new consoles. =20 Considering X360 and PS3 are HDTV-ready and HDTV screens usually have far higher contrast and luminosity than standard PC monitors or TVs, is it useful to tone map with that model ? =20 At the end of the day, isn't an HDR scene well represented by a 1000:1 contrast for most games...? =20 I'm suspecting it's gonna be a waste of cycles. =20 =20 =20 Best, =20 Emanuele Salvucci Maya|Lightwave Game Technical Artist Lscript developer =20 www.forwardgames.com <http://www.forwardgames.com> <http://www.forwardgames.com <http://www.forwardgames.com> >=20 ema...@fo... <mailto:ema...@fo...>=20 =20 "#3. He causes things to look different so it would appear time has passed." ________________________________ ----- Original Message -----=20 From: Wolfgang Engel <mailto:wengel@RockstarSanDiego.com <mailto:wengel@RockstarSanDiego.com> > =20 To: gda...@li... <mailto:gda...@li...> =20 Sent: Thursday, December 01, 2005 1:42 AM Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping Yep, the paper title is "Dynamic Range Reduction Inspired by Photoreceptor Physiology". It is published in the IEEE 2005 Vol. 11, No.1 January/February 2005, page 13. A short google search only showed up the IEEE website where you can buy the paper ... I think I bought it from there. Having bought my third paper from this website now, I am thinking about a membership ... - Wolfgang ________________________________ From: gda...@li... <mailto:gda...@li...> [mailto:gda...@li...] On Behalf Of Rowan Wyborn Sent: Wednesday, November 30, 2005 2:32 PM To: gda...@li... <mailto:gda...@li...>=20 Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping do you have links to either of those papers online? (siggraph or 2005 paper)=20 :) thanks, rowan ________________________________ From: Wolfgang Engel [mailto:gda...@li...] On Behalf Of Wolfgang Engel Sent: Thursday, 1 December 2005 3:52 AM To: gda...@li... <mailto:gda...@li...>=20 Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping I think good ideas for contrast improvements can be found in Erik Reinhardt's 2005 paper ... just forgot the name, but he also talked on SIGGRAPH this year about it. You might for example interpolate the luminance of a pixel with the scene luminance or you might store luminance not for RGB per scene, but for each color channel separately. This should help with contrast. Anyone tried this? - Wolfgang |
From: Emanuele S. <in...@fo...> - 2005-12-02 22:03:59
|
In theory, giving a better look at their screenshots, they might have = some HDR lightmaps, but I notice such a resolution from the old times = that makes me think they went for uncompressed RGBE maybe ?! ...you = can't really go up in resolution with lightmaps on PC considering 256 Mb = as the max Vram available on the target platform. Of course they have a great art dept...and they've again managed to get = a good job done. ;) Best, Emanuele Salvucci Maya|Lightwave Game Technical Artist Lscript developer www.forwardgames.com ema...@fo... "#3. He causes things to look different so it would appear time has = passed." -------------------------------------------------------------------------= ------- ----- Original Message -----=20 From: Wolfgang Engel=20 To: gda...@li...=20 Sent: Friday, December 02, 2005 7:45 PM Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping <<< What VALVE did on their last "not-quite-HDR show" could be a simple = gamma add operation. <<< I believe they used HDR textures that are good for 16 different = exposure values and as far as I can see they use the same Erik Reinhard = tone-mapping operator like most people do. They might work in gamma 1.0, = but other than this I would not think that there is something that is = surprising from a technical point of view.=20 Overall they managed to get the whole art workflow running and release = a complete level that looks great.=20 I saw your website before. I think one guy from your company featured = your compressed HDR. - Wolf -------------------------------------------------------------------------= ----- From: gda...@li... = [mailto:gda...@li...] On Behalf Of = Emanuele Salvucci Sent: Thursday, December 01, 2005 9:41 AM To: gda...@li... Subject: Re: [Algorithms] Dynamic Gamma / Tone Mapping I agree with the tools. In fact we have custom ones...and use = Lightwave as it's native HDR. (sky generation, volumetric particle = baking, to name a couple) I also agree on the limited dynamic range needed. The original = St.Peter's basilica probe has got a maximum luminance value of ~1100. Not sure what you mean with "color contrast" ...but if you can = generate the whole data in HDR and keep it in realtime, you shouldn't = experience such a loss. What VALVE did on their last "not-quite-HDR show" could be a simple = gamma add operation. Once you have the overall frame's luminance, as said by someone else = previously, you could proceed like this: - RTT the framebuffer - Pass it to a gamma operator (pixel shader) just once - Add the result on a fullscreen quad N times The gamma operator is obviously the key to the desired effect. You might want to have a function that enhances bright values and = darkens midtones when you get a high overall frame luminance, or maybe = the other way around, to never get over-exposed nor pitch-black = lighting....but the latter is against the current common "desired look", = it seems. :) Unless they've dropped lightmapping, I doubt they've used real HDR = data in that demo. As you can see from our website, we instead manage HDR lightmaps, = together with dynamic lighting. Emanuele Salvucci Maya|Lightwave Game Technical Artist Lscript developer www.forwardgames.com ema...@fo... "#3. He causes things to look different so it would appear time has = passed." -------------------------------------------------------------------------= ----- ----- Original Message -----=20 From: "Wolfgang Engel" <wengel@RockstarSanDiego.com> To: <gda...@li...> Sent: Thursday, December 01, 2005 5:23 PM Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping The idea is to choose 256 luminance values out of the 64k that are = possible by using 16-bit textures. Choosing the 256 values can happen = over this whole range and under different criteria. You have a = middle-grey value that helps you to emphasize a specific range of = luminance values and with the light adaption result, you move the 256 = values you choose up and down through the 64k luminance value range. So the main idea is to choose the best suitable luminance range that = fits to the scene. The practical problems are - you do not really have 64k luminance values anywhere. The reason for = this is that we do not have the tools and teams do not have necessary = the experience on how to do this. So you end up with a much lower range = of values. - as already mentioned: color contrast gets lost - what I can see in some 360 games now: the light adaption process is = not very precise it stutters sometimes =20 I think the most difficult part about HDR/tone-mapping is to establish = an art pipeline that can produce predictable results. The problem starts = just by using Photoshop. Try to open up a HDR texture with CS2 and save = it ... it took some time until this really worked. At the same time we = tried the latest beta of Photogenics but while trying to adjust the = gamma value we bumped into a bug ............. =20 One of the things I would love to hear is, how VALVE did that for Lost = Coast, but I can understand that they do not want to share this :-) ________________________________ From: gda...@li... on behalf of = Emanuele Salvucci Sent: Wed 11/30/2005 7:01 PM To: gda...@li... Subject: Re: [Algorithms] Dynamic Gamma / Tone Mapping =20 A question about the model based on the eye perception, and new = consoles. =20 Considering X360 and PS3 are HDTV-ready and HDTV screens usually have = far higher contrast and luminosity than standard PC monitors or TVs, is = it useful to tone map with that model ? =20 At the end of the day, isn't an HDR scene well represented by a 1000:1 = contrast for most games...? =20 I'm suspecting it's gonna be a waste of cycles. =20 =20 =20 Best, =20 Emanuele Salvucci Maya|Lightwave Game Technical Artist Lscript developer =20 www.forwardgames.com <http://www.forwardgames.com>=20 ema...@fo... =20 "#3. He causes things to look different so it would appear time has = passed." ________________________________ ----- Original Message -----=20 From: Wolfgang Engel <mailto:wengel@RockstarSanDiego.com> =20 To: gda...@li...=20 Sent: Thursday, December 01, 2005 1:42 AM Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping Yep, the paper title is "Dynamic Range Reduction Inspired by = Photoreceptor Physiology". It is published in the IEEE 2005 Vol. 11, = No.1 January/February 2005, page 13. A short google search only showed = up the IEEE website where you can buy the paper ... I think I bought it = from there. Having bought my third paper from this website now, I am thinking = about a membership ... - Wolfgang ________________________________ From: gda...@li... = [mailto:gda...@li...] On Behalf Of = Rowan Wyborn Sent: Wednesday, November 30, 2005 2:32 PM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping do you have links to either of those papers online? (siggraph or 2005 = paper)=20 :) thanks, rowan ________________________________ From: Wolfgang Engel = [mailto:gda...@li...] On Behalf Of = Wolfgang Engel Sent: Thursday, 1 December 2005 3:52 AM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping I think good ideas for contrast improvements can be found in Erik = Reinhardt's 2005 paper ... just forgot the name, but he also talked on = SIGGRAPH this year about it. You might for example interpolate the luminance of a pixel with the = scene luminance or you might store luminance not for RGB per scene, but = for each color channel separately. This should help with contrast. Anyone tried this? - Wolfgang |
From: Newport, M. <mne...@ea...> - 2005-12-02 20:11:18
|
While some screens advertise impressively high contrast ratios not many actually manage to get close to 1000:1 in the real world. Even if they did it's still not enough for many interesting scenes. An outdoor scene on a sunny day with strong shadows can easily hit a 100,000:1 dynamic range and the human visual system can handle an intrascene dynamic range of 10,000-100,000:1. The human eye is limited in the contrast it can handle between immediately adjacent scene elements but within a scene it's quite possible to make out detail in both lit and shadowed areas simultaneously, detail that is impossible to capture in a photo on a conventional display without some tone mapping. If you've tried taking photos at sunset that capture what you can actually see as an observer (detail of both the sky and the foreground at the same time) this becomes pretty obvious. Once you add in the ability to wander around the world and move from dark indoor to bright outdoor areas some kind of tonemapping and adaptation becomes even more important. Proper HDR and tonemapping is definitely not a waste of cycles on an HDTV. =20 Has anyone played PGR3 on the Xbox 360 yet? They have some nice HDR effects (don't know the details of what approach they are using) but when you race on the Nurbugring (sp?) and have to drive in the shadow of the trees it's practically impossible to see the track - I'd have really appreciated a better tonemapping operator there :-) =20 Matt. ________________________________ From: gda...@li... [mailto:gda...@li...] On Behalf Of Emanuele Salvucci Sent: Wednesday, November 30, 2005 7:01 PM To: gda...@li... Subject: Re: [Algorithms] Dynamic Gamma / Tone Mapping =20 A question about the model based on the eye perception, and new consoles. =20 Considering X360 and PS3 are HDTV-ready and HDTV screens usually have far higher contrast and luminosity than standard PC monitors or TVs, is it useful to tone map with that model ? =20 At the end of the day, isn't an HDR scene well represented by a 1000:1 contrast for most games...? =20 I'm suspecting it's gonna be a waste of cycles. =20 =20 =20 Best, =20 Emanuele Salvucci Maya|Lightwave Game Technical Artist Lscript developer =20 www.forwardgames.com <http://www.forwardgames.com>=20 ema...@fo... =20 "#3. He causes things to look different so it would appear time has passed." ________________________________ ----- Original Message -----=20 From: Wolfgang Engel <mailto:wengel@RockstarSanDiego.com> =20 To: gda...@li...=20 Sent: Thursday, December 01, 2005 1:42 AM Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping Yep, the paper title is "Dynamic Range Reduction Inspired by Photoreceptor Physiology". It is published in the IEEE 2005 Vol. 11, No.1 January/February 2005, page 13. A short google search only showed up the IEEE website where you can buy the paper ... I think I bought it from there. Having bought my third paper from this website now, I am thinking about a membership ... =20 - Wolfgang ________________________________ From: gda...@li... [mailto:gda...@li...] On Behalf Of Rowan Wyborn Sent: Wednesday, November 30, 2005 2:32 PM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping =09 =09 do you have links to either of those papers online? (siggraph or 2005 paper)=20 =20 :) =20 thanks, rowan =20 =20 =09 =09 ________________________________ From: Wolfgang Engel [mailto:gda...@li...] On Behalf Of Wolfgang Engel Sent: Thursday, 1 December 2005 3:52 AM To: gda...@li... Subject: RE: [Algorithms] Dynamic Gamma / Tone Mapping =09 =09 I think good ideas for contrast improvements can be found in Erik Reinhardt's 2005 paper ... just forgot the name, but he also talked on SIGGRAPH this year about it. You might for example interpolate the luminance of a pixel with the scene luminance or you might store luminance not for RGB per scene, but for each color channel separately. This should help with contrast. Anyone tried this? =20 - Wolfgang =20 |