Alpha channel color output #53265

New Issue

Konstantins Visnevskis · 2017-11-07T20:28:42+01:00

2017-11-07 20:28:42 +01:00

System Information
Win8.1x64, 3x gtx580

Blender Version
2.79

Short description of error
For the long time I was wondering why is it impossible to render alpha-translucent colors in blender. It seemed like an obvious case of incorrect choice of premultiplication on my part, however regardless of what nodes or math I applied to output channels, the best I could do was faking it to look less prominent for each particular case.

So now I tried just outputting pure rgba(1, .5, .25, .25). Which in render view and upon saving gets outputted as a pure grey (or white with <1 alpha). This happens after all the node transformations have been done as in the nodes the color is recoverable, however once if it gets to "composite" view and/or saving, some color transformation gets applied affecting colors by intermediate alpha values. I get that color space transformations are unavoidable, however no possible transformation leading to particular result can be right.

Switching "View" color space from default/raw to others produces seemingly correct result for respective color spaces, but default/raw output, desaturates colors of low-intermediate alpha for some reason.

Not sure if somehow relevant - the Alpha Over compositing node produces alike result before even composite if the render image is being composited over a zero-alpha-white, while keeping everything intact over zero-alpha-black. That is - final output in semi transparent areas acts as if the image was composited over zero-alpha-white or gray before viewing/saving.

Exact steps for others to reproduce the error
color.blend

Render -> output is grey

