-Are 16bit TIFFs not supported in height_field?
It does work (no error), but the result looks like 8bit.
When I convert the TIFF to PNG first, it looks much smoother.
The TIFF was generated by Picture Publisher 10.
It this an issue with TIFFs in general, or only with TIFFs generated
by Picture Publisher?

-Is there a version of POV-Ray that supports more than 8bit/channel
in pigments, so that it is possible to make an iso-heightfield from
an 16bit grayscale image? (function{pigment{image_map{...}}})
I tried MLPov with an hdr image (converted with HCRedit), but still
the result didn't look as smooth as the 16bit PNG heightfield.
Maybe MLPov converts it back to 8bit when it is used inside a function?

Lutz-Peter

Post a reply to this message

In article <3ee29c31$1@news.povray.org>,
 Lutz-Peter Hooge <lpv### [at] gmxde> wrote:

> -Are 16bit TIFFs not supported in height_field?

Probably not. From memory, POV supports 16-bit PNG grayscale, POT (some 
odd kind of 16-bit GIF), and a little hack where it uses the red and 
green channels of an RGB TGA file to store a 16-bit gray value.


> It does work (no error), but the result looks like 8bit.
> When I convert the TIFF to PNG first, it looks much smoother.
> The TIFF was generated by Picture Publisher 10.
> It this an issue with TIFFs in general, or only with TIFFs generated
> by Picture Publisher?

Maybe neither. There've been problems with TIFF support before, it is 
apparently quite common for software to not support it fully, and POV 
does not mention it in the section on 16-bit formats.


> -Is there a version of POV-Ray that supports more than 8bit/channel
> in pigments, so that it is possible to make an iso-heightfield from
> an 16bit grayscale image? (function{pigment{image_map{...}}})

Color math in POV is done as single precision floating point. The 8/16 
bit limitation is internal to the file formats, not to POV.


> I tried MLPov with an hdr image (converted with HCRedit), but still
> the result didn't look as smooth as the 16bit PNG heightfield.
> Maybe MLPov converts it back to 8bit when it is used inside a function?

I'm not sure how HDR images store the values, they may just not have the 
precision you are expecting. They cover a wider dynamic range, and small 
levels are useless in much of that range, so to save memory it may 
distribute the levels more densely at the lower intensities. I'm not 
sure what you're trying to do using them for a height field or 
isosurface, if you want more precision you should just use a 16 bit 
image. (And why compare a HDR isosurface to a PNG height field?) One 
more thing: make sure you have bilinear interpolation turned on, the 
isosurface solving algorithm doesn't deal well with the infinite 
gradients between solid pixels.

-- 
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 <3ee29c31$1@news.povray.org> , Lutz-Peter Hooge <lpv### [at] gmxde>
wrote:

> Are 16bit TIFFs not supported in height_field?

They are not support anywhere, not only not in height_fields.  In fact, I
don't think 16bit PNG is support either...

> Is there a version of POV-Ray that supports more than 8bit/channel
> in pigments, so that it is possible to make an iso-heightfield from
> an 16bit grayscale image?

If you use a 16 bit PNG and have verbose output turned on, you should see a
warning "Converting PNG image map to 8 bits/sample from higher bit depth."

    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

Lutz-Peter Hooge wrote:
> 
> [...]
> 
> -Is there a version of POV-Ray that supports more than 8bit/channel
> in pigments, so that it is possible to make an iso-heightfield from
> an 16bit grayscale image? (function{pigment{image_map{...}}})
> I tried MLPov with an hdr image (converted with HCRedit), but still
> the result didn't look as smooth as the 16bit PNG heightfield.
> Maybe MLPov converts it back to 8bit when it is used inside a function?

The hdr format is not a good idea for heightfields at all.  In official
POV you can currently only use ascii pgm for this purpose, next MegaPOV
will also support 16 bit binary pgm.

You can of course always use the trick of two separate image maps for
HSB/LSB.

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

In article <3ee2e94a$1@news.povray.org> , "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> They are not support anywhere, not only not in height_fields.  In fact, I
> don't think 16bit PNG is support either...

Never mind, it is actually support, but the way it is supported is so
obfuscated and far more complicated than it needs to be...

    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:

> distribute the levels more densely at the lower intensities. I'm not 
> sure what you're trying to do using them for a height field or 
> isosurface,

A highly detailed heightfield uses lot of memory.
My idea was to use a image for the rough structure and add the little
details as functions.

> if you want more precision you should just use a 16 bit 
> image.

