 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi, I am using a background with transmit to 1 in PNG format and it behaves
exactly like I want it to (it's colored, and it's removable). I just didn't find
how to remove the white outline I get when using anti aliasing?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mr <nomail@nomail> wrote:
> Hi, I am using a background with transmit to 1 in PNG format and it behaves
> exactly like I want it to (it's colored, and it's removable). I just didn't find
> how to remove the white outline I get when using anti aliasing?
The background color getting mixed with antialiased pixels (as well as
semi-transparent surfaces) is a design mistake in 3.7beta which hopefully
will be corrected at some point.
POV-Ray 3.5 behaved the same way, and it made the +UA option quite
useless (except in the cases where you deliberately *don't* use antialiasing
nor (semi)transparent surfaces), so the behavior was fixed in POV-Ray 3.6,
which works properly in this respect.
The behavior was reverted to the same as 3.5 when the code was redesigned
in 3.7beta. It should be fixed back to the way 3.6 does it before the final
release.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 04.07.2010 11:19, schrieb Mr:
> Hi, I am using a background with transmit to 1 in PNG format and it behaves
> exactly like I want it to (it's colored, and it's removable). I just didn't find
> how to remove the white outline I get when using anti aliasing?
In short: You can't. Not with beta 38.
The PNG file format is specified to use what is called straight - or
non-premultiplied - alpha. In effect, this means that if you try to
remove the alpha channel by simply ignoring it, all semi-transparent
areas get overly bright. Instead, the software post-processing the image
would have to properly compose it against a black background (= multiply
color by alpha) to get what you probably expect.
Some other image file formats, such as OpenEXR and TIFF, officially use
associated - or premultiplied - alpha, which means that the data is
stored in the file already pre-composed against a black background, so
simply ignoring alpha would indeed give what you'd expect.
Unfortunately, POV-Ray doesn't do TIFF output, and OpenEXR isn't
widespread yet (and it is allegedly typically used in straight alpha
mode in violation of the specs).
POV-Ray 3.6 got that alpha thing pretty messed up, always writing
associated alpha no matter what the file format (effectively getting
semi-transparency too dark with PNG and TGA format), while at the same
time always expecting straight alpha for all image input files
(effectively getting semi-transparency too dark with TIFF format). This
has been changed with beta 38.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tag povrayorg> wrote:
> Mr <nomail@nomail> wrote:
> > Hi, I am using a background with transmit to 1 in PNG format and it behaves
> > exactly like I want it to (it's colored, and it's removable). I just didn't find
> > how to remove the white outline I get when using anti aliasing?
> The background color getting mixed with antialiased pixels (as well as
> semi-transparent surfaces) is a design mistake in 3.7beta which hopefully
> will be corrected at some point.
> POV-Ray 3.5 behaved the same way, and it made the +UA option quite
> useless (except in the cases where you deliberately *don't* use antialiasing
> nor (semi)transparent surfaces), so the behavior was fixed in POV-Ray 3.6,
> which works properly in this respect.
> The behavior was reverted to the same as 3.5 when the code was redesigned
> in 3.7beta. It should be fixed back to the way 3.6 does it before the final
> release.
Actually I have to redact what I wrote above, as my information was based
on a much older beta. I tried the newest beta, and the +UA seems to work ok
with antialiasing after all. (There still seems to be some problems with
media against transparent background, though.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 04.07.2010 12:24, clipka wrote:
> Some other image file formats, such as OpenEXR and TIFF, officially use
> associated - or premultiplied - alpha, which means that the data is
> stored in the file already pre-composed against a black background, so
> simply ignoring alpha would indeed give what you'd expect.
To clarify and to prevent a new bug within POV-Ray:
I do not know where you did get the information/impression that TIFF
"officially use associated - or premultiplied - alpha". This is not true
as TIFF allows *everything*.
You might have misread the TIFF 6.0 specs section 18: Associated Alpha
Handling. This section applies only *IF* the "ExtraSamples" tag is
present and the value of the tag reads 1. In most cases (in all if the
TIFF was written by any Adobe software) the value of the ExtraSample tag
will be 0 - i.e. unassociated, non-pre-multiplied, straight.
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 04.07.2010 15:06, Ive wrote:
> On 04.07.2010 12:24, clipka wrote:
>> Some other image file formats, such as OpenEXR and TIFF, officially use
>> associated - or premultiplied - alpha, which means that the data is
>> stored in the file already pre-composed against a black background, so
>> simply ignoring alpha would indeed give what you'd expect.
>
>
> To clarify and to prevent a new bug within POV-Ray:
>
> I do not know where you did get the information/impression that TIFF
> "officially use associated - or premultiplied - alpha". This is not true
> as TIFF allows *everything*.
> You might have misread the TIFF 6.0 specs section 18: Associated Alpha
> Handling. This section applies only *IF* the "ExtraSamples" tag is
> present and the value of the tag reads 1. In most cases (in all if the
> TIFF was written by any Adobe software) the value of the ExtraSample tag
> will be 0 - i.e. unassociated, non-pre-multiplied, straight.
>
> -Ive
>
Umm, and to correct myself an "ExtraSample" value of 0 actually means
undefined but was always used by Adobe to indicate unassociated alpha,
(but could actually mean something else e.g. no "alpha" data at all).
The correct value to identify unassociated, non-pre-multiplied alpha
would be 2.
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ive <"ive### [at] lilysoftorg"> wrote:
> On 04.07.2010 15:06, Ive wrote:
> > On 04.07.2010 12:24, clipka wrote:
> >> Some other image file formats, such as OpenEXR and TIFF, officially use
> >> associated - or premultiplied - alpha, which means that the data is
> >> stored in the file already pre-composed against a black background, so
> >> simply ignoring alpha would indeed give what you'd expect.
> >
> >
> > To clarify and to prevent a new bug within POV-Ray:
> >
> > I do not know where you did get the information/impression that TIFF
> > "officially use associated - or premultiplied - alpha". This is not true
> > as TIFF allows *everything*.
> > You might have misread the TIFF 6.0 specs section 18: Associated Alpha
> > Handling. This section applies only *IF* the "ExtraSamples" tag is
> > present and the value of the tag reads 1. In most cases (in all if the
> > TIFF was written by any Adobe software) the value of the ExtraSample tag
> > will be 0 - i.e. unassociated, non-pre-multiplied, straight.
> >
> > -Ive
> >
>
> Umm, and to correct myself an "ExtraSample" value of 0 actually means
> undefined but was always used by Adobe to indicate unassociated alpha,
> (but could actually mean something else e.g. no "alpha" data at all).
> The correct value to identify unassociated, non-pre-multiplied alpha
> would be 2.
>
> -Ive
I'm happy that there has indeed been some improvement. I hope you don't mean
that it's impossible to get the desired behaviour? For now I just have
deactivate either anti aliasing or background alpha in the blender exporter. And
sorry to get to blender again in the discussion, I am prepared for someone to
answer that it simply is buggy or wrong, but it behaves without any of its
million count userbase complaining. It doesn't seem to premultiply the
background as there is no trace of it when we use the show alpha button in the
image window. I made a little screenshot with the process to render and see what
I mean if you have a version of blender around:
http://dl.free.fr/ucR4swaMX
Maybe the source code can be an inspiration?... just for this very point of
course, no matter how bad it may be for anything else :-P ?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 05.07.2010 11:44, schrieb Mr:
> sorry to get to blender again in the discussion, I am prepared for someone to
> answer that it simply is buggy or wrong, but it behaves without any of its
> million count userbase complaining. It doesn't seem to premultiply the
> background as there is no trace of it when we use the show alpha button in the
> image window. I made a little screenshot with the process to render and see what
> I mean if you have a version of blender around:
The alpha premultiplication issue only shows very openly with
semi-transparent stuff.
A simple test whether some piece of software does it right or not should
be as follows:
(1) Render a scene with anti-aliasing and/or semi-transparent items and
some pitch black object behind it filling the whole view.
(2) Remove that pitch black thing and render again with transparency
output. View this image against a pitch black background.
If the images don't look 100% the same, /something/ is wrong. If in (2)
semi-transparent areas appear darker and anti-aliased edges seem to
"shrink" a little bit, chances are the software handles the PNG alpha
channel wrong.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Am 05.07.2010 11:44, schrieb Mr:
>
> > sorry to get to blender again in the discussion, I am prepared for someone to
> > answer that it simply is buggy or wrong, but it behaves without any of its
> > million count userbase complaining. It doesn't seem to premultiply the
> > background as there is no trace of it when we use the show alpha button in the
> > image window. I made a little screenshot with the process to render and see what
> > I mean if you have a version of blender around:
>
> The alpha premultiplication issue only shows very openly with
> semi-transparent stuff.
>
> A simple test whether some piece of software does it right or not should
> be as follows:
>
> (1) Render a scene with anti-aliasing and/or semi-transparent items and
> some pitch black object behind it filling the whole view.
>
> (2) Remove that pitch black thing and render again with transparency
> output. View this image against a pitch black background.
>
> If the images don't look 100% the same, /something/ is wrong. If in (2)
> semi-transparent areas appear darker and anti-aliased edges seem to
> "shrink" a little bit, chances are the software handles the PNG alpha
> channel wrong.
If I understood your test correctly, blender passed it. I used the antialiasing
from this scene:
http://dl.free.fr/hj1KvmvaZ
-render with F12,
-then hit j to store in secondary buffer,
-back to main UI window, push 1 key on the non numpad keyboard to isolate the
layer without the black
object. (black object will disappear from 3D view and render)
-render again (F12)
-hit j key a few times to compare the two render buffers,
you can do so while zoomed with the mouse wheel.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 05.07.2010 19:57, schrieb Mr:
> If I understood your test correctly, blender passed it. I used the antialiasing
> from this scene:
I'm a bit surprised about this; however, it doesn't necessarily mean
that blender is doing everything right. Maybe it treats alpha
differently when using the internal render engine than when calling an
external program.
Once again, my suggestion is you present this issue to the blender
community.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
