 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <879### [at] triton imagicode>,
Christoph Hormann <chr### [at] gmxde> wrote:
> You can use such files in isosurface via image maps but you will have to
> do interpolation manually (or use two separate image files for low and
> high byte).
Wrong. The interpolation will work correctly, and with isosurfaces you
very definitely want it.
> #declare fn_Height=
> function {
> fn_Image(x, y, z).red+fn_Image(x, y, z).green/256
> }
A better way is to simply use fn_Image(x, y, z).hf.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
>
>>You can use such files in isosurface via image maps but you will have to
>>do interpolation manually (or use two separate image files for low and
>>high byte).
>
>
> Wrong. The interpolation will work correctly, and with isosurfaces you
> very definitely want it.
You obviously have never tried it - interpolation in color images does
treat the color channels independantly -> it will mess up such an image.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <36r### [at] tritonimagicode>,
Christoph Hormann <chr### [at] gmxde> wrote:
> > Wrong. The interpolation will work correctly, and with isosurfaces you
> > very definitely want it.
> You obviously have never tried it - interpolation in color images does
> treat the color channels independantly -> it will mess up such an image.
It does interpolate the channels independently, but it doesn't matter.
The interpolated color is a weighted average of the image pixel colors.
Here: (considering only two pixels for simplicity)
Interpolated colors:
w1*red1 + w2*red2
w1*green1 + w2*green2
Channels are combined with: red + green/256
(actually scaled down slightly, but that doesn't matter...it's done
after everything else. And it actually uses 255 when it should use
256...)
So the final grayscale value is:
w1*red1 + w2*red2 + (w1*green1 + w2*green2)/256
Combining channels before interpolating would give:
w1*(red1 + green1/256) + w2*(red2 + green2/256)
==
w1*red1 + w1*green1/256 + w2*red2 + w2*green2/256
==
w1*red1 + w2*red2 + w1*green1/256 + w2*green2/256
==
w1*red1 + w2*red2 + (w1*green1 + w2*green2)/256
Which should look familiar.
Now turning the interpolation off results in a discontinuous
function...the infinite gradients will cause trouble for the isosurface
solver. And while it would be possible to do the interpolation in an
isosurface function, it isn't very feasible.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
>>>Wrong. The interpolation will work correctly, and with isosurfaces you
>>>very definitely want it.
>>
>>You obviously have never tried it - interpolation in color images does
>>treat the color channels independantly -> it will mess up such an image.
>
>
> It does interpolate the channels independently, but it doesn't matter.
> The interpolated color is a weighted average of the image pixel colors.
> Here: (considering only two pixels for simplicity)
>
> Interpolated colors:
> w1*red1 + w2*red2
> w1*green1 + w2*green2
> [...]
I think it would be easier if you'd just try it out and see why it does
not work.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <8k7### [at] tritonimagicode>,
Christoph Hormann <chr### [at] gmxde> wrote:
> I think it would be easier if you'd just try it out and see why it does
> not work.
Ok, I did. My method worked. Yours didn't. The interpolated version does
what's expected, it gives the isosurface a smooth function to work with,
and the result is something that closely resembles the original. The
non-interpolated version also does what is expected...the infinite
gradients result in a surface that is more cracks and gaps than it is
height field.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
From: Pascal
Subject: Re: Leveller 2 and using hf pigments in iso-functions
Date: 17 Jan 2004 05:01:35
Message: <400907ff@news.povray.org>
|
|
|
| |
| |
|
|
879### [at] tritonimagicode...
[cut]
> Note it is quite surely more efficient to use a different image file
> format for this purpose but sadly POV-Ray 3.5 does only support 16 bit
> grayscale image_maps in form of ASCII pgm files. This will be different
> in the next version though.
>
I thought 16 bit grayscale PNG images were supported as well. Am I wrong ?
--
Pascal.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
>
> Ok, I did. My method worked. Yours didn't. The interpolated version does
> what's expected, it gives the isosurface a smooth function to work with,
> and the result is something that closely resembles the original.
It seems to do in case of image_maps, the case where i originally had
problems with it was image_pattern (because it uses GREY_SCALE()). This
also makes it clear why using two separate images for low and high byte
works.
Note the code did not even work with final POV-Ray 3.5, for some reason
image_pattern is not allowed in pattern functions (it is commented out
in Parse_PatternFunction()).
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <rdg### [at] tritonimagicode>,
Christoph Hormann <chr### [at] gmxde> wrote:
> It seems to do in case of image_maps, the case where i originally had
> problems with it was image_pattern (because it uses GREY_SCALE()). This
> also makes it clear why using two separate images for low and high byte
> works.
I don't know what you were using image_pattern for...the .hf feature
takes a vector function, almost always a pigment function. It will never
work with image_pattern, because pattern functions return a single float
value. And image_pattern won't return any sort of sensible result from a
red-green 16-bit data file.
> Note the code did not even work with final POV-Ray 3.5, for some reason
> image_pattern is not allowed in pattern functions (it is commented out
> in Parse_PatternFunction()).
#declare InterpFn = function {pigment {image_map {tga "hfimage.tga"
interpolate 4}}}
isosurface {
function {y - InterpFn(x, z, y).hf}
...
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
>
>>It seems to do in case of image_maps, the case where i originally had
>>problems with it was image_pattern (because it uses GREY_SCALE()). This
>>also makes it clear why using two separate images for low and high byte
>>works.
>
>
> I don't know what you were using image_pattern for...the .hf feature
> takes a vector function, almost always a pigment function. It will never
> work with image_pattern, because pattern functions return a single float
> value. And image_pattern won't return any sort of sensible result from a
> red-green 16-bit data file.
Not for 24 bit tga images (which are a bad choice for heightfield data
anyway) If everything works as it should image_pattern in combination
with a 16 bit grayscale format (png or pgm) would be the most elegant
solution for this purpose:
#declare fn_Image =
function {
pattern {
image_pattern {
png "hfimage.png"
interpolate 2
}
}
}
isosurface {
function { z - fn_Image(x, y, 0) }
...
}
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <p76### [at] tritonimagicode>,
Christoph Hormann <chr### [at] gmxde> wrote:
> Not for 24 bit tga images (which are a bad choice for heightfield data
> anyway) If everything works as it should image_pattern in combination
> with a 16 bit grayscale format (png or pgm) would be the most elegant
> solution for this purpose:
I don't know what you're talking about. Your assertion was that .hf and
interpolation didn't mix. Then you started talking about image_pattern,
which can't be used with the .hf feature. Now you're talking about 24
bit RGB and 16 bit grayscale images as if it makes a difference...it
doesn't. A 16 bit grayscale image isn't useful as input for the .hf
feature, and makes it unnecessary. The red-green 16 bit grayscale TGA
format is not useable as input for the image_pattern pattern, but I
never said to use it as such. None of this has anything to do with
interpolation.
Yes, a 16 bit grayscale PNG or PGM would be ideal height field input,
but I don't see what it has to do with this discussion, which is about
TGA files. A red-green grayscale TGA with interpolation and the .hf
feature will work just as well, and you could recover the wasted space
of the blue channel by storing something else in it.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
