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

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

I think there are good arguments for and against both ways.

I think the "normal" way to create a hfield is to take some image and
process it with either a special program or photo editor to get the desired
look.  In both cases one would expect the export of a grayscale image.  No
human can reliably comprehend how a rgb-image will look like when it is
converted to grayscale without seeing the result.  So this task is best done
in a program.  POV-Ray allows you to even work with programs that don't
support grayscale images in an easy way by using just one component of a
color image without having to consider a possibly complicated color to
grayscale conversion.

Then there is the less frequent and less useful (I guess) use of a color
photo or something similar as a hfield.  In this case the optimal solution
would be to do a good grayscale conversion of the color information.

I don't use hfields (or POV-Ray) a lot, and I actually don't have a problem
with either way.  If there are more requests to make it convert to grayscale
for 16-bit per color component images, I would be happy to do so...


    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

in news:3bc75cdc$1@news.povray.org Thorsten Froehlich wrote:

> No, with the exception of JPEG all non-indexed color image formats
> will be used as red-green hfields

I'll add this to the docs.

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: I don't use hfields (or POV-Ray) a lot, and I actually don't have a problem
: with either way.  If there are more requests to make it convert to grayscale
: for 16-bit per color component images, I would be happy to do so...

  I don't think that the current behaviour is that problematic. I think that
the biggest problem is that this behaviour is not clearly documented. I have
read the heightfield documentation countless times during these years, and I
never realized this behaviour.
  Of course I can't speak for anyone else, but it seems to me that the user
(well, in this case me) gets the impression that this kind of b/w conversion
must be done when creating the heightfield... I don't know where did I get
that impression, but that's what I thought. I think that the documentation
lacks a clear and unambiguous description of the exact algorithm used for
the pixel to height conversion with true color images (what happens with
indexed images is a lot better documented).
  Perhaps a more visible note about this conversion could be added with some
examples of useful usages of this feature.

  On the other hand, I wouldn't mind that the b/w conversion would be used
to create the heightfield from the image. Note that this way you get *more*
than 256 heights, which makes the heightfield more accurate even with 24-bit
images.

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

Warp wrote:
> 
>   I don't think that the current behaviour is that problematic. I think that
> the biggest problem is that this behaviour is not clearly documented. I have
> read the heightfield documentation countless times during these years, and I
> never realized this behaviour.

Well, I have. But I also read the Fractint documentation,
who also used "16 out of 24 bits" formats, so I easily
understood what POV was doing.

I am not sure that if you convert 24-bit to greyscale
you will get 16-bit precision : I would say 8-bit, but I'm
not at all into this field, so I'm not sure at all.
Something inbetween perhaps.

> I think that the documentation
> lacks a clear and unambiguous description of the exact algorithm used for
> the pixel to height conversion with true color images (what happens with
> indexed images is a lot better documented).

Indexed color : the number of the color in the index
 is used to determine the height. 8-bit and 16-bit indexes
 are accepted and used by POV. 16-bit indexes are mostly/only?
 supported by PNG file format.

True color : the red and green components are combined to
 form a 16-bit value. This dates back from days where no
 file format supported 16-bit palettes or 16-bit B&W.
 Fractint introduced this hack, and it has been kept. Of
 course, it is almost impossible to draw them by hand (or
 you do a B&W picture, but only get 8-bit precision), you
 should use a special program for that. afaik, hflab can
 output such format.

>   On the other hand, I wouldn't mind that the b/w conversion would be used
> to create the heightfield from the image. Note that this way you get *more*
> than 256 heights, which makes the heightfield more accurate even with 24-bit
> images.

I'm a bit confused about the issue of B&W conversion. Are you
sure you will have more than 8-bit precision in that case?

-- 
Adrien Beau   adr### [at] freefr   http://adrien.beau.free.fr/

Post a reply to this message

Adrien Beau <adr### [at] freefr> wrote:
: I am not sure that if you convert 24-bit to greyscale
: you will get 16-bit precision : I would say 8-bit, but I'm
: not at all into this field, so I'm not sure at all.

  When you convert an image to b/w (and save it to a true-color 24-bit
format) you get exactly 256 different shades of gray. POV-Ray can only
create 256 heights from them.

  Using red+green as a 16-bit value for the height is a good idea, but not
