 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
is there a way to keep the alpha value for a partially transparent
object ?
Regarding my earlier question, a transparent background color works
well together with the +UA switch but if any object
has a transparency < 1.0 it will get the appropriately mixed color
(object(s) + background color) and appears to have a final
transparency of 0. In most cases this is exactly what you want. But what
if I want to generate say a 50% transparent square and keep that
information in my image so that when I move it over my screen, I would
see the local background shining through. Even this is easy as long as
the transparency is uniform but what if it is more complex say one uses
a color_map with transparency gradients ???
Any suggestions are greatly appreciated.
Lothar.
--
Dr. Lothar Esser
NIH / NCI
Tel. 301-435-6163
email les### [at] helix nihgov
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Lothar Esser wrote:
>
> is there a way to keep the alpha value for a partially transparent
> object ?
If you don't find any other solution, you can use just red and blue
light (for example), and a green background. Then create an alpha
channel from the green channel, and use it with the image rendered with
normal light and background.
--
JM
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jean-Michel Grimaldi wrote:
> If you don't find any other solution, you can use just red and blue
> light (for example), and a green background. Then create an alpha
> channel from the green channel, and use it with the image rendered with
> normal light and background.
Thanks. Interesting solution ...
L.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jean-Michel Grimaldi <jm### [at] viaecpfr> wrote:
: If you don't find any other solution, you can use just red and blue
: light (for example), and a green background.
Note that even when there's only a red and blue lights, the objects can
show green too.
--
#local D=array[6]{11117333955,7382340,3358,3900569407,970,4254934330}
#local I=0;#macro M()<mod(D[I],13)-6,mod(div(D[I],13),8)-3,10>#end
#while(I<6)cylinder{M()#local D[I]=div(D[I],104);M().1
pigment{rgb M()}}#local I=(D[I]>99?I:I+1);#end /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> Note that even when there's only a red and blue lights, the objects can
> show green too.
I meant ambient light too.
--
JM
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 23 Apr 2001 20:17:43 -0400, Lothar Esser wrote:
>Hi,
>
> is there a way to keep the alpha value for a partially transparent
>object ?
>Regarding my earlier question, a transparent background color works
>well together with the +UA switch but if any object
>has a transparency < 1.0 it will get the appropriately mixed color
>(object(s) + background color) and appears to have a final
>transparency of 0.
I don't see this. If I render this:
box {<-1,-1,0> <1,1,.01> pigment {rgbt <1,0,0,.5>} finish {ambient 1}}
camera {location -5*z look_at 0}
using command-line options +fn +ua, I get a PNG image with a red square
in it. Loading that into Photoshop 6, I see that the red square has a
color of 191 (bad, because as you said that is mixed with the black
background, which doesn't seem right) but a transparency of .5 (which
also probably isn't right, since it should represent the cumulative
transparency along the ray, or .25) The latter problem will definitely
be fixed in 3.5, which will generate an image with a transparency
of .25, but the former problem, if it is a problem, appears unchanged
in the current development build.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
>
> I don't see this.
gimp tells me "libpng-1.0.8 error: Too many IDAT's found".
Though I don't know whether it is a libpng reading bug or a povray
writing bug.
--
JM
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 24 Apr 2001 21:28:52 +0200, Jean-Michel Grimaldi wrote:
>Ron Parker wrote:
>>
>> I don't see this.
>
>gimp tells me "libpng-1.0.8 error: Too many IDAT's found".
>Though I don't know whether it is a libpng reading bug or a povray
>writing bug.
Hmmm....
|[ron@fwi ron]$ ./pngcheck -v transp.png
|File: transp.png (1051 bytes)
| chunk IHDR at offset 0x0000c, length 13
| 320 x 240 image, 32-bit RGB+alpha, non-interlaced
| chunk gAMA at offset 0x00025, length 4: 0.45455
| chunk sBIT at offset 0x00035, length 4: red = 8 green = 8 blue = 8 alpha = 8
| chunk IDAT at offset 0x00045, length 48
| zlib: deflated, 32K window, default compression
| chunk IDAT at offset 0x00081, length 45
| chunk IDAT at offset 0x000ba, length 45
| chunk IDAT at offset 0x000f3, length 100
| chunk IDAT at offset 0x00163, length 82
| chunk IDAT at offset 0x001c1, length 82
| chunk IDAT at offset 0x0021f, length 82
| chunk IDAT at offset 0x0027d, length 82
| chunk IDAT at offset 0x002db, length 129
| chunk IDAT at offset 0x00368, length 45
| chunk IDAT at offset 0x003a1, length 45
| chunk IDAT at offset 0x003da, length 45
| chunk IEND at offset 0x00413, length 0
|No errors detected in transp.png (99.7% compression).
That's based on libpng, too (so's POV's PNG code.) Offhand I'd say it's a
GIMP bug, or maybe your GIMP is linked against a bad version of libpng.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
