#macro m_RGB2G(fRed,fGreen,fBlue)
  #local G = 0.3 * fRed + 0.59 * fGreen + 0.11 * fBlue;
  (G)
#end

Satisfied folks ? That's the greyscaling algorithm for a colour, apply this to
every colour in the scene, and thereyago, BW image.

Ken	be free to use this :-)
Kyle 	haven't tried the hf_grey_16 yet...
Peter 	Alternate solution?
Others	Whooa...

-- 
//Spider 
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);

Post a reply to this message

Um, yes... but you won't get the same result...

OK, I think I should stop bothering everyone after this... But I just want
to prove a little point first:

You CANNOT get the same effect of converting and image to greyscale later by
colouring the objects in your scene with greyscale equivalents.  It doesn't
work.

The reason is simple and I won't go on about it after this :)

If you plan to have only white lights in your scene, fine, it doesn't make
ANY difference (except for reflections) if you convert a colour image to
greyscale, or if you build your scene with the greyscale equivalents.
However, if you are going to use coloured lights, things get tricky.  The
reason it won't work properly is because different colours react in
different ways on other colours.  For example, the highlight or specular on
an object will look like it has a different exposure.  A good example is to
place a yellow sphere with a red light on one side and a blue light on the
other.  If you examine the highlights you'll find that the one produced by
the red light will be exposed more than the one from the blue light.  Now if
you were to convert your scene's colours to greyscale before rendering, this
effect isn't produced because you now only have intensities, so all the
highlights will have a linear progression of magnitude.  This means that you
can no longer produce scenes with realistic lighting (or reflections), and
that's why it is VERY hard to get the right contrast in a B&W scene if
you're going to make it by using intensities.  See?  So, ultimately, Peter's
solutions is the ONLY REAL solution to the problem, because that way you are
ACTUALLY rendering the colour, but it is being converted to greyscale later
(well, not later, still in POV-Ray) using the HF16G option, and then
converted to RGB still using POV-Ray by making a height_field from the
resulting PNG image and then colouring the height_field with a gradient from
black to white.

(Did anyone understand my point?)
OK, I'll shut up now...

--
Lance.


---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone

Post a reply to this message

To support Roland I have assembled a little example and posted it in
povray.binaries.images.

It shows that B/W rendering is *totally* possible directly from POV-Ray
without any postprocessing that would violate the IRTC rules.
Now, somewhere else Kyle wrote that he actually wanted to achieve an
"old-style/western-like" B/W look. That would probably mean a more
brownish/yellowish, probably even scratched and "weathered" look, and *that*
is a totally different story ;-)

Johannes.

Post a reply to this message

On Fri, 12 Mar 1999 21:41:02 -0500, Kyle <joe### [at] geocitiescom>
wrote:

>Hi everyone, thanks for the great response to my post.  Well, I've read
>through all of them and I've come to the conclusion that there is NOT an
>automatic way to do this in POV-Ray.  My goal was for my image to look
>like an old B&W photo, old west style particularly.  I guess it seems to
>me that the only real way to do it is to do what Ken said and just give
>each object a grey color.  I haven't actually tried it yet so I don't
>know how hard it will be.  Actually, I think it may give me some very
>badly needed control over my colors and textures (I can never seem to
>get them quite right).  I'll have a go at it and post my creation in
>binaries.images when I'm done.  Well, here goes nothin'.  
>
>Once again, thanks everyone for racking your brains trying to think of a
>solution.  I really appreciate it.  
>
>		Kyle

