Josh English wrote:
> 
> Wow. Gilles Tran admits to "no artistical merit" and still produces an amazing
> image.

Artistic merit has just been redefined.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Gilles Tran wrote:
>
> in MP radiosity, a good balance of
> light intensity vs brigthness can give amazingly "good" (meaning visually
> satisfying) results.

There is a way to balance radiosity and light sources after the render
in a photo editor. Since radiosity takes much of the total render time
lets just render it once and tweak it afterwards interactively :) This
is purely for artists to get desired results and ignores the scientific
stuff except gamma :) Yes, can't get rid of that since we are after all
dealing with CRT displays.

We need:

1. Image editor that has additive layer mode and a method of editing
   gamma 1.0 images so that the gamma correction is applied only to
   the displayed image.

2. One render of the scene without assumed_gamma statement with all
   the lights and radiosity on.

3. A render like 2) but without radiosity.

4. Subtract image 3) from image 2). This leaves just the radiosity.


The interactive part:

5. Load image 3) to layer NORAD

6. Load image 2) into a separate layer RAD with additive layer mode.

7. Set the image editor to perform Display_Gamma correction on the fly.

8. Now you can adjust the RAD & NORAD layer transparency, histogram,
   transfer curve, brightness, contrast etc. Try to get what you want
   first with the transparency and histogram operations and then try
   the others.

9. Flatten the image, apply Display_Gamma correction to the image
   data and save.


I tried this with Photoshop to tweak media & lights  but it has a
couple of limitations.

- No additive mode. Screen used instead (it works because there are only
  few overlapping bright areas in the image).
- Gamma correction done with curves adjustment layer so it's fixed.
- Not possible to edit 48bit images.

Have a look: http://hammer.prohosting.com/~kkivisal/splash_layer.zip

Hollywood Gimp is supposed to be able to do this properly when it's ready.


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

Post a reply to this message

Xplo Eristotle wrote:
>
> 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.

The data is clipped to fit the image format. 48bit output with contrast
ratio of about 50 000 is already available and sufficient for the
photosim calculations.


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

Post a reply to this message

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

I think it can, but it needs to take place before the pixel is written to the
file.  POV seems to store the RGB colors as floating point numbers, which should
provide more than enough dynamic range.  Only problem I see is that numbers
greater than one get clipped, which means that you would still need to make an
effort not to have colors in the scene that exceed this.  This isn't all that
hard though...

Looking at the source, I notice that COLOUR is defined as an array of floats, so
that should be 32-bits per color (I think).    So if you knew the point just
before the program changes the color to whatever the bit depth the image is, you
could run it through the exposure or compression filter.  Better yet, store the
image in floating point format for later post-processing filters, but I imagine
that would require quite a chunk of memory or disk space.

-Mike

Post a reply to this message

Kari Kivisalo wrote:
> 
> Xplo Eristotle wrote:
> >
> > 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.
> 
> The data is clipped to fit the image format. 48bit output with contrast
> ratio of about 50 000 is already available and sufficient for the
> photosim calculations.

Um, since when? I know POV-Ray can generate 16-bit heightfields, but I
didn't know it could handle full 48-bit color.

-Xplo

Post a reply to this message

MikeH wrote:
> 
> > 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?
> 
> I think it can, but it needs to take place before the pixel is written to the
> file.  POV seems to store the RGB colors as floating point numbers, which should
> provide more than enough dynamic range.  Only problem I see is that numbers
> greater than one get clipped, which means that you would still need to make an
> effort not to have colors in the scene that exceed this.  This isn't all that
> hard though...

It isn't? Boy, I sure must suck then.. I've had reasonable success
lighting a room with "artificial" lighting, but as soon as I try to open
a door or window and shine sunlight in, my lighting model goes straight
to hell.

I suppose I could adjust the lighting so that the sunlight doesn't
create numbers greater than one, but then my other lights get dimmed
into nonexistence and so does my radiosity. A patch that bends the
luminance in 48 bits *might* fix this, but it seems like a ghastly way
to develop a scene, and I think some kind of adaptive scaling would be
much, much better than clipping.

-Xplo

Post a reply to this message

Xplo Eristotle wrote:
> but I
> didn't know it could handle full 48-bit color.

At least in MP0.5 there is 48bit PNG option. Must be in the
official release too since one of the pov developers is in the
PNG group :)

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

Post a reply to this message

Xplo Eristotle wrote:
>
> I've had reasonable success
> lighting a room with "artificial" lighting, but as soon as I try to open
> a door or window and shine sunlight in, my lighting model goes straight
> to hell.

Don't panic. We'll propably make it work eventually somebody will then
make a tutorial which shows how to set up interior and outdoors scene
using radiosity and dynamic range compression :)


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

Post a reply to this message

In article <39C157EB.210EB232@unforgettable.com>, 
inq### [at] unforgettablecom wrote:

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

I was talking about the "post_process" feature of MegaPOV, *NOT* editing 
in an external program. You can probably do all of what you want using a 
series of the existing filters, or write your own.


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

It stores colors as single-precision floating point values...isn't that 
enough? It is certainly far more than 8-bit...

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

On Thu, 14 Sep 2000 15:58:50 -0700, Xplo Eristotle
<inq### [at] unforgettablecom> wrote:

>Chris Huff wrote:
>> 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).

I am betting 50-50 that the post-process in MP uses the unclipped
color values which are defined as double (I think) or maybe float.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message