-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