We all know that 24 bit images can be used for height fields, but I
was wondering if 48 bit images could also be used for height fields,
and if they would give less of the "terracing" or "banding" effects
that 24 bit files sometimes give?

Of course, I also have to find a way to create 48 bpp images in a
format that POV-Ray can actually read, but I'll eventually figure that
one out. For now, I just want to know if there is any advantage to 48
bpp images, when used as height fields?

Just in case anyone is tempted to do so, please don't tell me to read
the POV 3.5 docs, because I can't at the moment.  

Later,
Glen

Post a reply to this message

-Hail

   Pov never uses 24 bit information to build its height fields, it would
have been a great update though since the 16 bits in its odd format is
hardly adequate if you ask me.

Post a reply to this message

Vampyrium wrote:
> 
>      -Hail
> 
>    Pov never uses 24 bit information to build its height fields, it would
> have been a great update though since the 16 bits in its odd format is
> hardly adequate if you ask me.

I completely disagree.  Common number formats in computers are 8, 16 and
32 bit.  24 bit images have 3x8 bit and 48=3x16 bit.  Using those formats
to store 1 channel information is only a workaround (like done with 24 bit
tga red/green channel) better is to use 16 bit png or pgm which Povray can
read (although there are problems in the current beta) and which is
perfectly adequate.

There could be situations when 16 bit resolution is not enough of course,
but i never heard of actual problems with that.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <lFvGO8=N87Ecf8A=H0iK3LSb+WfL@4ax.com> , Glen Berry 
<7no### [at] ezwvcom>  wrote:

> We all know that 24 bit images can be used for height fields, but I
> was wondering if 48 bit images could also be used for height fields,
> and if they would give less of the "terracing" or "banding" effects
> that 24 bit files sometimes give?
>
> Of course, I also have to find a way to create 48 bpp images in a
> format that POV-Ray can actually read, but I'll eventually figure that
> one out. For now, I just want to know if there is any advantage to 48
> bpp images, when used as height fields?
>
> Just in case anyone is tempted to do so, please don't tell me to read
> the POV 3.5 docs, because I can't at the moment.

You should be able to use 16-bit grayscale PNG images.  You can also use
48-bit per pixel (16-bit per color component) PNG images of which only the
read channel will be used. As for a program that creates this kind of PNG
images (also they are standard), I don't know except for POV-Ray itself.

And of course the old format using the red and green color component of
8-bit per color component images is still available as well.  I think there
are a few (ancient) programs out there that support this format, but I don't
know where to get those either.


    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

Thorsten Froehlich wrote:
> 
> You should be able to use 16-bit grayscale PNG images.  You can also use
> 48-bit per pixel (16-bit per color component) PNG images of which only the
> read channel will be used. As for a program that creates this kind of PNG
> images (also they are standard), I don't know except for POV-Ray itself.

I think gforge/hf-lab does write those pngs.

> And of course the old format using the red and green color component of
> 8-bit per color component images is still available as well.  I think there
> are a few (ancient) programs out there that support this format, but I don't
> know where to get those either.

red/green channel TGA is a quite convenient format if you want to
write/read from your own program without libpng etc.  Writing a TGA header
is extremely easy and the rest is just an array of rgb triples.  Of course
it's an awful waste of space...

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: You can also use
: 48-bit per pixel (16-bit per color component) PNG images of which only the
: read channel will be used.

  You mean the red channel? Why?

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

Post a reply to this message

In article <3bc72ce7@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

> : You can also use
> : 48-bit per pixel (16-bit per color component) PNG images of which only the
> : read channel will be used.
>
>   You mean the red channel? Why?

Ups, "red" of course.  What else should be used as the height of a color
image?  Any method to get a grayscale value out of an RGB image is
different.  How many and which one should be supported?

    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

Thorsten Froehlich <tho### [at] trfde> wrote:
: Ups, "red" of course.  What else should be used as the height of a color
: image?  Any method to get a grayscale value out of an RGB image is
: different.  How many and which one should be supported?

  AFAIK 24-bit images are converted to grayscale when using them to create
a heightfield. I don't see any reason why 48-bit images should be handled
any different.

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

Post a reply to this message

In article <3bc757c3@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   AFAIK 24-bit images are converted to grayscale when using them to create
> a heightfield. I don't see any reason why 48-bit images should be handled
> any different.

No, with the exception of JPEG all non-indexed color image formats will be
used as red-green hfields and I am not sure why JPEG is different (I don't
remember making that change deliberately, if I made it at all).  For formats
with color maps POV-Ray will ignore the color value and just take the map
index as height.


    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

It seems that I have been using heightfields for years without realizing
that it doesn't do what I thought. This is perhaps because I use almost
exclusively b/w images.
  I must confess that I don't understand the logic behind the current
behaviour. Wouldn't it be more logical to just convert the color to b/w and
take that as height?

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

Post a reply to this message