By no means do I wish to sound inmodest, but if you would care to test
the solution I offered (I haven't tested it yet), I bet my disability
pension that it will work. If you want to make it look like a really
old picture, yellowish/brown in color, with scratches etc., it is all
a matter of texturing the height_field properly. You can even try to
make it kinda burnt along the edges in the following way:

1. Make the HF16G png
2. Render a b&w HF blah blah (as I explained)
3. Get the image from step 2, apply it to a height_field and overlay
another texture, probably a boxed pattern that is clear inside and
black around 0.95 and above, with some turbulence. 
4. Now using  the result from step 3 as a height_field with a
water_level of, say, 1/255, the edges will look eaten away. Apply the
gradient pattern you want (black->brown->yellowish ?) and overlay it
with the same boxed pigment from step 3, this time a little more
blurry , like

color_map
{
  [0 color Clear]
  [0.9 color Clear]
  [0.9 color Brown filter 1]
  [1 color Brown filter 0]
}

and apply the same turbulence as you did in step 3.

HTH

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

Post a reply to this message

Yep, I knew about the color interactions.
Did a B&W render for the AOL 3D Render Challenge long time ago, but I
converted to grayscale jpg because post-processing isn't as much a
concern there. I was actually working by way of getting an appropriate
enough color image that would look right in all grays.
Think Ken wants a purely artistic manipulation approach.
The hf_gray_16 method needs a orthographic camera.
256 grays is never going to be very good.
Anyone try Spiders idea yet? Sounds interesting, but I'm not sure of how
the color interactions would take place if all are converted to monotone
first then used as the light(s)/texture(s). Same thing as Kens way,
except no manipulation upon them.
Post-conversion is different than pre-conversion no matter I would
think.
Oh, and yes, you can multiply color vectors by -1, i.e.
rgb<.5,.6,.7>*-1, however getting the neutral gray by combining the
positive with negative I don't see happening right.
I tried a simple test, a red object with white light, multiplied both
color vectors by -1 (the only way to see the negative red object). This
makes a similar red object once again. Then I used the result as a
image_map filtered in front of the original object positive red object
and left the negative light.
Well, long story short here, I failed to see a way to get a grayscale
from this sort of thing. Either you get color or you get black only
apparently. Maybe there's still a way, but like I said this was a
"simple test".


Lance Birch wrote:
> 
> Um, yes... but you won't get the same result...
> 
> OK, I think I should stop bothering everyone after this... But I just want
> to prove a little point first:
> 
> You CANNOT get the same effect of converting and image to greyscale later by
> colouring the objects in your scene with greyscale equivalents.  It doesn't
> work.
> 
> The reason is simple and I won't go on about it after this :)
> 
> If you plan to have only white lights in your scene, fine, it doesn't make
> ANY difference (except for reflections) if you convert a colour image to
> greyscale, or if you build your scene with the greyscale equivalents.
> However, if you are going to use coloured lights, things get tricky.  The
> reason it won't work properly is because different colours react in
> different ways on other colours.  For example, the highlight or specular on
> an object will look like it has a different exposure.  A good example is to
> place a yellow sphere with a red light on one side and a blue light on the
> other.  If you examine the highlights you'll find that the one produced by
> the red light will be exposed more than the one from the blue light.  Now if
> you were to convert your scene's colours to greyscale before rendering, this
> effect isn't produced because you now only have intensities, so all the
> highlights will have a linear progression of magnitude.  This means that you
> can no longer produce scenes with realistic lighting (or reflections), and
> that's why it is VERY hard to get the right contrast in a B&W scene if
> you're going to make it by using intensities.  See?  So, ultimately, Peter's
> solutions is the ONLY REAL solution to the problem, because that way you are
> ACTUALLY rendering the colour, but it is being converted to greyscale later
> (well, not later, still in POV-Ray) using the HF16G option, and then
> converted to RGB still using POV-Ray by making a height_field from the
> resulting PNG image and then colouring the height_field with a gradient from
> black to white.
> 
> (Did anyone understand my point?)
> OK, I'll shut up now...
> 
> --
> Lance.
> 
> ---
> For the latest 3D Studio MAX plug-ins, images and much more, go to:
> The Zone - http://come.to/the.zone

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

Post a reply to this message

Johannes Hubert wrote:
> 
> To support Roland I have assembled a little example and posted it in
> povray.binaries.images.
I did it as well. Source in povray.text.scene-files.
 
> It shows that B/W rendering is *totally* possible directly from POV-Ray
> without any postprocessing that would violate the IRTC rules.
Mine as well.

> Now, somewhere else Kyle wrote that he actually wanted to achieve an
> "old-style/western-like" B/W look. That would probably mean a more
> brownish/yellowish, probably even scratched and "weathered" look, and *that*
> is a totally different story ;-)
Nope, just change the formulae a bit, modify to enchance the R+G Values in the
creation. Will work just FINE.


-- 
//Spider 
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);

Post a reply to this message

DEmo out in .binaries.images, is it ok ?
-- 
//Spider 
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);

Post a reply to this message

Not sure, seems there's good points to both images, the color or black &
white, and bad points near as I can tell.
See my reply there.


Spider wrote:
> 
> DEmo out in .binaries.images, is it ok ?
> --
> //Spider
> ( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
> #declare life = rand(seed(42))*sqrt(-1);

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

Post a reply to this message

Gordon <gbe### [at] birdcameroncomau> wrote:
: 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?

  BTW, if you are making a b/w jpeg, you don't have to use all the three
color channels, but you can use just one channel instead (the jpeg format
supports this). It surely will save space this way.
  I don't see the problem in converting from 16-bit b/w PNG to 8-bit
b/w jpeg. It's just an image format conversion.

-- 
main(i,_){for(_?main(i+1,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[--i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Margus Ramst wrote in message <36e974e4.0@news.povray.org>...
>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.


Photoshop loads it fine if you specify a PNG file instead of a TGA file.  It
does truncate to 8 bits, though.

Post a reply to this message