Roland Mas wrote:

> I wondered how long it would take until someone would notice this...
> I'm afraid you all lost :-)
> 
> The doc says it all (almost):
> 
> --- Cut here ---
> 7.8.4            HF_Gray_16
> 
> The hf_gray_16 setting is useful when using POV-Ray to generate
> heightfields for use in other POV-Ray scenes. The syntax is...
> 
>   global_settings { hf_gray_16 BOOLEAN }
> 
> The boolean value turns the option on or off. If the keyword is
> specified without the boolean value then the option is turned on. If
> hf_gray_16 is not specified in any global_settings statement in the
> entire scene then the default is off.
> 
> When hf_gray_16 is on, the output file will be in the form of a
> heightfield, with the height at any point being dependent on the
> brightness of the pixel.  The brightness of a pixel is calculated in
> the same way that color images are converted to grayscale images:
> 
>   height = 0.3 * red + 0.59 * green + 0.11 * blue
> 
> Setting the hf_gray_16 option will cause the preview display, if used,
> to be grayscale rather than color. This is to allow you to see how the
> heightfield will look because some file formats store heightfields in
> a way that is difficult to understand afterwards. See section "Height
> Field" for a description of how POV-Ray heightfields are stored for
> each file type.
> --- Cut here ---
> 
> Maybe it should have been a bit clearer.  Anyway, the output can be
> turned into a sixteen bit per pixel black and white image file.  I
> first wrote "at least in Truevision format", but it is not true.  My
> further tests reveal that it works with "PNG" format.  Hence my
> superseding of my previous article.
> 
> Roland.
> --
> Roland Mas
> 

> - Genki desu, ture en zinc.



   For the purposes of the i.r.t.c. contest this method is invalid. Yes it
 is true that the image is in 16 bit gray scale but it is also true that
 if try to view it in a normal image viewing program it is not recognizable
 as a normal image. In most cases they an ugly green in color and highly
 pixelated in appearance. To make it visible it needs to be color and format
 converted. If you are going to do that you might as well use an image
 conversion program to turn into 256 shades of gray and gain the added color
 depth in the process. Either way it's not allowed in the competition so it's
 a moot point. It is for these reasons I did not bring it up before simply
 because it's not the solution the original poster will need to accomplish
 his goal.


-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

hf_gray_16 generates 16 bit grayscale images, every pixel value should be
considered a 2-byte "word". This is non-standard; graphics packages will not
translate the image correctly as a grayscale bitmap. Have you looked what a
heightfield tga looks like in, say, PSP? It's red-green.

Margus

Roland Mas wrote in message ...
>
>I wondered how long it would take until someone would notice this...
>I'm afraid you all lost :-)
>
>The doc says it all (almost):
>
>--- Cut here ---
>7.8.4            HF_Gray_16
>

Post a reply to this message

I'm pretty sure that reasonable post processing is allowed in the IRTC.
I recall reading that processing which affects all pixels similarly is
acceptable, ie. 'if you wouldn't be willing to do it to every frame of
an animation, it's probably not acceptable' so I'd just load the image
into a paint program and grey scale it.

Cheers, PoD.

Post a reply to this message

On 12 Mar 1999 17:38:53 +0100, rol### [at] casimirrezelenstfr (Roland
Mas) wrote:

>I wondered how long it would take until someone would notice this...
>I'm afraid you all lost :-)
>
>The doc says it all (almost):
>
>--- Cut here ---
If you say so... :)
>--- Cut here ---
>
>Maybe it should have been a bit clearer.  Anyway, the output can be
>turned into a sixteen bit per pixel black and white image file.  I
>first wrote "at least in Truevision format", but it is not true.  My
>further tests reveal that it works with "PNG" format.  Hence my
>superseding of my previous article.
>
>Roland.

Use the output image as a source for a height_field turned towards the
camera with a gradient pattern ranging from black to white and
pointing towards the viewer. For example, this

height_field
{
  png "hf16g.png"
  texture
  {
    pigment { gradient y color_map { [0 color rgb 0][1 color rgb 1] }}
    finish { ambient 1 }
  }
  translate -0.5
  scale <1,1/1000,1>
  rotate -90*x
}

camera
{
  location -2*z
  up y
  right x
  angle 30
  look_at 0
  orthographic
}

should work, imho. Use the same output file width and height settings
as for the original, color image.

---------
Peter Popov
ICQ: 15002700

Post a reply to this message

Damn! You beat me to it. Perhaps I should write my messages online.

Margus

