 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I don't really grasp what you're doing. Are you
using several dozens of lightsources and some are
really bright (where actual lamps are) and others are
more dim (just for bright surfaces etc), or are you
doing something different?
And how exactly do you prepare it, by hand, or by
some ingenious POV-trace-find-color-put-lightsource
way?
See, I'm nosy. :-)
Regards,
Tim
>
> Here are some attempts to replicate the results of Mael HDRI patch
> with regular image_maps, ambient and radiosity. This is not a try to
> invalidate the need for a patch, but only a search for a way to do it
> with any POV-Ray scene. I liked very much the tests done by Gilles and
> others, but I wanted to do it with something more than a limited set of
> premade HDR maps. And as the only camera that I have is POV...
>
> In my usual lazy-curious way of thinking, I figured that the important
> part here was not the H but the DR. That is, the image used needs to
> have a dinamic brightness. The problem, as Ive said, is that on a
> regular photo (or POV image), the sun and a sheet of paper are both rgb
> 1. But with POV, the scene for the map can be carefully created with a
> "pseudo-dinamyc" brightness, making light sources much brighter than the
> other objetcs on the scene. That is how I've setup the light for a
> spherical shot on the "office" scene, using the resulting image as the
> fake HDRI for the "reflective balls" scene.
>
> Well, not as spectacular as real HDRI, but I needed to keep busy the
> CPU with something while writting the docs for the next version of
> ligthsys...
>
>
> --
> Jaime Vives Piqueres
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 30 Dec 2002 11:33:22 +0100
"Tim Nikias" <tim### [at] gmx de> wrote:
> I don't really grasp what you're doing. Are you
> using several dozens of lightsources and some are
> really bright (where actual lamps are) and others are
> more dim (just for bright surfaces etc), or are you
> doing something different?
> And how exactly do you prepare it, by hand, or by
> some ingenious POV-trace-find-color-put-lightsource
> way?
No, it is a simple image_map, no light sources:
sphere{0,.5 hollow
pigment{
image_map{png "office" map_type 1 interpolate 2}
}
finish{ambient 1}
scale 10e5
}
The only other trick is using radiosity with a recursion limit of 1
and a brightness of 10. The important part for the result is how the
scene for the map shot is setup. In this map scene the lights must be
much brighter than any ohter object, so when mapped on the second scene
the pixels corresponding to the more bright parts behave as"faked"
light sources. The rest of the map also contributes to light the scene,
but much less than these "spots".
Hope it is clear enough... I'm not really good at explaining my fuzzy
mental process. I'm noisy too...
--
Jaime Vives Piqueres
La Persistencia de la Ignorancia
http://www.ignorancia.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:200### [at] ignoranciaorg Jaime Vives
Piqueres wrote:
> No, it is a simple image_map, no light sources:
>
> sphere{0,.5 hollow
> pigment{
> image_map{png "office" map_type 1 interpolate 2}
>
Is it a 8 bit/color image or 16 bit/color?
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 30 Dec 2002 07:25:25 -0500
ingo <ing### [at] tagpovrayorg> wrote:
> Is it a 8 bit/color image or 16 bit/color?
It's a 16 bit png converted from the tga output from POV.
--
Jaime Vives Piqueres
La Persistencia de la Ignorancia
http://www.ignorancia.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jaime Vives Piqueres wrote:
>
> It's a 16 bit png converted from the tga output from POV.
I see two problems. Povray doesn't output 16 bit tgas and
doesn't use the low byte of 16 bit pngs. You might as well
used 8 bit files.
_____________
Kari Kivisalo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 30 Dec 2002 18:50:43 +0200
Kari Kivisalo <pro### [at] luxlabcom> wrote:
> I see two problems. Povray doesn't output 16 bit tgas and
> doesn't use the low byte of 16 bit pngs. You might as well
> used 8 bit files.
Well, you are right, as usual. :)
I've done the experiment without even thinking about how many bits of
color I was using. As I said, I tought that this was not the important
thing. I only looked at it to answer to Ingo.
Anyhow, I've just tried it again directly with the tga, to be sure,
and the result is the same, of course. So, you must be right and POV
only reads 8 bits from the PNG. But, there is a format in wich POV
reads more than 8 bit for a image_map? ...I've tried with different
formats at 8 and 16 bits, but the results look always the same (with
the exception of the crash with TIFF and the "multicolor" results
with PPM).
--
Jaime Vives Piqueres
La Persistencia de la Ignorancia
http://www.ignorancia.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:3E107963.9E8741A9@luxlab.com Kari Kivisalo wrote:
> Povray [...] doesn't use the low byte of 16 bit pngs.
Ah, never realised that :(
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ingo wrote:
>
> > Povray [...] doesn't use the low byte of 16 bit pngs.
>
> Ah, never realised that :(
It's easy to test.
// test.pov
// +fn16 +kff2
global_settings{assumed_gamma 2.2}
camera{
orthographic location -z up y right x
direction z look_at 0 translate <0.5,0.5,0>
}
#declare M=64; // up to 256 the gradient should be smooth
#if(clock<0.5)
plane{z,0 pigment{gradient y color_map{[0 rgb 0][1 rgb 1]}}
finish{ambient 1/M}}
#else
plane{z,0 pigment{image_map{png "test1.png"}} finish{ambient M}}
#end
_____________
Kari Kivisalo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kari Kivisalo wrote:
>
> ingo wrote:
> >
> > > Povray [...] doesn't use the low byte of 16 bit pngs.
> >
> > Ah, never realised that :(
>
> It's easy to test.
>
And should be possible to fix.
(png_pov.cpp, function PNG_Image::Read_Line)
BTW, does anyone know why it says:
line_data[col][pRED] = (DBL)row_ptr[j] / 255.0;
and not
line_data[col][pRED] = (COLC)row_ptr[j] / 255.0;
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 31 Dec. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3E11B0B9.42C8FAEF@gmx.de> , Christoph Hormann
<chr### [at] gmxde> wrote:
> BTW, does anyone know why it says:
>
> line_data[col][pRED] = (DBL)row_ptr[j] / 255.0;
>
> and not
>
> line_data[col][pRED] = (COLC)row_ptr[j] / 255.0;
No, but note that it does not make a difference.
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
|
|
| |
| |
|
|
|
|
| |
