Page MenuHome

Alpha difference Viewport/F12
Confirmed, NormalPublicKNOWN ISSUE

Description

System Information
Windows 10, GTX1080

Blender Version
2.79.1 Hash:6859695

Bug description
Alpha channel seems to be different in the viewport compared to F12 render.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Hello guys,
I saw many items are combined with this Bug. Can you tell me please what is the current level of resolve of it, because I had some pending items also on my desk which are related to this issue? Basically, I'm trying to promote blender in my organization as one of the main tools for development, but now I've not been able to show the complete power and the main reason is this bug because I can not find any other way to save PNG's.

Thank you in advance.
With Respect Ivaylo

PNGs are complete garbage. Don’t use them.

Bastien Montagne (mont29) changed the subtype of this task from "Report" to "Known Issue".Jan 20 2020, 11:54 AM

PNGs are complete garbage. Don’t use them.

Hello Troy,

Yes, maybe you right, however currently, an automotive business is using this format as a pretty much standard format. Do you have any other idea, how to showcase the transparency in real-time render engine?

Currently, I'm not able to promote Blender within the company, even as a presentation real-time tool, because of the same issue in 2.80 and above.
I need to showcase the complete thing with the program, but when I'm required to render a png picture with transparency, for our real-time render engine, it will not be accurate. And from the perspective of engineer work, this will not be accepted. It should be really accurate actually.

This means all my effort will not be applied using Blender at the moment, compared to other colleagues with Maya, Max or Cinema. Could you support on that, please?

! In T52680#858382, @Ivaylo Gogov (ivaydesign) wrote:
Do you have any other idea, how to showcase the transparency in real-time render engine?

Yes. Education.

Also, isolate the idea of presentation from working.

In terms of presentation encodings, PNG is acceptable. If you are building a module configuration tool, it’s another matter altogether and the inherent shortcomings of PNG become much more problematic.

In terms of work, it is vital to appreciate that PNGs can not encode light transport concepts.

Your particular context is unrelated to this issue I believe.

I need to showcase the complete thing with the program, but when I'm required to render a png picture with transparency, for our real-time render engine, it will not be accurate.

If you are using PNG, you have already missed on the most important aspect above. Further, real time rendering doesn’t work well with the alpha format encoded in PNG on a number of levels, unless you are doing hacks such as side loading data in an image format.

And from the perspective of engineer work, this will not be accepted. It should be really accurate actually.

Again, see above. By design, PNGs are broken for light transport, compositing, and effects.

This means all my effort will not be applied using Blender at the moment, compared to other colleagues with Maya, Max or Cinema. Could you support on that, please?

You have to appreciate that the reason things are broken currently inside Blender is in no small part related to the brokenness of certain pixel encodings that are not and and cannot express light transport ideas.

Clear?

I don’t have any influence on “supporting” anything. Just saying that there is more to the problem than what you think is pressing for you. The implications of alpha encoding throughput the software has wide reaching problems.

If you reach out privately to me, I am happy to try and give you a bit of support within your particular context, and have a bit of experience in a very similar contexts.

Hello Troy, thank you for the answer, I understand the problem is more fundamental.
Please, tell me how to contact you via a private line, to communicate the current issues I have on that level.

Best Regards,
Ivaylo

Hello guys,

I would like to re-check again about this bug. Any plan for this fix? Previously, I was talking with Troy Sobotka for the same, he suggested workaround with exr's, however this is not working for us. The EXR's are not correct as the .png export in terms of --alpha density-- Please, confirm if you have any plan to fix this issue.

Best Regards,
Ivaylo

The EXR's are not correct as the .png export in terms of --alpha density--

You should provide an example between two pixels. Given the internal renderer generates the precise same alpha format that is encoded in an EXR, it would seem odd that the encoding was incorrect.

Break down what you are seeing into two pixels as a comparison.

Hello Troy,
Please check and consider the following with the team:

  1. For 2.80 and above when is rendering for example "a single element with alpha applied", it is not displaying properly on the screen when it is rendered from the program. If I need to generate such simple Gradient and to export it from Blender with alpha - this will not be accurate to what you see on screen, compare before, during, and after rendering. It does not matter the format of the export, the alpha and colors are not calculated as same as in the viewport vs render output, and this makes lots of confusion when it is up to the development of a project! So far I've experienced this in 2.80 / 2.81/ 2.82/ 2.83/ now 2.9 same so far...
  1. Serious Limitation for me and my team (as a representative of the automotive industry) so far - I have always to render on a black background if the shader is containing any transparency node. And then to combine them in program like Photoshop, Gimp, etc... I was fighting for years to establish such a pipeline including Blender. I hire people working with Blender, and it is been one of our main tools for production activities in our daily. With this obvious limitation, we have been struggling a lot these days, related to image and complex component creation . ..