As already said, that doesn't work, the only place where 16bit seems
to be supported (with the special TGA format and PNG) are heightfields.

> (And why compare a HDR isosurface to a PNG height field?)

see above.

Lutz-Peter

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:

> You can of course always use the trick of two separate image maps for
> HSB/LSB.

Is there a software that can split a TIFF or PNG into this kind of
thing?

Lutz-Peter

Post a reply to this message

In article <3ee33ba1$1@news.povray.org>,
 Lutz-Peter Hooge <lpv### [at] gmxde> wrote:

> > distribute the levels more densely at the lower intensities. I'm not 
> > sure what you're trying to do using them for a height field or 
> > isosurface,
> 
> A highly detailed heightfield uses lot of memory.
> My idea was to use a image for the rough structure and add the little
> details as functions.

That still doesn't explain why you chose the HDR format. They're for 
storing color data with a high dynamic range, a feature that is entirely 
useless for height fields.


> > if you want more precision you should just use a 16 bit 
> > image.
> 
> As already said, that doesn't work, the only place where 16bit seems
> to be supported (with the special TGA format and PNG) are heightfields.

Did you use a grayscale image? When I was poking through that code, I 
saw code for loading 16 bit grayscale, but I don't recall seeing 16-bit 
RGB. And did you make sure to use bilinear interpolation?

BTW, the TGA format *is* supported, but image maps load it as an 
ordinary color TGA, because that's what it is. You need to use .hf to 
get a grayscale value computed from the red and green channels:

#declare MyHFImgFn = function {pigment {image_map {tga...}}}
#declare MyHFFn = function {MyHFImgFn(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 <cja### [at] earthlinknet> wrote:

> That still doesn't explain why you chose the HDR format.

Because I guessed it is just another 16bit format.

> Did you use a grayscale image? When I was poking through that code, I 
> saw code for loading 16 bit grayscale, but I don't recall seeing 16-bit 
> RGB. And did you make sure to use bilinear interpolation?

I'll try again with grayscale, but IIRC I did already.
Yes, I DID use bilinear interpolation.

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

Lutz-Peter

Post a reply to this message

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

In article <3ee4fc87@news.povray.org>,
 Lutz-Peter Hooge <lpv### [at] gmxde> wrote:

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

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

> What were the render times like?

For 512x384 without AA:

bilinear:               14s
bilinear as function: 1m05s
bicubic as function:  4m10s

So bicubic is about 4 times slower (not unexpected, it uses 16 samples
instead of 4 in bilinear).

Lutz-Peter

Post a reply to this message

In article <3ee52eb6@news.povray.org>,
 Lutz-Peter Hooge <lpv### [at] gmxde> wrote:

> Christopher James Huff <cja### [at] earthlinknet> wrote:
> 
> > What were the render times like?
> 
> For 512x384 without AA:
> 
> bilinear:               14s
> bilinear as function: 1m05s
> bicubic as function:  4m10s
> 
> So bicubic is about 4 times slower (not unexpected, it uses 16 samples
> instead of 4 in bilinear).

I was actually wondering about isosurface vs. height field.
An isosurface solver optimized for the constraints of a height field 
might be worth it...I've done some experiments with this before in my 
little test-bed tracer, I might revive that work. With an image as the 
data source, it could do some things to further speed computation.

For example, I'm thinking about a quad-tree structure storing the min 
and max heights of areas to allow them to be skipped in the intersection 
search. (If a ray enters and exits a partition above or below the range 
of the height field, an intersection is not possible.) This optimization 
should also be possible for mesh-based height fields, but I suspect 
wouldn't be much of an improvement over a more straightforward quad-tree 
method.

There are a few other improvements that could be made to the existing 
primitive. At least one thing which has already been done by someone 
else: switch the orientation of the two-triangle patches depending on 
the direction the surface is curving. This way, the diagonals follow the 
contours of the curves and the artifacts are much less jarring. Better 
smoothing would also be nice, I find it hard to believe the current 
smoothing is optimal. And a couple more ideas...I kind of like the 
bilinear patch effect of the isosurface, and am going to try to figure 
out how to test intersections directly. And there's a point-cloud 
raytracing algorithm that I've been looking at which might work nicely 
on height field data.

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

> I was actually wondering about isosurface vs. height field.

~1s for heightfield

> An isosurface solver optimized for the constraints of a height field 
> might be worth it...

Would that still work if the surfaces is modified with some other
function?

