Thorsten Froehlich <tho### [at] trfde> wrote:
> "Converting PNG image map to 8 bits/sample from higher bit depth."

  But why? I can't understand.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

In article <3ee346e3@news.povray.org>,
 Lutz-Peter Hooge <lpv### [at] gmxde> 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] 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 <cja### [at] earthlinknet> 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

In article <3ee397c2$1@news.povray.org>,
 Lutz-Peter Hooge <lpv### [at] gmxde> 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] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <cja### [at] netplexaussieorg> , 
Christopher James Huff <cja### [at] earthlinknet>  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] trfde

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

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> 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

In article <3ee3bdc4$1@news.povray.org>,
 Lutz-Peter Hooge <lpv### [at] gmxde> 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] 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 <cja### [at] earthlinknet> 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

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

Christopher James Huff <cja### [at] earthlinknet> 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