Ken wrote in message <36E96D77.9FBEB7EF@pacbell.net>...
>
>   For the purposes of the i.r.t.c. contest this method is invalid. Yes it
> is true that the image is in 16 bit gray scale but it is also true that
> if try to view it in a normal image viewing program it is not recognizable
> as a normal image. In most cases they an ugly green in color and highly
> pixelated in appearance. To make it visible it needs to be color and
format
> converted. If you are going to do that you might as well use an image
> conversion program to turn into 256 shades of gray and gain the added
color
> depth in the process. Either way it's not allowed in the competition so
it's
> a moot point. It is for these reasons I did not bring it up before simply
> because it's not the solution the original poster will need to accomplish
> his goal.
>
>
>--
>Ken Tyler
>
>mailto://tylereng@pacbell.net

Post a reply to this message

On Fri, 12 Mar 1999 11:39:35 -0800, Ken <tyl### [at] pacbellnet> wrote:
>   For the purposes of the i.r.t.c. contest this method is invalid. Yes it
> is true that the image is in 16 bit gray scale but it is also true that
> if try to view it in a normal image viewing program it is not recognizable
> as a normal image. 

This is only true if you output to a TGA image.  PNG and PPM both output
as plain grays.

Post a reply to this message

A real bad way:
 Use rgb single floats, force 8-bit display (under Options in Windows
version menu  anyway) and do a screen capture.
Yuck! Never mind.


Kyle wrote:
> 
> Hi everyone.  I have a quick question.  Is there any way to have POV-Ray
> render in black and white?  I'm thinking about submitting an IRTC image
> in black and white, but since post-processing is not allowed, I don't
> see a good way to do it.  Is there some setting in POV-Ray for this?  Of
> course, I can just give all the objects a greyish color but I don't
> think that would come out very nicely.  Well, if anyone has a suggestion
> I'd be very grateful to hear it.
> 
>                 Kyle

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.htm
 mailto:inv### [at] aolcom?PoV

Post a reply to this message

On Sat, 13 Mar 1999 06:44:16 +1030, PoD <pod### [at] merlinnetau> wrote:

>I'm pretty sure that reasonable post processing is allowed in the IRTC.
>I recall reading that processing which affects all pixels similarly is
>acceptable, ie. 'if you wouldn't be willing to do it to every frame of
>an animation, it's probably not acceptable' so I'd just load the image
>into a paint program and grey scale it.

Not so, I'm afraid.  That would definitely be illegal postprocessing.
The intent of the rule and the somewhat poor example you quote has
been clarified in irtc-l.  The desired situation is no postprocessing
at all.  About the only things generally considered acceptable
postprocessing are: adding copyright/sig, jpeg conversion. resizing,
gamma/brightness correction, (this causes some controversy) stitching
together an image rendered in pieces and (this is even more
controversial) cropping in certain circumstances.  Many people go to
great extremes to avoid even these things where possible.

Jerry Anning
clem "at" dhol "dot" com

Post a reply to this message

"Margus Ramst" <mar### [at] peakeduee> writes:

> hf_gray_16 generates 16 bit grayscale images, every pixel value should be
> considered a 2-byte "word". This is non-standard; graphics packages will not
> translate the image correctly as a grayscale bitmap. Have you looked what a
> heightfield tga looks like in, say, PSP? It's red-green.

Sure.  But, as was said before, save as PNG and you'll get a sixteen bit
per pixel *black and white* image.   Not a red-green one.
-- 
Roland Mas

Sauvez une souris, mangez votre chat.

Post a reply to this message

Jerry Anning wrote in message <36e98f24.23757454@news.povray.org>...
>On Sat, 13 Mar 1999 06:44:16 +1030, PoD <pod### [at] merlinnetau> wrote:
>
>>I'm pretty sure that reasonable post processing is allowed in the IRTC.
>>I recall reading that processing which affects all pixels similarly is
>>acceptable, ie. 'if you wouldn't be willing to do it to every frame of
>>an animation, it's probably not acceptable' so I'd just load the image
>>into a paint program and grey scale it.
>
>Not so, I'm afraid.  That would definitely be illegal postprocessing.
>The intent of the rule and the somewhat poor example you quote has
>been clarified in irtc-l.  The desired situation is no postprocessing
>at all.  About the only things generally considered acceptable
>postprocessing are: adding copyright/sig, jpeg conversion. resizing,
>gamma/brightness correction, (this causes some controversy) stitching
>together an image rendered in pieces and (this is even more
>controversial) cropping in certain circumstances.  Many people go to
>great extremes to avoid even these things where possible.
>
>Jerry Anning
>clem "at" dhol "dot" com

While I haven't had a go at IRTC (yet), I have read the rules. It seems to
me that it is quite acceptable to use a graphics program to convert an image
from one "file format" to another, for axample, TGA to JPG, for posting. How
is it different if I open my 16-bit grayscale image and save it as a 24-bit
jpeg? The program recognises that the image is gray, not colour and behaves
appropriately.

Comments?

Gordon
<gbe### [at] birdcameroncomau>

Post a reply to this message