 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
I did an image I think last December that was titled I believe "Black
and White Povatography". It is in the images group. In that I explored the
wonderful world of black and white photography as represented in a raytracing
program that is commonly used for color image production. Anyway My solutions
was of course to use shades of gray for all objects in the scene. It's really
not that difficult to do since all of your pigments can be designed using a
single rgb float value - pigment{rgb .5} would be 50% gray for example.
The most difficult part is choosing the correct finish statements and lighting
models to get the same sharp contrast that b/w photos are famous for. Getting
sharp shadows is a trademark item for b/w photos that I had trouble recreating.
I think there is a certain limitation in the represention of b/w images on
an electronic medium but that is a nother story.
As far as special settings for Pov I know of no setting that will allow a
256 shades of grey pallet or display output as used as the standard for
electronic b/w image reproduction.
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I also did a B&W image merely by using only shades of grey in my image.
You might also consider a brownish image by using a filter. My image is
in the Element's round of the IRTC and is titled DarkLight.
Steve
Ken wrote:
>
> 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
>
> I did an image I think last December that was titled I believe "Black
> and White Povatography". It is in the images group. In that I explored the
> wonderful world of black and white photography as represented in a raytracing
> program that is commonly used for color image production. Anyway My solutions
> was of course to use shades of gray for all objects in the scene. It's really
> not that difficult to do since all of your pigments can be designed using a
> single rgb float value - pigment{rgb .5} would be 50% gray for example.
> The most difficult part is choosing the correct finish statements and lighting
> models to get the same sharp contrast that b/w photos are famous for. Getting
> sharp shadows is a trademark item for b/w photos that I had trouble recreating.
> I think there is a certain limitation in the represention of b/w images on
> an electronic medium but that is a nother story.
> As far as special settings for Pov I know of no setting that will allow a
> 256 shades of grey pallet or display output as used as the standard for
> electronic b/w image reproduction.
>
> --
> Ken Tyler
>
> mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The best way is to convert all the colours in your scene to shades of gray
using a grayscale algorithm. You can't currently tell POV-Ray to render to
greyscale.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Using a filter? Please elaborate. I'd like to know how you do this.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Richard Speir wrote:
>
> Using a filter? Please elaborate. I'd like to know how you do this.
A simple way would be to use something like a box in front of the camera
with a filtering pigment. Only certain colors owuld be allowed to pass
while others would be blocked. If you use several layers of pigments
you can greatly lower the bands of permissable colors allowed to pass.
I'm not sure if this is what he had in mind but it will work to some extent.
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbell net> wrote:
: Anyway My solutions was of course to use shades of gray for all objects
: in the scene.
How do you model this:
Three objects: One is yellow, one is cyan and one is white.
Two light sources: One is red and the other is blue.
Of course the red light source only illuminates the yellow and the white
object while the blue light source only illuminates the cyan and also
the white object.
I want this image in b/w.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Mika wrote:
>
> Ken <tyl### [at] pacbellnet> wrote:
> : Anyway My solutions was of course to use shades of gray for all objects
> : in the scene.
>
> How do you model this:
>
> Three objects: One is yellow, one is cyan and one is white.
> Two light sources: One is red and the other is blue.
> Of course the red light source only illuminates the yellow and the white
> object while the blue light source only illuminates the cyan and also
> the white object.
> I want this image in b/w.
>
> --
> main(i,_){for(_?main(i+1,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[--i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
If you really want this so badly I suggest...
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Mika <war### [at] cctutfi> writes:
> How do you model this:
>
> Three objects: One is yellow, one is cyan and one is white.
> Two light sources: One is red and the other is blue.
> Of course the red light source only illuminates the yellow and the white
> object while the blue light source only illuminates the cyan and also
> the white object.
> I want this image in b/w.
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 is (at
least in Targa Truevision format) a sixteen bit per pixel black and
white image file.
Roland.
--
Roland Mas
- Ogenki desuka, yau de poêle ?
- Genki desu, ture en zinc.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Mika <war### [at] cctutfi> writes:
> How do you model this:
>
> Three objects: One is yellow, one is cyan and one is white.
> Two light sources: One is red and the other is blue.
> Of course the red light source only illuminates the yellow and the white
> object while the blue light source only illuminates the cyan and also
> the white object.
> I want this image in b/w.
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
- Ogenki desuka, yau de poêle ?
- Genki desu, ture en zinc.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
One method would be to use the hue and intensity values of the color to
form the grey scale value of that color, and then render the grey scale
colors. Perhaps applying a greyscale equation to your pigments?
Steve
Nieminen Mika wrote:
>
> Ken <tyl### [at] pacbellnet> wrote:
> : Anyway My solutions was of course to use shades of gray for all objects
> : in the scene.
>
> How do you model this:
>
> Three objects: One is yellow, one is cyan and one is white.
> Two light sources: One is red and the other is blue.
> Of course the red light source only illuminates the yellow and the white
> object while the blue light source only illuminates the cyan and also
> the white object.
> I want this image in b/w.
>
> --
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Lance Birch wrote in message <36e8a932.0@news.povray.org>...
>The best way is to convert all the colours in your scene to shades of gray
>using a grayscale algorithm. You can't currently tell POV-Ray to render to
>greyscale.
Sure you can!
Check out the global-settings option "HF_Gray_16" (it has it's own little
chapter in the docs BTW).
Varsågod!
Johannes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
So it goes...
My answer lingered a bit in the outbox, and when I looked the next time,
Roland had already given the correct answer :-) - by then my answer was
already posted ...
Johannes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Didn't somebody post a POV ray file that converted from RGB to HSB and HSV...
those would probably be most helpful in created a B&W image.
Stephen Lavedas wrote:
> One method would be to use the hue and intensity values of the color to
> form the grey scale value of that color, and then render the grey scale
> colors. Perhaps applying a greyscale equation to your pigments?
>
> Steve
>
> Nieminen Mika wrote:
> >
> > Ken <tyl### [at] pacbellnet> wrote:
> > : Anyway My solutions was of course to use shades of gray for all objects
> > : in the scene.
> >
> > How do you model this:
> >
> > Three objects: One is yellow, one is cyan and one is white.
> > Two light sources: One is red and the other is blue.
> > Of course the red light source only illuminates the yellow and the white
> > object while the blue light source only illuminates the cyan and also
> > the white object.
> > I want this image in b/w.
> >
> > --
> > main(i,_){for(_?main(i+1,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[--i]
> > ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
--
Josh English
eng### [at] spiritonecom
www.spiritone.com/~english
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
>
> - Ogenki desuka, yau de poêle ?
> - 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gordon wrote:
>
> 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>
I think in this case it is more an issue of taking a 16m color image
and converting it to 256 shades of gray that would be in non compliance
with the rules. If you are silly enough to take make a rendering in Pov's
16bit greyscale, convert it, and then submit it to the competition you
might just get sympathy votes for being so stupid.
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gee!!! I've used that thing HUNDREDS of times and yet I've totally
forgotten it existed!!! he he he
And of course, that's right, you'd think that after studying physics for 6
months and a huge chapter on colour wavelengths I would have realised that
you can't just use an algorithm to convert the pigments in your scene
because then the lights won't react in the right way!!!
Maybe I should actually consider THINKING before I post!!!
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
OK, I've got an idea but I can't remember if it's possible or not (it's been
a while since I've used POV-Ray).
Can you render the image in normal colour, then SOMEHOW work out a way of
rendering the two images over each other with negative colour indices? That
way the resulting image would be black and white...
The only problem is, how do you get an inverse of the picture without doing
image editing? Is there a way to multiply the image_map pigments by -1?
This would solve all the problems, if it were possible. Any ideas?
Of course the other way (WHICH WOULD TAKE MUCH LONGER!!!) is to write a
macro which reads from the Targa file and creates an array of boxes with the
black and white colour conversions for each pixel so that when rendered you
would have the image again... You'd have to turn anti-aliasing off...
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Lance Birch wrote:
>
> OK, I've got an idea but I can't remember if it's possible or not (it's been
> a while since I've used POV-Ray).
>
> Can you render the image in normal colour, then SOMEHOW work out a way of
> rendering the two images over each other with negative colour indices? That
> way the resulting image would be black and white...
>
> The only problem is, how do you get an inverse of the picture without doing
> image editing? Is there a way to multiply the image_map pigments by -1?
>
> This would solve all the problems, if it were possible. Any ideas?
>
> Of course the other way (WHICH WOULD TAKE MUCH LONGER!!!) is to write a
> macro which reads from the Targa file and creates an array of boxes with the
> black and white colour conversions for each pixel so that when rendered you
> would have the image again... You'd have to turn anti-aliasing off...
>
> --
> Lance.
I don't know why anybody would go through the trouble. It is very easy
to make grey scale images without resorting to a bunch of tricks or having
to use post processing techniques. Grey/Gray is an easy color to specifiy
in Pov and will work with any pigment pattertn and texture types. It really
is not that difficult to choose the right colors. I have more trouble getting
the right shades of colors than I do shades of grey and I'm pretty good at
color control.
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
See what a mess you started here Kyle ?
One other possibility that the folks in this crowd can grind donw the
merit of is using a reflection vector with every object in the scene.
If you use reflection <0.5,0.5,0.5> the color reflected off the object
will by a 50% gray and the rest will be filtered out. How well this
would work is untested and I don't know if you can stack reflection
vectors on top of each other. If you can it might be possible to make
a global reflection for the whole scene. Or - maybe not !
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
NO NO NO!!! It DOESN'T WORK!!!
Ken, have you tried a red light source on a red and white sphere lately?
I'd like you to try making that in greyscale... This is the point I missed
in my first post and I really should have pointed it out earlier. Remember,
because the light sources can be different colours, the surfaces of objects
will react in different ways. Like a blue shere will look different under
red light... and another coloured sphere under the same light will look
different again. If you convert the lights to just intenisties (which is
what you're suggesting) the surfaces won't react differently so the objects
won't appear realistic.
Remember, the problem lies in the wavelengths.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
Ken wrote:
>
> 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
>
> See what a mess you started here Kyle ?
>
> One other possibility that the folks in this crowd can grind donw the
> merit of is using a reflection vector with every object in the scene.
> If you use reflection <0.5,0.5,0.5> the color reflected off the object
> will by a 50% gray and the rest will be filtered out. How well this
> would work is untested and I don't know if you can stack reflection
> vectors on top of each other. If you can it might be possible to make
> a global reflection for the whole scene. Or - maybe not !
>
> --
> Ken Tyler
>
> mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Lance Birch wrote:
>
> NO NO NO!!! It DOESN'T WORK!!!
>
> Ken, have you tried a red light source on a red and white sphere lately?
> I'd like you to try making that in greyscale... This is the point I missed
> in my first post and I really should have pointed it out earlier. Remember,
> because the light sources can be different colours, the surfaces of objects
> will react in different ways. Like a blue shere will look different under
> red light... and another coloured sphere under the same light will look
> different again. If you convert the lights to just intenisties (which is
> what you're suggesting) the surfaces won't react differently so the objects
> won't appear realistic.
>
> Remember, the problem lies in the wavelengths.
>
> --
> Lance.
YES YES YES ! IT DOES TOO WORK !!!!!
By my will,
My will alone,
I set my mind in motion...
Grey is grey is grey is grey and you can't turn it red or blue in a
grey world.
It's the artistic interpretation of the colors applied to the medium
that will make it work and the physics of are not important to the the
minds interpretation of the colors. If I have an object I want colored
a certain way THAT is physical reality. If I have to match the grey
colors in a black and white photo then there may be an issue but only
if I choose to make an issue out of it. Fact is with art you don't
have to care about physical reality. Show me a painting by one of
the "Masters" that really looks like a 3D human were standing there.
I have yet to see one.
Get my point or should I rationalize it a bit more for you ?
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I hate to tell this to you Mr Tyler but this is one time that I AM RIGHT!
I want you to replicate this for me in greyscale... using your so-called
"rationalisations".
You have a yellow sphere, a red light to the left, a blue light to the
right. The result after rendering and conversion to greyscale is NOT the
same as converting the colours to intesities and then rendering.
Do you want me to prove it with pictures?
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I hate to tell you this but Ken is wrong, the result CANNOT be the same.
For example, if you have a yellow sphere, a red light to the left, a blue
light to the right, after rendering and converting to greyscale the result
with NOT be the same as converting the colours to grey first and then
rendering. (As the converted lights will not react the same way with the
objects because they no longer obey colour laws of wavelength, they all have
mono-wavelengths)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
UH-OH....The challenge has been issued....the stakes are high....what'll
happen next in this high drama matchup between 2 leading POV-Ray
superpowers??? Stay tuned to find out....
Kyle
Lance Birch wrote:
>
> I hate to tell this to you Mr Tyler but this is one time that I AM RIGHT!
>
> I want you to replicate this for me in greyscale... using your so-called
> "rationalisations".
>
> You have a yellow sphere, a red light to the left, a blue light to the
> right. The result after rendering and conversion to greyscale is NOT the
> same as converting the colours to intesities and then rendering.
>
> Do you want me to prove it with pictures?
>
> --
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Oh don't worry, I realized that early on. I'm only planning on using
one white light anyway. If I do happen to add more they will definately
be white also. That would be WAY too hard to try to compensate for
different light colors and probably far out of my league as well.
Kyle
Lance Birch wrote:
>
> I hate to tell you this but Ken is wrong, the result CANNOT be the same.
> For example, if you have a yellow sphere, a red light to the left, a blue
> light to the right, after rendering and converting to greyscale the result
> with NOT be the same as converting the colours to grey first and then
> rendering. (As the converted lights will not react the same way with the
> objects because they no longer obey colour laws of wavelength, they all have
> mono-wavelengths)
>
> --
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
:) Yes, especially considering it isn't possible ;-)
Come on Ken, show your face! Do you want me to prove it?
(I never back down from a wavelength challenge!!! ;-)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
After repeated taunting by Lance, Ken has yet to respond. Has he given
up? Has he admitted defeat? Or does Ken have an ace up his sleeve?
What'll happen next? Don't touch that dial kids!!
Kyle
Lance Birch wrote:
>
> :) Yes, especially considering it isn't possible ;-)
>
> Come on Ken, show your face! Do you want me to prove it?
>
> (I never back down from a wavelength challenge!!! ;-)
>
> --
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
By the way Ken, if you are planning on coming up with some strange excuse, I
already have the images that will prove my theory correct! BA HA HA HA!!!
;-)
(And now, for a commercial break)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In any case, I've just been chatting with Peter and I think it's important
that I draw attention to his post of 13/03/99 6:12 where he has a final
solution to all these problems :)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
#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
|
|
| |
| |
|
|
From: Bob Hughes
Subject: Re: Rendering in B&W? - RIGHT, THAT'S IT!!! ;-)
Date: 13 Mar 1999 09:42:46
Message: <36EA7925.348CD38A@aol.com>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