**System Information** Win8.1x64, 3x gtx580 **Blender Version** 2.79 **Short description of error** For the long time I was wondering why is it impossible to render alpha-translucent colors in blender. It seemed like an obvious case of incorrect choice of premultiplication on my part, however regardless of what nodes or math I applied to output channels, the best I could do was faking it to look less prominent for each particular case. So now I tried just outputting pure rgba(1, .5, .25, .25). Which in render view and upon saving gets outputted as a pure grey (or white with <1 alpha). This happens after all the node transformations have been done as in the nodes the color is recoverable, however once if it gets to "composite" view and/or saving, some color transformation gets applied affecting colors by intermediate alpha values. I get that color space transformations are unavoidable, however no possible transformation leading to particular result can be right. Switching "View" color space from default/raw to others produces seemingly correct result for respective color spaces, but default/raw output, desaturates colors of low-intermediate alpha for some reason. Not sure if somehow relevant - the Alpha Over compositing node produces alike result before even composite if the render image is being composited over a zero-alpha-white, while keeping everything intact over zero-alpha-black. That is - final output in semi transparent areas acts as if the image was composited over zero-alpha-white or gray before viewing/saving. **Exact steps for others to reproduce the error** [color.blend](https://archive.blender.org/developer/F1103282/color.blend) - Render -> output is grey

Konstantins Visnevskis commented

2017-11-07 20:28:42 +01:00

Changed status to: 'Open'

Konstantins Visnevskis commented

2017-11-07 20:28:42 +01:00

Added subscriber: @KonstantinsVisnevskis

Brecht Van Lommel commented

2017-11-12 20:20:35 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2017-11-12 20:20:35 +01:00

Changed status from 'Open' to: 'Archived'

Brecht Van Lommel closed this issue

2017-11-12 20:20:35 +01:00

Brecht Van Lommel self-assigned this 2017-11-12 20:20:35 +01:00

Brecht Van Lommel commented

2017-11-12 20:20:35 +01:00

There's no bug here as far as I can tell, but some more user control would be good. See also the discussion in #52680.

Fundamentally, it is impossible to do correct color management on images with alpha. Only when the background color is known can this be done, so when doing color management on such images Blender does a kind of thing that looks OK-ish on most backgrounds but is now quite correctly. Better may be to make some setting for this, there is no way to always automatically do the expected thing.

Further, Blender rendering and compositing works with premultiplied alpha. That means a color like (1, .5, .25, .25) is interpreted as (4, 2, 1) without alpha, and such very bright values get clipped by the default view transform. A different view transform can better preserve such HDR colors.

There's no bug here as far as I can tell, but some more user control would be good. See also the discussion in #52680. Fundamentally, it is impossible to do correct color management on images with alpha. Only when the background color is known can this be done, so when doing color management on such images Blender does a kind of thing that looks OK-ish on most backgrounds but is now quite correctly. Better may be to make some setting for this, there is no way to always automatically do the expected thing. Further, Blender rendering and compositing works with premultiplied alpha. That means a color like (1, .5, .25, .25) is interpreted as (4, 2, 1) without alpha, and such very bright values get clipped by the default view transform. A different view transform can better preserve such HDR colors.

Konstantins Visnevskis commented

2017-11-12 21:50:26 +01:00

Thanks for the link and I understand the problems with background-color/premultiplication, but it seems taken a bit to extreme.
Whether the render layer is being passed into compositing premultiplied or not is a matter of preference, as long as it's consistent, but unless I fail to see something else, explicit values and channel transforms shouldn't be affected by any post processing "behind the scenes" before final output.
That is - nodes like "Combine RGBA" (maybe Color Input) shouldn't do any post-processing on values passed to them. In contrast, a "Set Alpha" node can be expected to do premultiplication as the user just expects it to work within given color system (which as you said is premultiplied), but nodes like "Separate/Combine RGBA" imply and are needed so that manual transforms can be made. And, I mean - it's not exactly manual, if it's being automatically transformed on the spot :)
Sure it'd be great to have a fancy "unpremultiplied" checkbox here and there, but given there are options to do something alike to math on channels, there should be no obstacle to output anything imaginable without the checkbox, by doing manually at least.

Edit: said is valid at least for alpha. I do realize colors can get very non-linear and basically unmanageable by average user, but that shouldn't be the case for alpha.

Thanks for the link and I understand the problems with background-color/premultiplication, but it seems taken a bit to extreme. Whether the render layer is being passed into compositing premultiplied or not is a matter of preference, as long as it's consistent, but unless I fail to see something else, explicit values and channel transforms shouldn't be affected by any post processing "behind the scenes" before final output. That is - nodes like "Combine RGBA" (maybe Color Input) shouldn't do any post-processing on values passed to them. In contrast, a "Set Alpha" node can be expected to do premultiplication as the user just expects it to work within given color system (which as you said is premultiplied), but nodes like "Separate/Combine RGBA" imply and are needed so that manual transforms can be made. And, I mean - it's not exactly manual, if it's being automatically transformed on the spot :) Sure it'd be great to have a fancy "unpremultiplied" checkbox here and there, but given there are options to do something alike to math on channels, there should be no obstacle to output anything imaginable without the checkbox, by doing manually at least. Edit: said is valid at least for alpha. I do realize colors can get very non-linear and basically unmanageable by average user, but that shouldn't be the case for alpha.

Brecht Van Lommel commented

2017-11-12 22:03:45 +01:00

There is no post processing on the Combined RGBA colors, it assumes premultiplied RGBA as input and passes those values straight on. In the render you are mixing with a Transparent BSDF, which changes the RGBA values going into the compositor, multiplying the RGB value from emission by 0.25.

Maybe you are expecting the Combine RGBA node to multiply the RGB values by A = 0.25 automatically? The problem with doing that is that chaining Separate and Combine RGBA will then alter the RGBA values.

There is no post processing on the Combined RGBA colors, it assumes premultiplied RGBA as input and passes those values straight on. In the render you are mixing with a Transparent BSDF, which changes the RGBA values going into the compositor, multiplying the RGB value from emission by 0.25. Maybe you are expecting the Combine RGBA node to multiply the RGB values by A = 0.25 automatically? The problem with doing that is that chaining Separate and Combine RGBA will then alter the RGBA values.

Konstantins Visnevskis commented

2017-11-12 22:11:38 +01:00

BSDF transparency is another can of worms I wouldn't touch. I was referring to input value of rgba(1, 0.5, 0.25, 0.25) fed directly into compositing Combine RGBA, resulting in grey (transparent white) output (at least in the output file), which I though from your comment is due to clipping of premultiplication. Which it seems shouldn't happen.

Brecht Van Lommel commented

2017-11-12 22:15:45 +01:00

It's not the premultiplication that clips it, but the color management view transform, which works on the unpremultiplied (1/0.25, 0.5/0.25, 0.25/0.25) = (4, 2, 1) values.

Konstantins Visnevskis commented

2017-11-13 11:05:41 +01:00

Thanks for patient replies!

If anyone ends up here trying to render transparency+emission glowy-thingy layer with alpha, the way it looks without alpha (on black),
here's the node setup that may help outputting something closer:
color2.blend
Works for transparency+emission shaders only. The idea is to use pixel's hsv(value) as alpha as it closer matches material's emissivity (needs to go through gamma of about 0.5 for external software). Setting hsv(value) to >1 to lose transparency color attenuation and multiplying resulting r,g,b with alpha to counter view transform premultiplication. A bit of cheating with curves, can be disabled. Matches default input of GIMP, AE.
Won't look like transparency in viewport exactly as the checker bg is brighter, but it's close.

Thanks for patient replies! If anyone ends up here trying to render transparency+emission glowy-thingy layer with alpha, the way it looks without alpha (on black), here's the node setup that may help outputting something closer: [color2.blend](https://archive.blender.org/developer/F1131084/color2.blend) Works for transparency+emission shaders only. The idea is to use pixel's hsv(value) as alpha as it closer matches material's emissivity (needs to go through gamma of about 0.5 for external software). Setting hsv(value) to >1 to lose transparency color attenuation and multiplying resulting r,g,b with alpha to counter view transform premultiplication. A bit of cheating with curves, can be disabled. Matches default input of GIMP, AE. Won't look like transparency in viewport exactly as the checker bg is brighter, but it's close.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Alpha channel color output #53265