Please, suggest something or at least tell me for any of your planning of this fix.


Please try taking the output to the compositor and use an alpha over node against black.

I believe this is the decade old Image Viewer bug you are seeing.

Hello Troy, thank you for suggesting this approach. I've already tried but the result is the same. Please check the image bellow. Not only the alpha but also color looks different. Attaching .blend file for the same.

In your first image previously, the “darker” blue on the Image Viewer is wrong; the alpha and emissions are incorrectly rendered. That is, it should be the image on the left, because the emission is occluding partially and emitting light above and beyond the occlusion in the alpha.

This is because of the colorramp node and the way you are manipulating the occlusion independently of the emission, despite the fact that the values are associated together.

I’m not sure what you are expecting here.

Troy those 2 blend files are different.
I just rendered again the one bellow to show more clearly what is the difference look like. I used the alpha over in the compositor, but the result is the same. Could you please give more clearance about your latest statement /ramp value thing/. Actually, I did not understand what you said in your last comment.
However, it is obvious from the picture example and .blend, that view port alpha rendered image is different from the one on the right side /rendered one/. The question to me is how to see them correctly and, why this is not a bug?

Best Regards,
Ivaylo

I’ll try to help you, but first you need to explain what, of the earlier light and dark images in this image is “correct”.

https://dev-files.blender.org/file/data/hn7xm452km7ve2dhuvdx/PHID-FILE-ho7pqvnpmuzqgsf3qxvq/image.png{F8545710}

Ran some tests. The viewport is very close to the proper result, and again, the Image Viewer is broken and has been forever. It's a bug, but not a high priority bug apparently, given it has been around since Blender's inception.

Here are the proper results, as from a properly saved EXR, including one darker grey that is close to the viewport output.

Photoshop will mangle the EXR correct handling I believe. Fusion and Nuke will handle the EXR properly.

Hello Troy, Thank you for the output.
I did try to open this file but it looks like there is a problem with it. Both computers Desktop and Laptop are not able to open it with Adobe CC 2019/2020.

Troy, based on my observation and tests so far, I think the problem is not in the Image Viewer at all. I'm saying that based on the following facts:

  1. If I open such an image generated out of a blender, the Image Viewer is showing the image absolutely properly, as was generated.
  2. If I try to re-save such image/gradient with transparency from Image Viewer as an output, the result is absolutely matching what the original data file which I open in the Image Viewer
  3. If I try to re-compose that imported image in a blender like this one, the Image Viewer is showing and exporting the data absolutely accurate as an output file, does not matter which file type I use.
  • 4) My observations so far are that rendering calculation in **Eevee** and **Cycles **are using similar representations of calculation for the rendering, but both results are changing for some reason when they need to be displayed/ moved to the **Image Viewer** inside Blender! Then what we see in the Image Viewer, the same image output is exported and this is what we see on screen out of Blender.

If I open such an image generated out of a blender, the Image Viewer is showing the image absolutely properly, as was generated.

False. This is not how alpha works and is a fundamental misunderstanding as to how it works.

If I try to re-save such image/gradient with transparency from Image Viewer as an output, the result is absolutely matching what the original data file which I open in the Image Viewer

False. This is ultimately dependent upon file encoding. Blender mishandles all 8 bit content here which can properly render it. That too is a bug. PNG can not express alpha correctly, according to the Porter Duff.

If I try to re-compose that imported image in a blender like this one, the Image Viewer is showing and exporting the data absolutely accurate as an output file, does not matter which file type I use.

False. See above. The only correct file encoding Blender saves to is EXR.

My observations so far are that rendering calculation in Eevee and Cycles are using similar representations of calculation for the rendering, but both results are changing for some reason when they need to be displayed/ moved to the Image Viewer inside Blender! Then what we see in the Image Viewer, the same image output is exported and this is what we see on screen out of Blender.

False.

Again, your understanding of alpha is fundamentally wrong, leading to incorrect inferences.

