Christopher James Huff wrote:

> raw_image filter restores the full float precision colors). Don't know 
> of any workaround for 3.5 though, you would have to use an external 
> program.

Wouldn't POV-Ray itself be able to read a 48 bits PNG ?

(you render in a 48 bits PNG, you use it as an image_map
  that fits exactly the screen, and you process it using
  eval_pigment and reconsturct the image with colored
  boxes)

Fabien.

Post a reply to this message

In article <3d3c72af@news.povray.org> , "Gilles Tran" <tra### [at] inapginrafr>
wrote:

> They'll surely look better at the final full res of 6000*8000 which is
> rendering now.

What render time do you expect for it?  A week?

> - Regrets : the lighting. I had a lot of trouble with it, as the original
> image
> is not very gamma-tolerant : it looked ugly on low-gamma monitors and much
> too dark on others. I had to find a middle way so I tweaked the tones in
> post-process and some colors were lost (and there's some extra graininess
> too). I hope it looks right on your PC or Mac.

It looks good on Macs.

I have to say the image looks really, really great!!!  Nearly perfect,
except imho the shadow of the tree seems like it is a bit to far to the
left.  Maybe moving the shadow about ten pixels to the right would make it
look even better...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

3d3dbc1e@news.povray.org...
> What render time do you expect for it?  A week?

About it. Less in fact, but I'll probably have to re-render little parts of
it with better radiosity settings and area_light settings.

> I have to say the image looks really, really great!!!  Nearly perfect,
> except imho the shadow of the tree seems like it is a bit to far to the
> left.  Maybe moving the shadow about ten pixels to the right would make it
> look even better...

Hmm, yes, you're right. I can still change it (still 60% to go on the large
render).

BTW, the main tree has its own light group with its own sun at a different
position that the main one, so that I could get both some direct light on
the trunk (from the light_group) and a highlight on the water (from the main
light)...

G.

--

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

Fabien Mosen wrote:
> Christopher James Huff wrote:
>
> > raw_image filter restores the full float precision colors). Don't know
> > of any workaround for 3.5 though, you would have to use an external
> > program.
>
> Wouldn't POV-Ray itself be able to read a 48 bits PNG ?
>
> (you render in a 48 bits PNG, you use it as an image_map
>   that fits exactly the screen, and you process it using
>   eval_pigment and reconsturct the image with colored
>   boxes)
>
> Fabien.

Isn't this a case of 'When all you have is a hammer everything starts to
look like a nail'? ;)
It sounds like a brilliant idea, still.

--
-Jide

Post a reply to this message

In article <3D3### [at] skynetbe>,
 Fabien Mosen <fab### [at] skynetbe> wrote:

> Wouldn't POV-Ray itself be able to read a 48 bits PNG ?
> 
> (you render in a 48 bits PNG, you use it as an image_map
>   that fits exactly the screen, and you process it using
>   eval_pigment and reconsturct the image with colored
>   boxes)

If you really want to do image processing of a large image in the POV 
language...it will be very, very slow.

A better solution: use the image_map on a plane or box with ambient 1, 
an orthographic camera and no light sources, and the curves post_process 
filter. The raw_image filter won't be of any help here, since the data 
has already been put through a PNG file. You will lose data for color 
values >1, and will only get 16 bits per channel instead of the float 
precision the post_process filters have access to...basically, MegaPOV 
will be as limited as any other external program.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

On Tue, 23 Jul 2002 22:19:34 +0200, Fabien Mosen
<fab### [at] skynetbe> wrote:

>Wouldn't POV-Ray itself be able to read a 48 bits PNG ?
>
>(you render in a 48 bits PNG, you use it as an image_map
>  that fits exactly the screen, and you process it using
>  eval_pigment and reconsturct the image with colored
>  boxes)

I'd rather use a function pigment for that - much faster than parsing
a gazillion boxes.


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

Post a reply to this message

> I'd rather use a function pigment for that - much faster than parsing
> a gazillion boxes.

To use boxes for postwork within Pov-Ray is exactly what I did in my last
two IRTC entries.
The method is awfully slow (compared with photoshop) and needs huge amounts
of memory
(a 1200*1600 render would need more than 1 GB !).

How can I use functions instead of pigments? I tried and failed so far.


Norbert

Post a reply to this message

In article <4vnrju8p4dnopfhb4ckuc4narsdevjg2j5@4ax.com>,
 Peter Popov <pet### [at] vipbg> wrote:

> >(you render in a 48 bits PNG, you use it as an image_map
> >  that fits exactly the screen, and you process it using
> >  eval_pigment and reconsturct the image with colored
> >  boxes)
> 
> I'd rather use a function pigment for that - much faster than parsing
> a gazillion boxes.

That's a good idea...you could do the same thing as the post_process 
curves filter without needing the patch, though it would still have the 
limitations of what you can put through a PNG file. A image_map pigment 
function run through three spline functions and combined into the final 
image with an average pigment would do the trick:

#declare imgFn = function {pigment {image_map {...}}}
#declare rCurveFn = function {spline {...}}
#declare gCurveFn = function {spline {...}}
#declare bCurveFn = function {spline {...}}

...
pigment {average
    pigment_map {
        [pigment {function {rCurveFn(imgFn(x, y, z).red).x}
            color_map {[0 rgb 0][1 rgb < 3, 0, 0>]}}]
        [pigment {function {gCurveFn(imgFn(x, y, z).green).x}
            color_map {[0 rgb 0][1 rgb < 0, 3, 0>]}}]
        [pigment {function {bCurveFn(imgFn(x, y, z).blue).x}
            color_map {[0 rgb 0][1 rgb < 0, 0, 3>]}}]
    }
}

I used three splines here to make it easier to adjust each channel 
separately, since splines use vectors you should be able to use just one 
spline. You could also do things like use a spline value to scale the 
color according to the brightness of the color.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

On Mon, 22 Jul 2002 23:05:20 +0200, "Gilles Tran" <tra### [at] inapginrafr> wrote:
> - Rendered with povray 3.5

Respect!

ABX

Post a reply to this message

Christopher James Huff wrote:

> That's a good idea...you could do the same thing as the post_process 
> curves filter without needing the patch, though it would still have the 
> limitations of what you can put through a PNG file.

What's the bit-depth limit ?

Fabien.

Post a reply to this message