> Better smoothing would also be nice, I find it hard to believe the current 
> smoothing is optimal.

SlimePOV also has an additional smoothing algorithm. 
It does not look much different in this testscene, however, but maybe in 
bigger, more complicated heightfields. I havn't tried that yet.

Lutz-Peter

Post a reply to this message

In article <3ee5491f$1@news.povray.org>,
 Lutz-Peter Hooge <lpv### [at] gmxde> wrote:

> > An isosurface solver optimized for the constraints of a height field 
> > might be worth it...
> 
> Would that still work if the surfaces is modified with some other
> function?

Depends on the modification function and the optimizations.


> > Better smoothing would also be nice, I find it hard to believe the current 
> > smoothing is optimal.
> 
> SlimePOV also has an additional smoothing algorithm. 
> It does not look much different in this testscene, however, but maybe in 
> bigger, more complicated heightfields. I havn't tried that yet.

That's the one with the smart triangle orientation, I think.

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

Lutz-Peter Hooge <lpv### [at] gmxde> wrote:

> For 512x384 without AA:
> 
> bilinear:               14s
> bilinear as function: 1m05s
> bicubic as function:  4m10s

Patched version:
bilinear: 14s (I expected the MingW-Version to be
               significantly slower then the official...)
bicubic:  25s

Seems to be faster (relative to bicubic) than I expected.

Also no artifacts problem in the patched version :-)
Added picture to
<http://www.lutz-peter.hoogi.de/extern/hfield/interp.html>

Lutz-Peter

Post a reply to this message

In article <3ee56c92$1@news.povray.org>,
 Lutz-Peter Hooge <lpv### [at] gmxde> wrote:

> Patched version:
> bilinear: 14s (I expected the MingW-Version to be
>                significantly slower then the official...)
> bicubic:  25s
> 
> Seems to be faster (relative to bicubic) than I expected.

About twice as fast as I would have guessed...nice.


> Also no artifacts problem in the patched version :-)

Well, only very faint artifacts. A huge improvement over smoothed height 
fields, but I wonder if those normal discontinuities could be removed...
Are you going to post the code somewhere?

That normalized distance method just doesn't look very effective.

-- 
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:
> > Also no artifacts problem in the patched version :-)
> 
> Well, only very faint artifacts. A huge improvement over smoothed height 
> fields, but I wonder if those normal discontinuities could be removed...

I was referring to that black-spots-problem.
There is a faint grid structure visible, but I don't see any
discontinuities. There should't be any, unless there is a bug in my code.

> Are you going to post the code somewhere?

Yes, I will post it later, I just want to clean it up and maybe
optimize it (if possible) before.

btw, what would be the correct group for this?
.programming or .unofficial.patches?

Lutz-Peter

Post a reply to this message

In article <3ee624d9@news.povray.org>,
 Lutz-Peter Hooge <lpv### [at] gmxde> wrote:

> I was referring to that black-spots-problem.
> There is a faint grid structure visible, but I don't see any
> discontinuities. There should't be any, unless there is a bug in my code.

The discontinuities I mentioned are in the normals, not the surface. The 
function is continuous, but not all its derivatives are. That's why you 
can see sharp changes in shading. The Perlin noise function used to have 
a similar problem, I wanted to see the code to see if a similar fix 
could be implemented for interpolation.


> btw, what would be the correct group for this?
> .programming or .unofficial.patches?

The scene code should go in povray.binaries.programming. The other two 
groups are for discussion.

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

I updated my custom POV version to include suppport for 16bit PNGs
and 16bit grayscale TIFFs.

PNG support should be complete, it also fixes the bug with grayscale
images <8bpp beeing almost black, and transparent 8bpp grayscale 
PNGs should be more memory-efficient (they where converted to RGB
before).

The TIFF Patch is more limited, it at least allows reading 
uncompressed 16bit grayscale TIFFs exported from Picture
Publisher 10, but I can't guaranty for anything more  ;-)
(extracting anything else than 8bit RGBA from LibTiff seems
to be quite complicated...)

Downloads:

<http://www.lutz-peter.hoogi.de/extern/lppov_usr.zip>
Win32 executable (MingW) and sample scenes

<http://www.lutz-peter.hoogi.de/extern/lppov_diff.zip>
Just the changed files needed to apply the patches to megapov 1.0

<http://www.lutz-peter.hoogi.de/extern/lppov_src.zip>
Full source code (minus support libs) including makefiles for
MingW (windows and windows console) and BCC 5.5

Lutz-Peter

Post a reply to this message