The Image Viewer is broken. Has been broken forever. It is not displaying the correct result as the viewport is. This can be trivially proven by trying the EXR which is a direct rendered output in capable software. Photoshop is not capable software.

EXR is the only correct file encoding within Blender for a long history of reasons.

Hello Troy, I'm not here to spend time to arguing with you, but to report the facts! IF you really want to help please do so, otherwise I don't know what to say...

I think you have to skip the idea of .EXR for a while! Your position is completely far for what I'm trying to explain.
I'm not arguing with you about the quality of extensions when we export. I'm saying when you see a Problem, the normal is to provide a solution for that problem, or at least to indicate what exactly the problem is.

From what you had explained to me so far, I didn't understand the workaround of this problem. And actually you were always pointing something different by telling me where I false in my understanding.
By your proposal I used Alpha Over - was not working. .EXR export - not work. Again, no sense of arguing... with you! However, I found a way to visually measure the difference between those 2 calculation, and to resolve this problem temporary.

1/ Simple as that - when you Render any picture in Blender without tick mark on transparency -ON (but you render without transparency).

  • NO ISSUE of the APPEARANCE! The image you see on both 3D view-port and Image View-port as render result are completely the same! The decision what type format you will export this image, doesn't matter!!! You can export what ever you need and it will be correct compare to what you see on the screen!

2/ The ISSUE is appearing Only and When you check-mark the Transparency ON! (render with transparency gradient in the shader).

  • Which means, again there is an ISSUE of Drawing the Calculated Alpha for the Final Render in Image Viewport, which need to be fixed!

I spend my day to try fix this issue through the Compositor by adjusting the Alpha with those missing values of the Drawing of the result in the Image View-port.

So far is working fine but I would like to have your support with this fix to ensure that we can use blender in our work in future!

NO ISSUE of the APPEARANCE! The image you see on both 3D view-port and Image View-port as render result are completely the same! The decision what type format you will export this image, doesn't matter!!! You can export what ever you need and it will be correct compare to what you see on the screen!

What part of that is not the correct result are you not comprehending here?

  1. PNG cannot encode alpha correctly. Using it as a demo is wrong, because again, PNG cannot encode alpha correctly. In fact, all file format encoding at 8 bit in Blender is wrong.
  2. The Image Viewer is also broken and does not display alpha correctly.

It’s really that simple.

The Viewport appears correct.
The Image Viewer is wrong and broken.
PNG is wrong, and doesn’t encode alpha correctly.

By your proposal I used Alpha Over - was not working.

That’s odd because using alpha over is the only proper way to get to the proper result.

Check the actual code values in the buffer and do the math by hand to confirm.

So far is working fine but I would like to have your support with this fix to ensure that we can use blender in your work in future!

Without the proper interpretation of alpha, things like glares, flares, reflections, fire, etc. cannot be rendered correctly. PNG cannot render any of those correctly.

Again, no sense of arguing... with you!

There is no sense in arguing for an incorrect understanding of what alpha is, what it represents, or how it works. Your fundamental understanding is wrong.

This is temporary solution based on this case and it is workign fine, but not working for variety of cases. The solution with the same approach need to be integrated in Blender as adaptive based on the difference between View-port vs Image Viewer.

The main question is, could you fix the current issue?

You keep saying "fix" but you are pointing at the wrong thing.

What do you expect from an RGBA triplet that is [666.0, 666.0, 666.0, 0.0]?

The things that need fixing with specific attention to this now hijacked thread is:

  1. The 8 bit file encodes need to be properly encoded with respect to how actual alpha works. That is, permit TIFF to properly support associated alpha, as per it's specification, by default.
  2. Fix the Image Viewer to properly display alpha encoded imagery.

Troy, I think we are talking now for the same points, and my understanding is the same. I agree with you, and the question is: Who can fix the following you have mentioned: Because the issue is been forever.

  1. The 8 bit file encodes need to be properly encoded with respect to how actual alpha works. That is, permit TIFF to properly support associated alpha, as per it's specification, by default.
  2. Fix the Image Viewer to properly display alpha encoded imagery.

I will really appreciate if you could help us with that. Many people are struggling because of this issue, for long long time! Could you support us with that?

I wrote a patch twice. Once back in 2007, then again in 2011.

https://developer.blender.org/T28782

I believe Clement was working on fixing the Image Viewer once and for all, so that it displays the alpha correctly. The file encoding has much larger issues due to some unfortunate historical design decisions.

