ingo wrote:
> 
> The film used here is a slide film, so it's a transfer function
> [scene->transparencey]. 
> 
> > If the transfer from film to paper/transparency is
> >not linear this would have to be modelled too.
> 
> It's not linear, the dynamic range of film is bigger than that of paper.

The maximum contrast ratio of 24bit crt display viewed in low ambient light
is about 170 and a 35mm slide has contrast ratio of over 500. Typical office
lighting reduces crt's contrast ratio down to 5 so it would be better to
model the paper process.

> Some curves of the tri-x b&w negative film

It's good to have someone around who knows about photography :)
This should be of interest to photographers:
http://www.naturalvisionsystems.com

I will now disappear down to my secret laboratory to ponder this new
information. There must have been previous research on this area
so now would be a good time to search for it also.


______________________________________________________________________
Kari Kivisalo                                  http://www.kivisalo.net

Post a reply to this message

In article <39BFD14F.10320EA2@kivisalo.net>, Kari Kivisalo 
<kar### [at] kivisalonet> wrote:

> 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.

This would be better done as a post_process filter(since that is exactly 
what it is). You could probably implement it with the existing add, 
multiply, subtract, divide, and exponent filters.

-- 
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

Steve wrote:

> The one thing that strikes me as being strange is the
> quite clear reflection of the wallpaper on Vickies skirt
> as shown in the attached image.
>
>  [Image]

It puzzled me too (I thought that the shadowy part had become transparent
!) but like GrimDude says it's just a side effect of the dress pattern.
G.

Post a reply to this message

"Tony[B]" wrote:

> Good... dang good. Did you see my pathetic little render of Nick?

I can't see why you say it's pathetic. "White Arnie" tests are fine and
very impressive, but I'd like to see more tests like yours using
radiosity in "real" scenes, where it's certainly more challenging and
requires more (empirical ?) parameter tweaking.
G.

Post a reply to this message

GrimDude wrote:

> I had no idea there were such things as 'Vicki girls' out there.

Victoria, aka Vicky aka Millenium Woman aka Millie, is a poseable
high-resolution female model sold by Zygote to be used in Poser 4. She's big
(the image map for the lashes alone is several Mb), costs 50$, has some birth
defects (look at the strange fold on her right elbow), and square shoulders.
There have been heated discussions in the Poser groups about whether she was
worth the price but the general consensus seems to be that she is. Her mate,
Michael (no alias yet) was born just last week, BTW.

G.

Post a reply to this message

Mael wrote:

> Concerning the artifacts , have you tried to use a small value for
> error_bound ? It works for me (on a very simple test)
> image with error_bound = 0.1 and error_bound = 0.01

I ran a test on a small part of the right wall where artifacts are very
visible, and was very disappointed : not the render time was multiplied
by 8 but there were still artifacts (different ones). However lowering
the error_bound does work in other situations, and there could be a
combination of rad params suitable for this scene.

G.

Post a reply to this message

Kari Kivisalo wrote:

> --------------------------------------------------------------------------
> Computer monitors can display images with contrast ratios 5-170 which
> is quite similar to photographs on paper. My theory is that to get natural
> looking images we should emulate the compression scheme used in photographs
> as a post processing step and use the "scientific settings" on a scene.
> --------------------------------------------------------------------------

Since I've little knowledge in lighting and photography theory, it's hard to
comment on this, but what strikes me is that in MP radiosity, a good balance of
light intensity vs brigthness can give amazingly "good" (meaning visually
satisfying) results. I'm running other interior radiosity tests using a
photograph as comparison and I've been able to reproduce the basic effects very
quickly. The render time is another matter of course...
G.

Post a reply to this message

No, she's not worth $50. :) Moray, or one of David K. Mason's utilities?
Hell, yes. Vicki? No.
AND, of course, we can't forget the IRTC CD-Rom's. Much more valuable IMHO.

Grim

Post a reply to this message

t'ain la vache

--
Rodolphe
galerie: http://www.gelaude.net
          annuaire "Povray Sites"
     http://www.povsite.fr.cf

news://news.newz.net/nzn.fr.3d.pov

Post a reply to this message

Chris Huff wrote:
> 
> In article <39BFD14F.10320EA2@kivisalo.net>, Kari Kivisalo
> <kar### [at] kivisalonet> wrote:
> 
> > 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.
> 
> This would be better done as a post_process filter(since that is exactly
> what it is). You could probably implement it with the existing add,
> multiply, subtract, divide, and exponent filters.

Uh.. no, it wouldn't. If you "photo" post-process an image with only 8
bits of luminance, you're going to end up with hideous round-off errors,
especially at the ends of the scale (if I've been reading this stuff right).

Besides, part of the problem is that POV-Ray is incapable of handling
scenes with high levels of contrast which are meaningful to the human
eye. If it can't generate this much contrast - even algorithmically,
before it ever puts pixel to screen - then how can it possibly extract
an accurate simulation from the crippled data?

You could fake it, maybe, if you did enough tweaking.. but if I'm going
to spend thirty hours trying to make something look more realistic, I'd
rather spend that time on textures or modeling than playing with PP settings.

-Xplo

Post a reply to this message