 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-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] gmx de> 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
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: heightfields, 16bit images and isosurfaces
Date: 8 Jun 2003 03:44:10
Message: <3ee2e94a$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Christoph Hormann
Subject: Re: heightfields, 16bit images and isosurfaces
Date: 8 Jun 2003 03:52:40
Message: <3EE2EB70.A5CC1158@gmx.de>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: heightfields, 16bit images and isosurfaces
Date: 8 Jun 2003 04:03:40
Message: <3ee2eddc$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Lutz-Peter Hooge
Subject: Re: heightfields, 16bit images and isosurfaces
Date: 8 Jun 2003 09:35:29
Message: <3ee33ba1$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Lutz-Peter Hooge
Subject: Re: heightfields, 16bit images and isosurfaces
Date: 8 Jun 2003 09:38:20
Message: <3ee33c4c@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Lutz-Peter Hooge
Subject: Re: heightfields, 16bit images and isosurfaces
Date: 8 Jun 2003 10:23:31
Message: <3ee346e3@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