Hello @Clément Foucault (fclem),
cc: @Dalai Felinto (dfelinto)

Those problems are been blocking me and my team (Automotive Industry) for long time. I hired about 10 people so far, more of them are working with + Blender as myself, however now the complete team is depending of this about its production. We are using blender daily in help to our production - modeling, texture and assets production for our real-time rendering engines.

-> As as simple example I need to be able to produce such simple gradient with transparency and to export it from Blender, after the creation.
I need to get accurate image from Blender. Accurate, from the technical perspective side - approximate number of pixels shown in the screen, accurate representation of gradients levels to mach with the 3D View Port Screen.

! Currently WHEN ALPHA TRANSPARENCY is ON, with Transparent Node dependency in the Shader ! There is big visible misalignment between what is showing in the View port Screen compare to what is rendered on the Image Viewer.
Please, check my comments above in the chat.

Could you please share some information to us, about this possible fix? We just discussed with Troy, and we came to the same conclusion both, of the following 2 points:

  1. Need to be fixed --- The 8 bit file encodes need to be properly encoded with respect to how actual alpha works. That is, permit TIFF to properly support associated alpha, as per it's specification, by default.
  2. Need to be fixed --- Image Viewer to properly display alpha encoded imagery.

Looking forward for your feedback.

As as simple example I need to be able to produce such simple gradient with transparency and to export it from Blender, after the creation.

You need to generate the gradient properly. Your demo above is not how to apply alpha, as I hope I have demonstrated.

You must scale the emission by the degree of occlusion, and then set the alpha. You cannot simply set the alpha, as the alpha will then be disconnected from the degree of occlusion, which is the crux of your issue. The Image Viewer being broken is somewhat secondary here. The proper output is as per the Viewport.

Hello Troy,
Could you show an example, and also what do you mean by

"must scale the emission by the degree of occlusion, and then set the alpha".."

Please, use my previously attached file to show what do you mean?

You haven't scaled your emission by the gradated shape, so some of the pixels are emitting more than they are occluding.

Currently, the RGB emission is emitting a higher ratio than the degree of occlusion (alpha) you are setting. What you are seeing in the alpha over is correct, as is the viewport. The Image Viewer is a broken result. To achieve what I think you are wanting:

  1. Scale the emission RGB values by the degree of occlusion in the gradient. That is, multiply the emission by the circular gradient. Or:
  2. Try cheating by incorrectly pretending the alpha is not proper associated alpha, and toggling the "Convert Premul" to on.

The proper approach is to understand what alpha is and do it properly via 1. Short term, 2. probably will yield the same result.

Hello sorry Troy, I did my best to communicate, understand and resolve the issue. Currently no success. This is not in my technical level. Of course I can workaround by cheating it.
I think this should be fixed properly to shown the result in the Image Viewer.

Again if you could help please adjust one of the provided files to what you are describing because I cannot understand what do you mean by

Scale the emission RGB values by the degree of occlusion in the gradient

I tried with and without gradients... same results.
Please, try to provide your solution via one of the provided files.

I still am unsure what result you are hoping for?

I am not wasting time hunting bugs in Blender’s Image Viewer again. It’s broken.

If the goal is to see what you see in the Viewport, I cannot do that. The only way to simulate it is to use the alpha over node and verify the results in the composited output using an arbitrary solid colour.

The checkerboard Image Viewer “transparent” view is fundamentally broken, and can never be mangled to work correctly in its current broken state.

So basically, as you've closed T78314, that would appear to mean Blender is completely incapable of rendering fire without smoke properly at all with transparency in both EEVEE and Cycles (and flakey at rendering fire & smoke with transparency), and so is unusable for compositing as it stands: is that what is being said here?
That doesn't strike me as terribly useful for production...

So what, if any, work-around is available to be able to render flames-only with transparency?
Also; and or when might this issue be addressed.

So basically, as you've closed T78314, that would appear to mean Blender is completely incapable of rendering fire without smoke properly at all with transparency in both EEVEE and Cycles (and flakey at rendering fire & smoke with transparency), and so is unusable for compositing as it stands: is that what is being said here?
That doesn't strike me as terribly useful for production...

So what, if any, work-around is available to be able to render flames-only with transparency?
Also; and or when might this issue be addressed.

shouldn't you have tons of workaround? Render with a green background and key that out, etc?

