|
 |
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] iname com
* to Hyde... * http://www.enst.fr/~jberger
*******************************
Post a reply to this message
|
|
|
|
<Jer### [at] enstfr> wrote:
> 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?
A spline? I am working on a post_process filter which adjusts each
channel with a spline, which should easily be able to do what you are
talking about.
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
