Kari Kivisalo wrote:
> 
> Christoph Hormann wrote:
> >
> > Kari Kivisalo wrote:
> > >
> > > I have a theory on why these changes were necessary to produce more
> > > pleasing image than the "scientific settings".
> > > [photosim stuff]
> >
> > Sounds reasonable (although i *try* to judge realism from comparing to reality
> > and not to photos).
> 
> What I was saying is that due to the limited dynamic range of computer
> displays reality has to be compressed to fit a monitor. Photographers
> have already done years of research how to compress contrast ratio of
> 100 000 in a real scene down to 100 which is the contrast ratio in a
> good quality glossy photograph. This also happens to be the contrast
> ratio of a good monitor. We can invent the wheel again but is it necessary?
> 
> Until we have displays that can match the real contrast ratios some kind
> of compromise (compression, scaling, chopping, etc.) can't be avoided. Oh,
> and those displays would be useless without at least 48bit input :)
> 
> > What we should not forget is, that the "scientific settings"
> > are only a simplified mathematical model for reality,
> 
> All simulations suffer from this but to me the main goal is not to simulate
> nature down to the tiniest atom. Simulations offer predictability and stability
> so that all the users can be confident that when they use close to real life
> parameters the output will be what one would expect. Just look at the first
> encounters with the official radiosity feature. Every user had to experiment
> with every scene to get decent results. The simulation will get you 80% there,
> the rest is up to the artist (textures, lighting, etc.).
> 
> The photosim feature requires one additional camera parameter: exposure_time.
> This will scale the maximum scene brightness along the transfer curve. There
> could be an automatic feature to set the exposure time by measuring the
> brigtness on certain spots on a scene just like in the real cameras :) The
> scene would be rendered just once and stored as floats and the photosim
> calculations would work on the float values.
> 
	I've been trying to implement something like that as a post_process
effect, but I can't find an acceptable transfer function. Right now I
have either an exponential whith no possiblity to change parameter and a
very small compression range or a rational function whose parameters are
changeable but whose compression range can't be small (and I haven't had
time to test it yet anyway...). Any idea what function I could use?


PS: followups set to unofficial.patches
-- 

* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde...                  * http://www.enst.fr/~jberger
*******************************

Post a reply to this message