Obviously, I know you can pretend Blender is not a piece of 3D software and treat it as a camera shooting green screen footage, which also obviously is somewhat of a massive pain-in-the-arse.
What I meant is: are there any work-arounds that make the software behave like it ought to, and be capable of rendering with a proper alpha channel?

What I meant is: are there any work-arounds that make the software behave like it ought to, and be capable of rendering with a proper alpha channel?

It renders to a proper alpha channel, encoded correctly. The Image Viewer is broken when using the transparent background checkerboard.

It renders to a proper alpha channel, encoded correctly. The Image Viewer is broken when using the transparent background checkerboard.

Bollocks! Totally retract the previous 3 comments! I've now skimmed this thread so shall be saving and ignoring the render preview completely. When you suggested the green-screen/keying work-around I assumed it was a real showstopper of a bug, rather than just a case of 'ignore the preview image'... Humble Apologies!

Mark Spink (marks) added a comment.EditedFri, Jul 3, 4:43 PM

It renders to a proper alpha channel, encoded correctly. The Image Viewer is broken when using the transparent background checkerboard.

Actually I'm retracting my previous apologies, and sticking to my guns: if you render fire/flames volumetrics without any smoke Blender does not render a proper alpha channel, and this is quite a show-stopper of a bug for me.
I'm finding it manages to encode the RGB correctly (if you save to EXR anyway), but I'm getting nothing / pure black in the alpha channel, where there should be something non-zero under the fire/flames.
Like this-

I'm off to re-report this issue and see if it gets bumped into this 'it's only the image viewer' thread again.

I'm finding it manages to encode the RGB correctly (if you save to EXR anyway), but I'm getting nothing / pure black in the alpha channel, where there should be something non-zero under the fire/flames.

False. This is not what a proper alpha encoded image represents.

Alpha is degree of occlusion. Zero alpha means zero occlusion. RGB are the three channels’ respective units of emission. Therefore, zero alpha is entirely correct. Flares, reflections, fires and candle flames, etc. all contribute emission without occluding.

I get what you're saying, and though it may well be technically correct...
If I create an image with an element that is completely non-transparent in places as shown in Blender's GUI, as in no 'checkerboard' can be seen through it, and if there were geometry or background behind it then they would also not be seen through it, then the alpha channel should respect this.
I mean this is for creating imagery, and I'm fairly sure most of the planet treats the alpha as describing transparency for compositing - regardless of if it's technically correct or not.
So do I now have to save an emission pass and bolt that onto the alpha or something- how elegant, you must be kidding- this should be a check-box! Do you want 'technically correct' alpha channel or the one that works properly y/n...

Proper handling is proper handling, and it cascades upwards.

The issue is that the viewer is not handling the alpha encoding correctly, so it is correctly occluding the proper amount (zero) but not putting the additional emission on (no zero RGB).

I don’t know what to say. If you try to make a case for mishandling alpha, you explode all proper pipelines that add flares and reflections etc. It simply isn’t what proper alpha means or is.

If I create an image with an element that is completely non-transparent in places as shown in Blender's GUI, as in no 'checkerboard' can be seen through it, and if there were geometry or background behind it then they would also not be seen through it

It’s feasible that something can be unoccluding and obscure the checkerboard with a significant enough emission. Again, the Image Viewer has long been broken, however.

I mean this is for creating imagery, and I'm fairly sure most of the planet treats the alpha as describing transparency for compositing - regardless of if it's technically correct or not.

Compositors creating imagery understand that alpha represents degree of occlusion. RGB is emission.

If someone spends 15000 USD on a Nuke license, does one expect proper alpha handling or broken? Nuke takes their alpha handling rather seriously.

In the end, broken alpha handling breaks the entire pipeline.

Just so you guys are aware, there are other issues that have been flagged as duplicates to this, which are actual software bugs.

So if this just gets ignored, so do those cases.

One of those dupes is a thread describing an issue with Eevee bloom not writing alpha, which is not an issue with the image editor/viewer

Just so you guys are aware, there are other issues that have been flagged as duplicates to this, which are actual software bugs.

Most of the duplicating flagging is being done by Brecht and Clement, and those two folks are typically pretty on point, despite having exceptionally little time.

Can you cite which duplicate is incorrect?

@Mark Spink (marks)

"I mean this is for creating imagery, and I'm fairly sure most of the planet treats the alpha as describing transparency for compositing"

Yes, which means that things like fire, require their separate layer, so they can be composited bypassing the rgba-mix blending mode mode, as they can be (and usually at least partially are) emissive without occlusion.

For convenience of previews and non-pbr stuff I too would like a checkbox that'd "simulate" emission into alpha (probably would require more options to be at least half-universal and the viewport should be affeceted), but it isn't a bug.
What also would aid the problem is to have an emission_subtracted pass to output into a multi-layer file, without resorting to compositor, and save a few passes in compositor too. Not a bug either.

Hey thanks Troy

I couldnt quite find the tread again, its possible it has been corrected already maybe.

Non the less the Eevee bloom not writing alpha issue is quite nasty, and Im hoping the devs will fix it soon. I need it for my game HUD creation pipeline

Non the less the Eevee bloom not writing alpha issue is quite nasty, and Im hoping the devs will fix it soon.

If it is a true optical bloom, there should be zero percent occlusion in the alpha channel. Or are you suggesting it is failing to write the alpha channel at all? Wish you had the proper report to avoid piling garbage into this one.

as far as 2.83.0, T67110 doesn't seem been fixed. I know there is 2.83.1, which I haven't checked yet. But I hope you guys realize about this.

as far as 2.83.0, T67110 doesn't seem been fixed

It isn't fixed because you are in the bug report for the repair. It's specifically about this report.

as far as 2.83.0, T67110 doesn't seem been fixed

It isn't fixed because you are in the bug report for the repair. It's specifically about this report.

Sorry, I am not sure what you mean exactly. Do you mean this whole thread is still being taken care of? because that issue is essentially merged here, so I suppose they point to the same principle error.
From your previous conversation with Mark, although I don't actually understand what happen, it gives me a feeling that this issue are almost "expected" and thus not being taking care of?
I feel sorry if I misunderstood.

The only thing I concern with is that if I output a cube with bloom and make it background transparent, the output image would have no bloom and it's not only limited to image editor in blender or so. Putting the output image to AE/PS will give the same result.
I personally don't think this is expected and is something that has to be fixed.

because that issue is essentially merged here, so I suppose they point to the same principle error.

It's merged here because the issue you cited is in fact the issue here, as the endless threads have also disclosed.

Putting the output image to AE/PS will give the same result.

Given AE and PS are Adobe products, alpha handling has been a longstanding mess. There's an infamous thread on the Adobe forums, that includes some extremely highly esteemed image editors slapping the lead developer around a bit on the subject. In particular, this specific passage from Zap Andersson, one of the head rendering developers at Autodesk now, and this passage, nicely summarize how and why the software mangles up alpha.

It doesn't help that everyone treats alpha as this remarkably simple idea that they believe they fully understand, without connecting the dots to the nature of the encodings and how light transport works. Note that the above discussion is entirely congruent with Alvy Ray Smith's position, and reinforced by Tom Porter and Tom Duff.

So again, for the poor people who keep having this thread pop up in their mailbox, the TL;DR is:

  1. Cycles and Eevee are absolutely correctly computing the alpha and emission, and encoding it properly into the RGBA triplet.
  2. The Image Viewer, and all default "render" views, is and has been broken forever, and will not show the result correctly.

The Image Viewer, and all default "render" views, is and has been broken forever, and will not show the result correctly.

This does not apply to bloom not writing alpha and Hoffman just linked the issue that I failed to find yesterday (Might be more issues that have been set to dupes to this thats also actual bugs)

You can go ahead and download the latest 2.9 alpha and test export a render with transparent background with bloom, its not going to write.

https://developer.blender.org/T67110

If it is a true optical bloom, there should be zero percent occlusion in the alpha channel. Or are you suggesting it is failing to write the alpha channel at all? Wish you had the proper report to avoid piling garbage into this one.

True optical cameras dont have alpha

This Topic again, and again.
I was reporting the same issue as @Hoffman Heard (Hoffman), many times. Lot's of discussions with Troy, same answers for months..

The problem is that: We all know Blender Developer are working on target, and the schedule between new releases is being really tight now.
---> However, all effort from the community as reports, and from developers can be simply waste of time and money, when at the end you cannot simply save an image with accurate alpha...

I think before going any further [new features, new explorations etc], this bug need to be fixed, simply because is downgrading the program qualities when we want to show any picture without background, with soft edge, or glowing, or specific alpha to customer. Simply at that moment this not possible with Blender. And this is a fundamental thing..

At that moment I have 10 people in my team using blender, and we not able to operate because of this bug for long time. I'm a bit disappointed, and I'm really looking for solution on that problem! Current pipeline wen with Maya because of that ...

Please, make sure you will targeted this ISSUE and topic and for 2.90 for example. This progress and bug fix will be huge for many people in the industry!

I think before going any further [new features, new explorations etc], this bug need to be fixed, simply because is downgrading the program qualities when we want to show any picture without background, with soft edge, or glowing, or specific alpha to customer. Simply at that moment this not possible with Blender. And this is a fundamental thing..

I think Troy stated that eevee and cycles are absolutely correct, and viewer is broken forever.
I think this is not being considered as a bug, instead of not caring this bug.
that's probably why there is no progress on this. you don't fix a thing that's not considered bug. Or I don't know.

Well, I don't know if this is officially should be classified as BUG or limitation, I can say that I spent enough time and effort to report again and again the same problem, ... without effect.
I think really soon many other people will start reporting the same, simply because if you want to use Blender as program in professional manner, Output of IMAGES from this program needs to be accurate as RGB color and Alpha.

At the moment the conclusion is simple:
---> Doesn't matter what kind of feature we have... we cannot produce accurate RGBA - image if there is a Smooth Alpha Edge as a Smoke/Fire or/Blur effect on transparency background. The output image will be always wrong (because of Image Viewer or what, I don't know), this is the fact!

---> Another thing: Any image Rendered in current Blender which is using Alpha - 0 or 1 - IS COMPLETELY accurate when saved as RGBA - output. So the current problem is when we have floating values between 0 and 1.

At the moment the conclusion is simple:
---> Doesn't matter what kind of feature we have... we cannot produce accurate RGBA

I think this is the core of this whole debate, and where Troy disagrees with.
I think his opinion is that "blender is producing absolutely accurate RGBA" from a technical point. Unless you persuade him that he is wrong, otherwise I don't see this problem will be solved any soon? Either way, I don't know.
I am neither a developer nor a technician, having no idea which side is correct.

I can only say that from the previous conversation, I see that this issue is and may not be taken care of.

Unless you persuade him that he is wrong, otherwise I don't see this problem will be solved any soon?

To be clear, one more time, for those in the back:

  1. Blender output from Cycles and Eevee alpha into the RGBA channels for fires, flares, glares, glows, glints, and reflections, 100% correctly in a majority of cases, actual bugs notwithstanding. If someone here believes it doesn’t, they need to stop making imagery, and go and read Porter / Duff, A R Smith, the Adobe thread, and learn how alpha works. This is not opinion, nor disagreement, and rather precisely how alpha is and always has been generated, which extends right down to the display level in terms of emissions from pixels. This is again, not opinion, and if someone here believes it to be so, go use Fusion, Nuke, Houdini, or any tools that use properly encoded RGBA correctly, read all literature, and read about light transport.
  2. Blender does not write the alpha encoded RGBA buffer correctly to all integer based file encodings, broken file encodings such as PNG notwithstanding.
  3. Blender does not display the alpha encoded RGBA buffer correctly in all things related to the Image Viewer.

It really is that simple.

It is wise to understand exactly how and where Blender is breaking, and in this particular instance it is point 2. and 3., and this report specifically pertains to 3.

If someone still wants to believe that somehow the singular proper encoding of RGBA in Cycles and Eevee is wrong in the face of actual literature, actual experts with Academy arts and science awards, actual people who designed file encodings such as EXR, and the actual researchers who invented and fleshed out the concept of alpha encoded RGBA, there’s not much hope for them.

It is going to be interesting, how many bug reports (and Troy's patience to explain the issue) is needed to get priority enough to find solution for this thing.

Che (Emblme) added a subscriber: Che (Emblme).EditedTue, Jul 7, 6:23 PM

While playing around with some drivers and animations, I found something interesting. It might be an unrelated bug, or it could be a potential lead, but it seems like the HSV selector from the RGB node has different behavior than a Combine HSV node with identical values, only visible with this bug. This same behavior carries over to the Transparency node, which uses an RGB node internally.

The left side is a color selected with a driven Combine RGB/HSV node. The right side color is a selection of the same value, selected with the RGB node.

RGB:

HSV:

It MIGHT be a Combine HSV bug, but we probably need more experimentation to tell.