Blender 2.91.0 Alpha - Blender cannot export proper image when containing smooth gradient of Alpha #81390

New Issue

Ivaylo Gogov · 2020-10-02T19:21:47+02:00

Ivaylo Gogov commented

2020-10-02 19:21:47 +02:00

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: GeForce GTX 1050 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 456.38

Blender Version
Broken: version: 2.91.0 Alpha, branch: master, commit date: 2020-09-25 20:54, hash: 83dc97ccc0
Worked: (newest version of Blender that worked as expected)

Short description of error
ISSUE is appearing when you try to save-as and export an RGBA image as .PNG etc, out of Blender result looks completely different by color, different brightness, etc. (3), not only in Photoshop but also in Windows Viewer.

Exact steps for others to reproduce the error

Open the attached blend file
Press render
Save-as RGBA ... .PNG file format, etc. save on your local device
Open the outputted image in any program or viewer and compare again vs blend file to see the difference
By the way .EXR format looks correct, but not the PNG. Once I render the.EXR needs to convert all the sequences to.PNGs once again

ISSUE-RENDERING.blend

**System Information** Operating system: Windows-10-10.0.18362-SP0 64 Bits Graphics card: GeForce GTX 1050 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 456.38 **Blender Version** Broken: version: 2.91.0 Alpha, branch: master, commit date: 2020-09-25 20:54, hash: `83dc97ccc0` Worked: (newest version of Blender that worked as expected) **Short description of error** ISSUE is appearing when you try to save-as and export an RGBA image as .PNG etc, out of Blender result looks completely different by color, different brightness, etc. (3), not only in Photoshop but also in Windows Viewer. **Exact steps for others to reproduce the error** 1. Open the attached blend file 2. Press render 3. Save-as RGBA ... .PNG file format, etc. save on your local device 4. Open the outputted image in any program or viewer and compare again vs blend file to see the difference 5. By the way .EXR format looks correct, but not the PNG. Once I render the.EXR needs to convert all the sequences to.PNGs once again [ISSUE-RENDERING.blend](https://archive.blender.org/developer/F8947767/ISSUE-RENDERING.blend) ![Blender_Rendering_issue.PNG](https://archive.blender.org/developer/F8947768/Blender_Rendering_issue.PNG)

Ivaylo Gogov commented

2020-10-02 19:21:47 +02:00

Added subscriber: @IvayloGogov

Yevgeny Makarov commented

2020-10-02 22:43:15 +02:00

Added subscriber: @jenkm

Yevgeny Makarov commented

2020-10-02 22:43:15 +02:00

I can see a big difference between 2.83.6 and 2.91.0.

The problem is how the file is displayed in Image Editor.

I can see a big difference between 2.83.6 and 2.91.0. The problem is how the file is displayed in Image Editor. ![#81390.jpg](https://archive.blender.org/developer/F8948270/T81390.jpg)

Ivaylo Gogov commented

2020-10-02 23:29:12 +02:00

@jenkm they fix The Image Editor issue in Blender 2.91 there is no issue, you can see my image above. Check here: https://developer.blender.org/T52680

So the BUG you are showing is fixed already. But..

The problem is coming now about the output of this. When you save as such image as RGBA -png, exr.. etc the result out of Blender looks really, really different.
I test via Window Image Preview, Photoshop, AE same.. result..

@jenkm **they fix The Image Editor issue in Blender 2.91 there is no issue, you can see my image above.** Check here: https://developer.blender.org/T52680 So the BUG you are showing is fixed already. But.. The problem is coming now about the output of this. When you save as such image as RGBA -png, exr.. etc the result out of Blender looks really, really different. I test via Window Image Preview, Photoshop, AE same.. result..

Ivaylo Gogov commented

2020-10-05 23:10:04 +02:00

Quick Update,
I tried the same with.EXR and TIFF - and working but not completely fine.
.PNG is not working at all. Now all sequences and render passes from EXR need to be converted to .PNG, and it is really time-consuming and annoying process.

Could you please check and advise for a solution to this bug?

I would like to properly render many sequences as PNG's from Blender.

Quick Update, I tried the same with.EXR and TIFF - and working but not completely fine. .PNG is not working at all. Now all sequences and render passes from EXR need to be converted to .PNG, and it is really time-consuming and annoying process. - Could you please check and advise for a solution to this bug? I would like to properly render many sequences as PNG's from Blender.

Yevgeny Makarov commented

2020-10-06 08:19:12 +02:00

I created a similar image in "photoshop" and passed it through the Compositor, and re-saved it in PNG, the result is identical to the original PNG. This is why I don't see a problem in import/export. Though, I don't insist on it, just a quick test.

Germano Cavalcante commented

2020-10-07 16:02:59 +02:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2020-10-07 16:02:59 +02:00

This is the same problem as described in #81101 (Saving image with Alpha (like bloom) not saving correctly)
In short, emission + transparency does not do well in some image formats.

This is the same problem as described in #81101 (Saving image with Alpha (like bloom) not saving correctly) In short, emission + transparency does not do well in some image formats.

Philipp Oeser commented

2020-10-07 16:51:22 +02:00

Added subscribers: @Jeroen-Bakker, @lichtwerk

Philipp Oeser commented

2020-10-07 16:51:22 +02:00

I think @Jeroen-Bakker already worked on this? #81199 (Some effects [bloom, smoke, fire, ..] still don't save in PNG with transparent background (occlusion vs. emission)) D9033: #81199: Store Emissive Colors when writing to sRGB 3 channel files

I think @Jeroen-Bakker already worked on this? #81199 (Some effects [bloom, smoke, fire, ..] still don't save in PNG with transparent background (occlusion vs. emission)) [D9033: #81199: Store Emissive Colors when writing to sRGB 3 channel files](https://archive.blender.org/developer/D9033)

Yevgeny Makarov commented

2020-10-07 17:01:47 +02:00

This not related to "emission + transparency", this also happens with normal 8bit png images,
it looks different in the Image Editor (2.91.0) than in photoshop or in the 2.83.6.

I created a similar image in "photoshop" and passed it through the Compositor, and re-saved it in PNG, the result is identical to the original PNG. This is why I don't see a problem in import/export.

This not related to "emission + transparency", this also happens with normal 8bit png images, it looks different in the Image Editor (2.91.0) than in photoshop or in the 2.83.6. > I created a similar image in "photoshop" and passed it through the Compositor, and re-saved it in PNG, the result is identical to the original PNG. This is why I don't see a problem in import/export.

Ivaylo Gogov commented

2020-10-08 22:48:40 +02:00

@Jeroen-Bakker You can use the file I attached, you can see there is no difference between viewport rendering and image editor, once is get rendered. The problem is coming when you want to Save as the output. Please check, simply following the steps above.

Jeroen Bakker commented

2020-10-09 11:04:35 +02:00

When comparing you should add the comparison with the whole 3d pipeline. The bug was that the alpha of rendered image in the image editor was off from the 3d viewport, The 3d viewport was correct.
The reason was that the image editor (2.90 and earlier) used to be doing the alpha blending in display space and not in scene reference space.
Alpha blending should be done in scene reference space (follow the color management settings and ocio configuration).
PNG images and other file formats do alpha blending in display space (srgb), the issue of alpha differences is now moved towards Image IO.

NOTE: that the same problem exists when importing a PNG file with transparencies and use it the transparency in a material or compositor. The image editor shows the effect that it has.

Keeping this in mind you see that a solution will always have limitations. For now if transparency is important use a file format that is flexible in color management for best results. I believe that the best option for usability is to decode and encode the alpha channel to get close to expected results. Not sure if OCIO can help in this case.

When comparing you should add the comparison with the whole 3d pipeline. The bug was that the alpha of rendered image in the image editor was off from the 3d viewport, The 3d viewport was correct. The reason was that the image editor (2.90 and earlier) used to be doing the alpha blending in display space and not in scene reference space. Alpha blending should be done in scene reference space (follow the color management settings and ocio configuration). PNG images and other file formats do alpha blending in display space (srgb), the issue of alpha differences is now moved towards Image IO. NOTE: that the same problem exists when importing a PNG file with transparencies and use it the transparency in a material or compositor. The image editor shows the effect that it has. Keeping this in mind you see that a solution will always have limitations. For now if transparency is important use a file format that is flexible in color management for best results. I believe that the best option for usability is to decode and encode the alpha channel to get close to expected results. Not sure if OCIO can help in this case.

Ivaylo Gogov commented

2020-10-10 00:50:04 +02:00

@Jeroen-Bakker I completely agree with your comments.
My observations after many hours of comparison and analyzes are the same.

I would like to recommend you for fixing the issue, counting the complete process and pipeline of render production.
Based on my latest observation RESULT compared between 3D view-port and Image Editor --- THERE IS NO DIFFERENCE. The difference is coming when I want to Save As the product out of it.

So here, my thoughts are dividing by 2 possible projections. You tell me, which one is correct, and it can be used.

1/ Projection of thought:

After the Setup the Scene in 3D-view-port and calculation of all DATA is stored temporary "somewhere", by definition of TYPE [buffer for poly/meshes; buffer for vertex color, textures, buffer fro shaders]
In this way as an output of rendered image we have result of that buffers combinations merged based on Zdistance, space-AO,GI, REFLECTIONS, EMISSIONS etc.
So the first logic calculating and merging the data -by- transferring it on ImageEditor Screen, and based on transfere here, alpha it cannot be calculated properly because is not stored properly, or it is not projected properly compare the life 3D-viewport-screen.

2/. Projection of thought

IF the data of the Alpha cannot be stored properly, there will be no way of projecting it properly. Which mean the focus should behow this data need to be a/stored b/transferred c/projected on final output image.
Probably the HIGH dynamic range images as you mentioned will look more accurate on look, but again it will not be exactly based on the present. Additional alpha adjustment will be always required.

Some questions:

how you store the alpha?
what approach you are using to transfer the color data and how you combine it with the alpha?
what should be added in addition to make possible Image Editor to Save As properly images with such Alpha.

Thank you, Respect for you work and huge effort!
Regards,
Ivaylo

@Jeroen-Bakker I completely agree with your comments. My observations after many hours of comparison and analyzes are the same. I would like to recommend you for fixing the issue, counting the complete process and pipeline of render production. Based on my latest observation RESULT compared between 3D view-port and Image Editor --- THERE IS NO DIFFERENCE. The difference is coming when I want to Save As the product out of it. So here, my thoughts are dividing by 2 possible projections. You tell me, which one is correct, and it can be used. 1/ Projection of thought: - After the Setup the Scene in 3D-view-port and calculation of all DATA is stored temporary "somewhere", by definition of TYPE [buffer for poly/meshes; buffer for vertex color, textures, buffer fro shaders] In this way as an output of rendered image we have result of that buffers combinations merged based on Zdistance, space-AO,GI, REFLECTIONS, EMISSIONS etc. So the first logic calculating and merging the data -by- transferring it on ImageEditor Screen, and based on transfere here, alpha it cannot be calculated properly because is not stored properly, or it is not projected properly compare the life 3D-viewport-screen. 2/. Projection of thought - IF the data of the Alpha cannot be stored properly, there will be no way of projecting it properly. Which mean the focus should be**how this data need to be a/stored b/transferred c/projected on final output image.** Probably the HIGH dynamic range images as you mentioned will look more accurate on look, but again it will not be exactly based on the present. Additional alpha adjustment will be always required. `Some questions:` - how you store the alpha? - what approach you are using to transfer the color data and how you combine it with the alpha? - what should be added in addition to make possible Image Editor to Save As properly images with such Alpha. Thank you, Respect for you work and huge effort! Regards, Ivaylo

gurlaldeep singh commented

2020-10-31 17:34:13 +01:00

Added subscriber: @gurlaldeep

gurlaldeep singh commented

2020-10-31 17:34:13 +01:00

I am having the same problem.
unfortunately, I can't share the blend file but I have attached a screenshot, and is there any workaround for this?
I am working on a really imported project.

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 456.38

Blender Version
Broken: version: 2.91.0 Beta, branch: master, commit date: 2020-10-26 17:29, hash: edf4378c44

Thank you,
Regards,
Gurlaldeep

I am having the same problem. unfortunately, I can't share the blend file but I have attached a screenshot, and is there any workaround for this? I am working on a really imported project. **System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 456.38 **Blender Version** Broken: version: 2.91.0 Beta, branch: master, commit date: 2020-10-26 17:29, hash: `edf4378c44` ![render.PNG](https://archive.blender.org/developer/F9141524/render.PNG) Thank you, Regards, Gurlaldeep

Jeroen Bakker commented

2020-11-25 07:49:51 +01:00

If alpha is important, please don't use PNG they aren't capable of handling pure emissive colors. Use other file formats that store in linear space with premultiplied alpha. OpenEXR is a good example.

Germano Cavalcante commented

2020-11-25 16:51:15 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Germano Cavalcante commented

2020-11-25 16:51:15 +01:00

I am setting as confirmed, since it was classified as a Known Issue.

I am setting as confirmed, since it was classified as a `Known Issue`.

gurlaldeep singh commented

2020-11-26 15:29:07 +01:00

In #81390#1060780, @Jeroen-Bakker wrote:
If alpha is important, please don't use PNG they aren't capable of handling pure emissive colors. Use other file formats that store in linear space with premultiplied alpha. OpenEXR is a good example.

I tried open EXR and keeps the alpha but not glow\bloom

> In #81390#1060780, @Jeroen-Bakker wrote: > If alpha is important, please don't use PNG they aren't capable of handling pure emissive colors. Use other file formats that store in linear space with premultiplied alpha. OpenEXR is a good example. I tried open EXR and keeps the alpha but not glow\bloom

Ivaylo Gogov commented

2021-02-03 18:04:43 +01:00

Added subscriber: @fclem

Ivaylo Gogov commented

2021-02-03 18:04:43 +01:00

Hello @fclem
Same here, I see a big difference between what people are trying to mention and what the reality is.

Real example: I'm using a blender to showcase and develop assets using alpha and smooth gradient effects.
After this confirmed, I'm moving this production to the development stage from which we need to collect the data from Blender. The standard format for 95% of the real-time render engines we used is PNGs. Not because we want it, but because the support of Open .exr's and others are not compatible with the render engines for embedded systems in Automotive Industries, where I work and develop using Blender.

I see a big difference when I export transparency open.EXR image especially when this not 32bit.
Basically, 90% of the TFT's for that field are supporting 16bits but not 32bits.
When I Open the.EXR and convert it to 16bit, there is a big difference in the colors, through the alpha, and basically this simply was not working.

!!! Converting the data once again, after is been ready in Blender is something that I really struggle with since I found such a defect exists.

All capabilities of Blender exporter are not in sync when this related to > **an image with alpha-transparent - smooth-gradient, especially when we save out of Blender to any format.

I still cannot understand what is so difficult for that fix?
Tell me please, where is the blocker?

The program it is been in serious development for years, and I'm really thankful for that.
However, we have been part of it also, and we have been supporting the process all the time. Now, I see something which I'm told cannot be resolved for more than 1 year ..?

Hello @fclem Same here, I see a big difference between what people are trying to mention and what the reality is. `Real example: `I'm using a blender to showcase and develop assets using alpha and smooth gradient effects. After this confirmed, I'm moving this production to the development stage from which we need to collect the data from Blender. The standard format for 95% of the real-time render engines we used is PNGs. Not because we want it, but because the support of Open .exr's and others are not compatible with the render engines for embedded systems in Automotive Industries, where I work and develop using Blender. - > I see a big difference when I export transparency open.EXR image especially when this not 32bit. Basically, 90% of the TFT's for that field are supporting 16bits but not 32bits. When I Open the.EXR and convert it to 16bit, there is a big difference in the colors, through the alpha, and basically this simply was not working. !!! Converting the data once again, after is been ready in Blender is something that I really struggle with since I found such a defect exists. All capabilities of Blender exporter are not in sync when this related to > **an image with alpha-transparent - smooth-gradient, especially when we save out of Blender to any format. I still cannot understand what is so difficult for that fix? Tell me please, where is the blocker? The program it is been in serious development for years, and I'm really thankful for that. However, we have been part of it also, and we have been supporting the process all the time. Now, I see something which I'm told cannot be resolved for more than 1 year ..?

Ivaylo Gogov commented

2021-02-03 19:54:10 +01:00

In #81390#1060780, @Jeroen-Bakker wrote:
@Jeroen-Bakker If alpha is important, please don't use PNG they aren't capable of handling pure emissive colors. Use other file formats that store in linear space with premultiplied alpha. OpenEXR is a good example.

@Jeroen-Bakker I'm giving you an example that, your suggestion won't work properly

You create an image in Blender using a smooth alpha transparency gradient. Then you render it F12.
Save this image in any format (however you want Open EXR for example)
Open EXR is supported only as 32bit, when you load this in photoshop or AE or any other program, you will have a number of limitations to do simple post-production. THEN
You have to convert the image from 32Bit to 16Bit and look what will happen?! -> it will look completely different

Even you won't do any post-production. The image will be completely different when you convert it from 32bit to 16bit.

How does this work for you? I don't know :) Still wondering ...

> In #81390#1060780, @Jeroen-Bakker wrote: > @Jeroen-Bakker If alpha is important, please don't use PNG they aren't capable of handling pure emissive colors. Use other file formats that store in linear space with premultiplied alpha. OpenEXR is a good example. @Jeroen-Bakker I'm giving you an example that, your suggestion won't work properly 1. You create an image in Blender using a smooth alpha transparency gradient. Then you render it F12. 2. Save this image in any format (however you want Open EXR for example) 3. Open EXR is supported only as 32bit, when you load this in photoshop or AE or any other program, you will have a number of limitations to do simple post-production. THEN 4. You have to convert the image from 32Bit to 16Bit and look what will happen?! -> it will look completely different Even you won't do any post-production. The image will be completely different when you convert it from 32bit to 16bit. How does this work for you? I don't know :) Still wondering ...

Clément Foucault commented

2021-02-04 15:07:22 +01:00

@IvayloGogov
I'm not sure I understand the issue. I've edited the original file to include some 3D solid color planes to check if blending is
the same in other applications. Of course it only works if said application uses the same colorspace. Here this works because Scenere Refered colorspace is the same as Display Linear space (using the Standard view transform).

ISSUE-RENDERING.blend

What I can say is this: exporting the render as .png and opening it in Gimp shows wrong alpha blending with the alpha checker / background color, BUT it does blend correctly if I put a layer with same color below it.

Over black checkerboard/background	Over black layer

To me this looks like blending in the wrong color space. Maybe there is an issue with this in photoshop as well? I know there is an option to enable linear blending. https://blog.prototypr.io/psa-on-mischievous-opacity-72bb355e6069

If this isn't the issue please post an image of what you get when you open the render with photoshop.

@IvayloGogov I'm not sure I understand the issue. I've edited the original file to include some 3D solid color planes to check if blending is the same in other applications. Of course it only works if said application uses the same colorspace. Here this works because Scenere Refered colorspace is the same as Display Linear space (using the Standard view transform). [ISSUE-RENDERING.blend](https://archive.blender.org/developer/F9630443/ISSUE-RENDERING.blend) ![untitled.png](https://archive.blender.org/developer/F9630447/untitled.png) What I can say is this: exporting the render as .png and opening it in Gimp shows wrong alpha blending with the alpha checker / background color, BUT it does blend correctly if I put a layer with same color below it. |Over black checkerboard/background| Over black layer| | -- | -- | |![Capture d’écran du 2021-02-04 14-57-11.png](https://archive.blender.org/developer/F9630430/Capture_d_écran_du_2021-02-04_14-57-11.png)|![Capture d’écran du 2021-02-04 14-56-50.png](https://archive.blender.org/developer/F9630432/Capture_d_écran_du_2021-02-04_14-56-50.png)| To me this looks like blending in the wrong color space. Maybe there is an issue with this in photoshop as well? I know there is an option to enable linear blending. https://blog.prototypr.io/psa-on-mischievous-opacity-72bb355e6069 If this isn't the issue please post an image of what you get when you open the render with photoshop.

Stefan Fallert commented

2021-11-11 11:51:00 +01:00

Added subscriber: @srfall

Stefan Fallert commented

2021-11-11 11:59:34 +01:00

I was about to create a new bug report when I found this task.
I am using 2.93.5 and still have the same problem as described in the original report: When saving a PNG with smooth alpha transparency, the colors get completely messed up.

I tried correcting the color space using ImageMagick but no success.

Is there any solution available to fix this?
(And no I can't just use exr. I need a png with correct alpha transparency)

I was about to create a new bug report when I found this task. I am using 2.93.5 and still have the same problem as described in the original report: When saving a PNG with smooth alpha transparency, the colors get completely messed up. ![untitled.png](https://archive.blender.org/developer/F11793508/untitled.png) I tried correcting the color space using ImageMagick but no success. Is there any solution available to fix this? (And no I can't just use exr. I need a png with correct alpha transparency)

Stefan Fallert commented

2021-11-11 18:08:57 +01:00

After reading the lengthy discussion here: https://developer.blender.org/T52680 I just want to summarize to see if I have gotten the correct points.

Blender handles and display the alpha transparency correctly now
Blender saves the alpha correctly, but PNG as a format is broken, which is why the saved images appear wrong
To which I reply: Even if PNG transparency is broken, since it is a widely used format, Blender should adapt and try its best to store it in a WYSIWYG manner.

For anyone having a similar issue and trying to get at least a somewhat accurate result: I was able to get an improved result by exporting the image as RGB PNG, then exporting the Alpha channel as separate grey scale PNG and then use ImageMagick to apply the transparency following this answer:
https://stackoverflow.com/questions/55376263/set-alpha-according-to-gradient-with-imagemagick/55377377

Also, since this appears to be a well known (and accepted ?) issue, how about a warning note in the export settings? This still seems to me like a major bug, but when the current position is: "Don't fix" then at least a heads up for the users would be nice.

After reading the lengthy discussion here: https://developer.blender.org/T52680 I just want to summarize to see if I have gotten the correct points. 1. Blender handles and display the alpha transparency correctly now 2. Blender saves the alpha correctly, but PNG as a format is broken, which is why the saved images appear wrong To which I reply: Even if PNG transparency is broken, since it is a widely used format, Blender should adapt and try its best to store it in a WYSIWYG manner. For anyone having a similar issue and trying to get at least a somewhat accurate result: I was able to get an improved result by exporting the image as RGB PNG, then exporting the Alpha channel as separate grey scale PNG and then use ImageMagick to apply the transparency following this answer: https://stackoverflow.com/questions/55376263/set-alpha-according-to-gradient-with-imagemagick/55377377 Also, since this appears to be a well known (and accepted ?) issue, how about a warning note in the export settings? This still seems to me like a major bug, but when the current position is: "Don't fix" then at least a heads up for the users would be nice.

Jeroen Bakker commented

2021-11-11 19:26:04 +01:00

Your points seems to be correct. Note that the described work-a-round can still introduce incorrect alpha blending as when apply-ing the transparency on a different color space than it was generated.
Adding an warning note in the export setting is a good idea.

Your points seems to be correct. Note that the described work-a-round can still introduce incorrect alpha blending as when apply-ing the transparency on a different color space than it was generated. Adding an warning note in the export setting is a good idea.

Stefan Fallert commented

2021-11-11 21:10:11 +01:00

Thanks for the quick answer.

Yeah, maybe I should have said it more clearly, the work-around doesn't give you a perfect result, but in my situation (where I need the png and care more about the overall look than perfect accurate blending) it gets me about 80% of the way, which is something I can work with.

*Sidenote: I guess an additional option in Blender to save it directly in a way similar to this hack may already be an improvement for many people

Thanks for the quick answer. Yeah, maybe I should have said it more clearly, the work-around doesn't give you a perfect result, but in my situation (where I need the png and care more about the overall look than perfect accurate blending) it gets me about 80% of the way, which is something I can work with. *Sidenote: I guess an additional option in Blender to save it directly in a way similar to this hack may already be an improvement for many people

Ivaylo Gogov commented

2021-11-11 21:49:34 +01:00

@srfall yes indeed. yes indeed. I was talking about this issue for a long time, but looks like was neglected, due to other urgent priorities on the road map, and squeezed schedule.
I think is a significant misalignment (bug) when we talk for high fidelity production, which is being there for years. There is no way to export a correct alpha from blender at the moment, doesn't matter if you use blender compositor e or other file type. At the end you always have to composite 2 flat images (once used as an alpha) the other as color, out of Blender to have an accurate look. Unfortunately, this is been for a long, long time.

@srfall yes indeed. yes indeed. I was talking about this issue for a long time, but looks like was neglected, due to other urgent priorities on the road map, and squeezed schedule. I think is a significant misalignment (bug) when we talk for high fidelity production, which is being there for years. There is no way to export a correct alpha from blender at the moment, doesn't matter if you use blender compositor e or other file type. At the end you always have to composite 2 flat images (once used as an alpha) the other as color, out of Blender to have an accurate look. Unfortunately, this is been for a long, long time.

jordi torres commented

2021-11-12 15:42:36 +01:00

Added subscriber: @jorditorres

jordi torres commented

2021-11-12 15:42:36 +01:00

Same bug happening to me. This is not a minor thing. There is any progress on this?

Martin Capitanio commented

2021-11-12 16:00:55 +01:00

Added subscriber: @capnm

Gerstmann Bradley commented

2021-11-13 19:27:15 +01:00

Added subscriber: @Bradley_G

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Blender 2.91.0 Alpha - Blender cannot export proper image when containing smooth gradient of Alpha #81390