Alpha difference Viewport/F12 #52680
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
23 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#52680
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
alpha_bug.blend
#79382 was marked as duplicate of this issue
#78820 was marked as duplicate of this issue
#78548 was marked as duplicate of this issue
#78314 was marked as duplicate of this issue
#78132 was marked as duplicate of this issue
#77108 was marked as duplicate of this issue
#67223 was marked as duplicate of this issue
#69930 was marked as duplicate of this issue
#73152 was marked as duplicate of this issue
#72178 was marked as duplicate of this issue
#70403 was marked as duplicate of this issue
#67877 was marked as duplicate of this issue
#65006 was marked as duplicate of this issue
#56343 was marked as duplicate of this issue
#56065 was marked as duplicate of this issue
#53306 was marked as duplicate of this issue
#53183 was marked as duplicate of this issue
Changed status to: 'Open'
Added subscriber: @SimonLiechti
Added subscriber: @An_Zi
This comment was removed by @An_Zi
Added subscribers: @brecht, @Sergey
The issue here is caused by different approach in Cycles and Blender about color management. Cycles is operating with premultiplied buffer, and color management looks like
DisplayPixel.rgba = color(linear_rgb_to_srgb(LinearPixel.rgb), LinearPixel.a). Note that Cycles does not do unpremultiplication prior to color management, however rest of Blender will first unpremultiply color, perform color space conversion and then will premultiply buffer back.@brecht, why such divergence appeared in the first place and where is the truth here?
The inconsistency comes from passing
falsefor predivide inengine_bind_display_space_shader, whereas the image editor works as if it's set totrue.It's impossible to do color management correctly on an image with alpha, so both are wrong. Here's a .blend with a Cycles checkerboard background to show what the correct result is:
alpha_bug_checkerboard_background.blend
Ideally color management should only happen after the image has been composited over a background. If both the image editor and 3D view would use GLSL shaders for drawing float buffers, this could be solved by drawing the render and checkerboard background in a single GLSL shader so that we can blend them and then do color management as the last step.
Enabling predivide for the 3D viewport would be the quick way to make it consistent. The downside would be that shaders that are fully transparent and have emission (like fire) would draw very poorly.
@brecht, the issue with GLSL side of colormanagement is that it doesn't come for free: it implies 4x of data to be transferred to the GPU on every redraw, which will eventually saturate your PCIex bus, causing lags in navigating in the image. Keeping texture on GPU all the time would solve the performance issue, but it's not something which will come any time soon.
While there is no correct solution here, we should stick to one of the solutions only. At least ideally. Keep in mind, same linear->display space conversion is needed when saving F12 render as png image.
Issue with emissive-only volumes is annoying, but it's also happening in F12 renders. So how much important is that?
Should we consider switching display buffer from straight to premultiplied alpha? (current issues outlined here will be somewhat easier to solve, but what downsides it'll bring?)
I'm fine with making Cycles viewport render consistent with the image editor, even if it looks worse for fire, and then do further improvements later.
Making the display buffer premultiplied alpha seems safe to me, there should be no precision loss. Only downside I guess is that saving a .png will give a different result, but on the other hand it will better show what you get when saving as .exr or using the render in compositing.
With half floats the transfer to the GPU would be only 2x, but that's also not trivial to implement.
Added subscriber: @troy_s
Regarding luminescent pixels, I had that fixed at one point. The predivide was the problem here, and I couldn't track down where the case of alpha == 0 was discarding RGB data. It could be solved by skipping the RGB values on the multiply in the case of alpha == 0 or setting the alpha to some extremely small value. Either scenario would preserve RGB for no occlusion / high emission cases. The OpenGL ONE_MINUS set properly blended all values, luminescent and non, when tested.
The scenarios where alpha is low and RGB is greater (low occlusion / higher emission) should hold up fine, and render as emissive.
I believe this is false if you mean that an alpha encoded image can't be properly colour managed, as can be proven via colour science calculations via the divide / multiply not zero. Guessing you weren't inferring that. I suspect you mean applying any colour manipulation before issuing a predivide is an error of process, which is absolutely correct. Appropriate process for any and all colour manipulation is always disassociate, colour manipulation, then reassociate.
Added subscribers: @marks-4, @zeauro
Added subscriber: @Twixuss
Added subscriber: @KonstantinsVisnevskis
Added subscriber: @chomik711
Added subscribers: @DTStheTDS, @Jeroen-Bakker, @mont29
Added subscriber: @stevewarner
Added subscribers: @Artur-12, @WilliamReynish
Added subscribers: @HoffmanWood, @lichtwerk
Added subscriber: @IvayloGogov
Added subscriber: @MaTcHo0o
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
Added subscriber: @mano-wii
The problem is seen when rendering with Eevee or Cycles.
PNGs are complete garbage. Don’t use them.
Added subscriber: @FilipMond
Added subscribers: @NinKorr, @fclem
Added subscriber: @Stefan_Werner
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?
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.
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.
Again, see above. By design, PNGs are broken for light transport, compositing, and effects.
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
Added subscribers: @surajrv6, @MarcinTwarowski
Added subscriber: @ponomarovmax
Added subscriber: @Olliver
This comment was removed by @Olliver
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
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:
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...
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.
20200520_Viewport_vs_Rending_issue_Blender2_80 and above.blend
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.
Report_BlenderTransparency_02.blend
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.
{F8545903}{F8545905}{F8545904}{F8545906}{F8545907}
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:
*** 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.False. This is not how alpha works and is a fundamental misunderstanding as to how it works.
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.
False. See above. The only correct file encoding Blender saves to is EXR.
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!
What part of that is not the correct result are you not comprehending here?
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.
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.
Without the proper interpretation of alpha, things like glares, flares, reflections, fire, etc. cannot be rendered correctly. PNG cannot render any of those correctly.
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:
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.
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.
Added subscriber: @dfelinto
Hello @fclem,
cc: @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.
!!! 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:
Looking forward for your feedback.
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
Please, use my previously attached file to show what do you mean?
Added subscriber: @Lluc3D
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:
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
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.
Added subscriber: @Pipeliner
Added subscriber: @Unchained-Production
So basically, as you've closed #78314, 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?
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!
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-
Flame_No_Alpha.mp4
I'm off to re-report this issue and see if it gets bumped into this 'it's only the image viewer' thread again.
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.
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.
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
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?
@marks-4
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.
Added subscribers: @Hongyu, @Diogo_Valadares
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
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, #67110 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.
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.
It's merged here because the issue you cited is in fact the issue here, as the endless threads have also disclosed.
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, [ https://community.adobe.com/t5/photoshop/change-in-exr-open-from-cs2-to-cs3-can-this-be-fixed/m-p/1521072?page=25#M948 | 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 [ https:*graphics.pixar.com/library/Compositing/paper.pdf | 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:
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
True optical cameras dont have alpha
This Topic again, and again.
I was reporting the same issue as @HoffmanWood, 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 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.
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.
Removed subscriber: @mont29
To be clear, one more time, for those in the back:
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.
Added subscriber: @Emblme
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:
Bug.blend
It MIGHT be a Combine HSV bug, but we probably need more experimentation to tell.
Added subscribers: @ParrotDenis, @EAW
Added subscriber: @Rui-huang
Changed status from 'Confirmed' to: 'Resolved'
This issue has been resolved by D8234. Please report any new issues as new reports.
Hello Jeroen @Jeroen-Bakker, could you tell me please, in which Blender version release I can find this fix.
I've been following this bug from long long time.
Best Regards,
Ivaylo
Ivaylo, the fix was pushed about 12 hours ago in the
d6525e8d13commit. If you build Blender yourself, it is in the master branch. If you use Windows, it is in the current build of 2.91 alpha at the link below. If you use Linux or Apple, you will have to wait for the next daily build to be made later today.https://builder.blender.org/download/
Thank you @EAW Even and Team,
Respect!