[Bf-committers] Alpha changes

[Sergey Sharybin]

Hi,

This will be changed for 2.66. Basically idea we discussed was to have:

- Default view is to RGB + Alpha, so you could see that buffer does have
alpha and not being confused by possible feather-like falloff which would
be displayed as RGB only atm
- RGB without alpha, displaying RGB channels only, alpha will have no
affect at all. That's how initially alpha worked after alpha premul cleanup
- Alpha channel only, where alpha is displaying as grayscale image
- Z channel

This is in my list to be done in next couple of days.

P.S. That's difficult to say which approach preserves more compatibility
with 2.65, but that's how we plan to make it work now.


On Sun, Jan 27, 2013 at 11:03 PM, David <erwin94 at gmx.net> wrote:

> Hi all,
>
> first of all, I want to say that I like the more unified approach to alpha
> handling that is currently in trunk. But I feel there are still some issues
> that will cause confusion for users:
>
> Quick recap first:
>
> - float buffers are assumed to be premultiplied/associated alpha
> - byte buffers are assumed to be unpremultiplied/unassociated/straight
> alpha
>
> This works well for most calculations and file outputs, and where it does
> not
> fit a conversion can be added.
>
> The issues arise only for display: If you want to have a valid composite
> output, it should be a premultiplied image (as the compositor works with
> float buffers).
> This leads to the correct display in the image viewer "Color and Alpha"
> mode,
> and all file outputs are correct as well. But the "Color" mode of the
> image viewer is weird: currently it premultiplies the unpremultiplied byte
> buffer,
> but what it really should display is the rgb color
> values without taking alpha into account at all. This is slightly
> inconsistent
> with the rules above: the image viewer uses a byte buffer for display, but
> what
> I expect to see is the unmodified premultiplied values. This is for a
> couple of
> reasons:
>
> - backwards compatibility: 2.65 and before showed this in the "Color" mode.
>
> - actually seeing whats in your image: at the moment you have no chance to
>   see what is in your image in areas where alpha is 0 (while this might
> seem
>   intuitive at first there are valid reasons to keep colors in 0 alpha
> areas
>   and this is a common compositing technique for illuminating but
> transparent
>   objects).
>
> - not distorting colors for alpha > 1: if alpha > 1 the unpremultiply on
> the
>   way to the byte buffer darkens this part of the image and the premultiply
>   of the image viewer cannot undo this, as alpha is clamped by then.
>
> - and at last: I would expect a "Color" display mode (as opposed to a
> "Color and Alpha" mode)
>   to NOT take alpha into account
>
>
> My current workaround is to have an "set alpha" with a alpha value of 1 at
> the
> end of my composites that I disable for "Color and Alpha" mode and enable
> for
> "Color" mode. While I like the changes to alpha handling, this is not much
> better
> than the unpremultiply that was necessary in 2.65 and before for a correct
> "Color
> and Alpha" mode. And as this has been refactored anyway for 2.66, we
> should strive
> to get it correct.
>
> till then, David.
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
With best regards, Sergey Sharybin