![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3ee346e3@news.povray.org>,
Lutz-Peter Hooge <lpv### [at] gmx de> wrote:
> > BTW, the TGA format *is* supported, but image maps load it as an
> > ordinary color TGA,
>
> Thats the same as not supported, isn't it?
> Interpolation would scew it up.
No. The interpolation is a weighted average, with the weights
independant of the pixel values. Basically the same goes for the
conversion. It's a very inefficient way to do it, requiring
interpolation of three values when only one would do, but it will work.
ar, ag: red and blue of pixel A
br, bg: red and blue of pixel B
w1, w2: weights of the pixels
Method 1: Combining then interpolating:
(ar*255 + ag)*w1 + (br*255 + bg)*w2
Method 2: Interpolating then combining:
(ar*w1 + br*w2)*255 + (ag*w1 + bg*w2)
Which equals:
ar*w1*255 + br*w2*255 + ag*w1 + bg*w2
Rearrange:
ar*w1*255 + ag*w1 + br*w2*255 + bg*w2
Which equals this, the same as method 1:
(ar*255 + ag)*w1 + (br*255 + bg)*w2
--
Christopher James Huff <cja### [at] earthlink net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tag povray org
http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Lutz-Peter Hooge
Subject: Re: heightfields, 16bit images and isosurfaces
Date: 8 Jun 2003 16:08:34
Message: <3ee397c2$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Christopher James Huff <cja### [at] earthlink net> wrote:
> No. The interpolation is a weighted average, with the weights
> independant of the pixel values. Basically the same goes for the
> conversion. It's a very inefficient way to do it, requiring
> interpolation of three values when only one would do, but it will work.
You're right, it does work.
I uploaded a table with my tests:
<http://www.lutz-peter.hoogi.de/extern/hfield/>
So a POV-generated TGA (or 2 seperate images) seems to be the only way
to get it working.
However it would be much nicer if POV directly supported 16bit PNG
(or TIFF)...
Lutz-Peter
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3ee397c2$1@news.povray.org>,
Lutz-Peter Hooge <lpv### [at] gmx de> wrote:
> I uploaded a table with my tests:
> <http://www.lutz-peter.hoogi.de/extern/hfield/>
I notice you didn't use smoothing on the height field...why?
> So a POV-generated TGA (or 2 seperate images) seems to be the only way
> to get it working.
Since the .hf feature is independant of the file format, you could use
it with other 8-bit color formats as well, you just need a way to
generate them. You could generate a RG-encoded-gray TGA and convert it
to PNG to save space, for example.
> However it would be much nicer if POV directly supported 16bit PNG
> (or TIFF)...
In addition, the whole arrangement of having TGA handled specially in
height fields seems unsatisfactory. For one thing, there are 24 bits
available in most RGB images, but 8 are wasted. Height fields internally
store values as short ints, but there are other uses now such as
isosurfaces, so might as well put that third byte to use.
The hf_gray_16 option generally looks badly designed, it seems really
out of place in global_settings when other file output options are part
of the command line or .ini file. I would have done it as a file output
option useable with any format, and a special toggle to make the height
field load an RG/RGB-encoded-grayscale instead of an ordinary RGB file.
--
Christopher James Huff <cja### [at] earthlink net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tag povray org
http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Thorsten Froehlich
Subject: Re: heightfields, 16bit images and isosurfaces
Date: 8 Jun 2003 18:09:13
Message: <3ee3b409@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <cja### [at] netplex aussie org> ,
Christopher James Huff <cja### [at] earthlink net> wrote:
>> However it would be much nicer if POV directly supported 16bit PNG
>> (or TIFF)...
>
> In addition, the whole arrangement of having TGA handled specially in
> height fields seems unsatisfactory. For one thing, there are 24 bits
> available in most RGB images, but 8 are wasted. Height fields internally
> store values as short ints, but there are other uses now such as
> isosurfaces, so might as well put that third byte to use.
> The hf_gray_16 option generally looks badly designed, it seems really
> out of place in global_settings when other file output options are part
> of the command line or .ini file. I would have done it as a file output
> option useable with any format, and a special toggle to make the height
> field load an RG/RGB-encoded-grayscale instead of an ordinary RGB file.
Yes. These options simply were created over time, and the really relevant
changes were not made in time. In 3.5 a lot of this way changes as support
for true 16 bit grayscale and image data was added. However, the image
reading hasn't been updated to support this yet. Only function images use
this feature so far. For PNG this will be in 3.51, but some of the other
formats don't offer such an easy interface to 16 bit image data that could
be used in POV-Ray :-(
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trf de
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Lutz-Peter Hooge
Subject: Re: heightfields, 16bit images and isosurfaces
Date: 8 Jun 2003 18:50:44
Message: <3ee3bdc4$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Christopher James Huff <cja### [at] earthlink net> wrote:
> I notice you didn't use smoothing on the height field...why?
Because like this it is more comparable to the iso-version.
Also, it doesn't help much in making the 8bit version look better.
Lutz-Peter
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3ee3bdc4$1@news.povray.org>,
Lutz-Peter Hooge <lpv### [at] gmx de> wrote:
> > I notice you didn't use smoothing on the height field...why?
>
> Because like this it is more comparable to the iso-version.
Actually, it would be more comparable. The isosurface isn't composed of
flat surfaces.
> Also, it doesn't help much in making the 8bit version look better.
I see.
i wonder how it would work with the height field macros...their
smoothing function is designed for continuous functions, I never really
tested it with interpolated image maps. It wouldn't fix the stepping
problem, but meshes use single-precision floats to store vertices, which
might be useful if the short integer used in the height field isn't
enough.
--
Christopher James Huff <cja### [at] earthlink net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tag povray org
http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Lutz-Peter Hooge
Subject: Re: heightfields, 16bit images and isosurfaces
Date: 8 Jun 2003 21:18:47
Message: <3ee3e077$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Christopher James Huff <cja### [at] earthlink net> wrote:
> Actually, it would be more comparable. The isosurface isn't composed of
> flat surfaces.
It is composed of _nearly_ (they are flat if the 4 adjactant vertices
are coplanar) flat surfaces when bilinear interpolation is used.
Smoother then unsmoothed height_field, but much less smooth than a
smoothed one.
With "interpolate 4" (normalized distance) they aren't flat anymore, but the
surface isn't continuous. For a really smooth surface something like bicubic
interpolation would be needed.
Lutz-Peter
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Christoph Hormann
Subject: Re: heightfields, 16bit images and isosurfaces
Date: 9 Jun 2003 04:44:17
Message: <3EE44909.EA042497@gmx.de>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Thorsten Froehlich wrote:
>
> [...]For PNG this will be in 3.51, but some of the other
> formats don't offer such an easy interface to 16 bit image data that could
> be used in POV-Ray :-(
As i said for ppm/pgm there is a patch in next MegaPOV.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Lutz-Peter Hooge
Subject: Re: heightfields, 16bit images and isosurfaces
Date: 9 Jun 2003 17:30:47
Message: <3ee4fc87@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Christopher James Huff <cja### [at] earthlink net> wrote:
> Actually, it would be more comparable. The isosurface isn't composed of
> flat surfaces.
Here are some pictures to compare the different interpolations in
isosurfaces.
<http://www.lutz-peter.hoogi.de/extern/hfield/interp.html>
I implemented bicubic as a function, however there is still some problem
with it, causing some artifacts.
btw, is there a reason bicubic interpolation isn't in POV?
Yesterday I succeeded in compiling (Mega-)POV, I think implementing
bicubic interp. would be a good exercise.
Lutz-Peter
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3ee4fc87@news.povray.org>,
Lutz-Peter Hooge <lpv### [at] gmx de> wrote:
> Christopher James Huff <cja### [at] earthlink net> wrote:
>
> > Actually, it would be more comparable. The isosurface isn't composed of
> > flat surfaces.
>
> Here are some pictures to compare the different interpolations in
> isosurfaces.
> <http://www.lutz-peter.hoogi.de/extern/hfield/interp.html>
Normalized distance doesn't work too well for this...interesting result
on the bilinear, I hadn't exactly expected those patches, though it is
obvious now that I think about it. They aren't flat, you can see the
curvature if you have two opposite points "higher" than two others
(where the isosurface shows its diagonals the most strongly), but the
discontinuous normal does make them more comparable to an unsmoothed
isosurface. It is an improvement...I wonder how difficult it would be to
implement a bilinear patch method for the height field primitive...or at
least a better smoothing method. The current one looks far from ideal.
What were the render times like?
> I implemented bicubic as a function, however there is still some problem
> with it, causing some artifacts.
It definitely looks the best.
> btw, is there a reason bicubic interpolation isn't in POV?
> Yesterday I succeeded in compiling (Mega-)POV, I think implementing
> bicubic interp. would be a good exercise.
Only that it isn't implemented. Type 3 is actually "cubic spline", it
just isn't implemented. Similarly, the supported mappings are plane,
sphere, cylinder, and torus, but there are declarations in the code for
parabolic, hyperbolic, and piriform.
--
Christopher James Huff <cja### [at] earthlink net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tag povray org
http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |