When I create a tga in leveller and use it as a height-field, everything is
fine.

However, when I try and use the same tga as a pigment-function in a height
field, it looks like garbage.

I've been able to get around the problem by rendering an orthographic hf of the
tga, applying a gradient pigment, no lights and ambient 1, and then using the
resultant bitmap in my function.

Still, do any leveller users understand the problem? I have to say that loading
the leveller output into PSP shows a much more messy image than I'd expect -
closer to the iso-output than the hf output.

I've put a zip that will show the problem in scene-files.binaries.

Any ideas/insight?

Oh, one final question - I would expect:

F_Img(x,0,z).gray (where F_Img is the pigment function) to return a value
between 0 - 255, so F_Img(x,0,z).gray/255 would return a value between 0 -1.
This, however, returns a completely flat surface, and I find I have to use a
value of around gray/10 to get anything back at all. Huh?

-- 
#macro A(V,B,C,R)#while(B-256)#if(V-128/B>=0)sphere{0,.5translate<C-4R-1,9>
pigment{rgb<1-C/8R/2C/8>}}#local V=V-128/B;#end#local B=B*2;#local C=C+1;#
end#end A(234,1,0,2)A(85,1,0,1)A(81,1,0,0)light_source{-5 1}//Tom Melly

Post a reply to this message

Tom Melly wrote:
> When I create a tga in leveller and use it as a height-field, everything is
> fine.
> 
> However, when I try and use the same tga as a pigment-function in a height
> field, it looks like garbage.
> 
> I've been able to get around the problem by rendering an orthographic hf of the
> tga, applying a gradient pigment, no lights and ambient 1, and then using the
> resultant bitmap in my function.
> 

Short answer: POV-Ray treats tga images differently in heightfields and 
image_maps.

Longer answer: The tga export in leveller probably makes use of the 
special interpretation of 24 bit tga images for heightfields in POV. 
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).

Without interpolation:

#declare fn_Image=function {
   pigment {
     image_map {
       tga "test.tga"
       map_type 0
       once
     }
   }
}

#declare fn_Height=
function {
   fn_Image(x, y, z).red+fn_Image(x, y, z).green/256
}

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.

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

"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:879### [at] tritonimagicode...

> function {
>    fn_Image(x, y, z).red+fn_Image(x, y, z).green/256
> }

Gah! I nearly figured this one out. I'd tried foo.red + foo.green + foo.blue. -
but with no division. I'd noted that the tga didn't have any blue, and... well,
that was about it. Why does only the green get divided by 256? Oh, high-byte,
low-byte stuff...

Many thanks...

(tests CH's solution)....

Many, many, many thanks

P.S.

Hmm, does this mean if I reduce the green by that factor in PSP, and then
grayscale, I'll also have a workable grayscale img? Tests....  Hmm, hard to test
(PSP+TOM limitation).

However, splitting the image into 3 separate images (one for red, one for blue,
etc.), gives me a usable red image (once grayscaled and then .gray in POV). The
green channel just has some bumps on it which add little to the image, and are
pretty irrelvant when using it in an iso (since I want to control my own fine
detail). I suspect that the green channel is used to store the "last applied
action", which would make single-level undo's easy (which is the only level of
undo that leveller supports iirc, which makes sense). Thanks, once again.

Post a reply to this message

In article <4007feb8$1@news.povray.org>,
 "Tom Melly" <tom### [at] tomandlucouk> wrote:

> Hmm, does this mean if I reduce the green by that factor in PSP, and then
> grayscale, I'll also have a workable grayscale img? Tests....  Hmm, hard to 
> test (PSP+TOM limitation).

No, this will not work. The values for each channel are stored as 8-bit 
integers, with a minimum of 0 and a max of 255. If you divide the green 
channel by 255 and then try to save the results to the file, you just 
essentially destroyed the green channel...pixels that were 255 will now 
be 1, and all other pixels will be 0.


> However, splitting the image into 3 separate images (one for red, one 
> for blue, etc.), gives me a usable red image (once grayscaled and 
> then .gray in POV). 

This is just truncating the HF data to 8 bits. In decimal, the analogy 
would be dividing it into 10000 levels, then only keeping the first two 
digits...1100, 1200, etc. You lose all the levels in between: 5123 
becomes 5100, 3999 becomes 3900, though it's really a hair away from 
4000.


> The green channel just has some bumps on it which add little to the 
> image, and are pretty irrelvant when using it in an iso (since I want 
> to control my own fine detail). I suspect that the green channel is 
> used to store the "last applied action", which would make 
> single-level undo's easy (which is the only level of undo that 
> leveller supports iirc, which makes sense). Thanks, once again.

No. The green channel stores the lower bits of the 16 bit value. The red 
channel splits the height field into 256 levels, the green channel 
splits each level into 256 more. You want the full 16 bits, *especially* 
with isosurfaces. Dropping the green channel will cause stairstepping or 
terracing artifacts.

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

In article <879### [at] tritonimagicode>,
 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

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