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

I di da new test with my demo-file, this time setting ambient_light 0, and then
changing the Assumed Gamma Value, I did tests on theese settings:
// assumed_gamma 0.5 //Gamma off
assumed_gamma 0.5
assumed_gamma 1.0
assumed_gamma 1.8
assumed_gamma 2.2

The differences are clear, and the most noteworthy difference is the green
lights shadow on the images(It's "lacking" in the macro BW image) as well as a
highlight that is larger in the macro version. other than this, the blue box are
in different shades of black, but not as noteworthy as the difference in the
background. 
I can post the images if you wish.(5*2 files)


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

Post a reply to this message

Sorry, I meant use a negative but only apply it 50%... It's a little thing I
do a lot in Photoshop.  You create a layer with the inverse of the section
you want to remove (so you can take a stain out of a picture for example) so
that you get greyscale areas without changing the hues.  Then you add
another layer on top of that to gie it the colour back.

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

That 10 images? Anyway I think they might go well with this topic.
Did you also try changing Display_Gamma in the Povray.ini yet?
I'm still trying to figure the 16-bit hf_gray_16 output and how it gets
used.
I thought only the red component got used and yet from what I could tell
using a heightfield (png) this isn't the case.


Spider wrote:
> 
> I di da new test with my demo-file, this time setting ambient_light 0, and then
> changing the Assumed Gamma Value, I did tests on theese settings:
> // assumed_gamma 0.5 //Gamma off
> assumed_gamma 0.5
> assumed_gamma 1.0
> assumed_gamma 1.8
> assumed_gamma 2.2
> 
> The differences are clear, and the most noteworthy difference is the green
> lights shadow on the images(It's "lacking" in the macro BW image) as well as a
> highlight that is larger in the macro version. other than this, the blue box are
> in different shades of black, but not as noteworthy as the difference in the
> background.
> I can post the images if you wish.(5*2 files)
> 
> --
> //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

I'll upload.

and as far as I have got it, the display gamma is not in the file, but the
display? Correct or not ?

> I'm still trying to figure the 16-bit hf_gray_16 output and how it gets
> used.
tell me if you find it. It might be in the source, but I don't have that.

> I thought only the red component got used and yet from what I could tell
> using a heightfield (png) this isn't the case.
Nope, it uses the formala, I think.  


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

Post a reply to this message