very practical. No image editing programs support that, so you just can't
create them. AFAIK there are only two widespread programs which support
this: POV-Ray and fracting. This isn't enough because neither is an image
editing program.
  Nowadays this red+green idea is also obsolete because we can use a 16-bit
b/w PNG to achieve the same thing, and this is a lot more supported (besides
being a lot more logical).

: I'm a bit confused about the issue of B&W conversion. Are you
: sure you will have more than 8-bit precision in that case?

  Yes. You get approximately 3 times more accuracy.

  There's a big difference between converting an image first to b/w and
then feeding the result to POV-Ray and feeding the original color image
and letting POV-Ray do the b/w conversion. The difference is that when
you do the b/w conversion yourself and save to an image format, you are
actually *clamping* the fraction values from the result, thus destroying
accuracy.

  Suppose that a simple average is used to make the b/w-conversion. This
table shows what I mean:

Original     B/W value               What actually gets
rgb values   (which pov could use)   written to an image file
----------   ---------------------   ------------------------
0,0,0        0                       0
1,0,0        1/3                     0
1,1,0        2/3                     1
1,1,1        1                       1
2,1,1        4/3                     1
2,2,1        5/3                     2
2,2,2        2                       2
etc.

(Note that the order of the example rgb values above doesn't matter.)

  If we let POV-Ray do the b/w-conversion, then it can use 3 times more
accuracy than if we save to b/w-converted image to a file and give that
to POV-Ray.

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

Warp wrote:
> 
>   Using red+green as a 16-bit value for the height is a good idea, but not
> very practical. No image editing programs support that, so you just can't
> create them. AFAIK there are only two widespread programs which support
> this: POV-Ray and fracting. This isn't enough because neither is an image
> editing program.
>   Nowadays this red+green idea is also obsolete because we can use a 16-bit
> b/w PNG to achieve the same thing, and this is a lot more supported (besides
> being a lot more logical).
> 

I would not say it's obsolete, apart from the reason that it's quite
simple to program TGA output, it's also possible to edit those formats
with a paint program which does not apply for 16 bit png.  You can resize
it (without interpolation of course) cut out a subsection of the image,
mirror it, etc.

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

Christoph Hormann <chr### [at] gmxde> wrote:
: I would not say it's obsolete, apart from the reason that it's quite
: simple to program TGA output, it's also possible to edit those formats
: with a paint program which does not apply for 16 bit png.  You can resize
: it (without interpolation of course) cut out a subsection of the image,
: mirror it, etc.

  But forget about making any real changes to the image, like smoothing,
sharpening, etc... :)

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

Warp wrote:
> 
>   Using red+green as a 16-bit value for the height is a good idea, but not
> very practical. No image editing programs support that, so you just can't
> create them. AFAIK there are only two widespread programs which support
> this: POV-Ray and fracting. This isn't enough because neither is an image
> editing program.

IIRC, hf-lab and the like can do that. Not that I'm a
supporter of 16-bit coded as red+green. We all agree
that PNG is now a better choice.

>   There's a big difference between converting an image first to b/w and
> then feeding the result to POV-Ray and feeding the original color image
> and letting POV-Ray do the b/w conversion.

I thank you for the explanation.

-- 
Adrien Beau   adr### [at] freefr   http://adrien.beau.free.fr/

Post a reply to this message

-Hail

  If you study how the F().gray works for the isosurface you will see that
that is a far better way to make heightfields.

Post a reply to this message

Vampyrium wrote:
> 
>   If you study how the F().gray works for the isosurface you will see that
> that is a far better way to make heightfields.

Far better than what?

The red/green channel tga has - as mentioned - historical reasons.  Your
suggestion would allow higher vertical resolution than 16 bit, but this is
hardly necessary and would be difficult from the programming perspective
(the program generating such a HF would certainly use 32 bit values for
internal calculations)

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