PNG alpha fringe problem #34966

New Issue

Andrew Price · 2013-04-13T05:28:37+02:00

Andrew Price commented

2013-04-13 05:28:37 +02:00

%%%--- Operating System, Graphics card ---
Windows 7, 2x GTX 680

- Blender version with error, and version that worked ---

With error r55891. Worked in 2.66a

- Short description of error ---

Transparent PNG files cause a bad pixilated fringe in render eg: http://i.imgur.com/4k8sYYc.jpg

- Steps for others to reproduce the error (preferably based on attached .blend file) ---

Download a transparent PNG image like this one: http://cgtextures.com/texview.php?id=50326&PHPSESSID=mts6189k3unqmcckfuvqhnf484
Add it to a plane in blender and give it a node setup like this: http://i.imgur.com/z77I1DR.png
When rendered, you should see a noticeable white or black fringe around the transparent areas. Here's how it looks on a tree with transparent leaves: http://i.imgur.com/4k8sYYc.jpg

Here's the .blend: http://www.pasteall.org/blend/20734

It worked fine in 2.66a but the latest versions seems to mess up.

Sorry if this is a repeat. I searched for a similar bug request, but it didn't show anything.

Thanks%%%

%%%--- Operating System, Graphics card --- Windows 7, 2x GTX 680 - Blender version with error, and version that worked --- With error r55891. Worked in 2.66a - Short description of error --- Transparent PNG files cause a bad pixilated fringe in render eg: http://i.imgur.com/4k8sYYc.jpg - Steps for others to reproduce the error (preferably based on attached .blend file) --- 1. Download a transparent PNG image like this one: http://cgtextures.com/texview.php?id=50326&PHPSESSID=mts6189k3unqmcckfuvqhnf484 2. Add it to a plane in blender and give it a node setup like this: http://i.imgur.com/z77I1DR.png 3. When rendered, you should see a noticeable white or black fringe around the transparent areas. Here's how it looks on a tree with transparent leaves: http://i.imgur.com/4k8sYYc.jpg Here's the .blend: http://www.pasteall.org/blend/20734 It worked fine in 2.66a but the latest versions seems to mess up. Sorry if this is a repeat. I searched for a similar bug request, but it didn't show anything. Thanks%%%

Andrew Price commented

2013-04-13 05:28:37 +02:00

Changed status to: 'Open'

Sergey Sharybin commented

2013-04-15 12:06:32 +02:00

%%%Hi Andrew.
Checking on this, but remember Brecht did some changes to Cycles, so probably will re-assign to him :)%%%

%%%Hi Andrew. Checking on this, but remember Brecht did some changes to Cycles, so probably will re-assign to him :)%%%

Sergey Sharybin commented

2013-04-15 12:49:51 +02:00

%%%Brecht, this is indeed caused by rev55818. Do you think we'll just break compatibility or maybe it could be preserved somehow? Also, not so much clear commit log there: "New rule is now that color output will not give straight RGB values if the alpha output is used" but what you do in fact un-premultiplying if Alpha socket is connected which is more like outputting straight color if alpha is connected, or am i missing something?

Andrew, probaly workaround could be to premultiply color with alpha. Not sure it'll work all fine tho.%%%

%%%Brecht, this is indeed caused by rev55818. Do you think we'll just break compatibility or maybe it could be preserved somehow? Also, not so much clear commit log there: "New rule is now that color output will not give straight RGB values if the alpha output is used" but what you do in fact un-premultiplying if Alpha socket is connected which is more like outputting straight color if alpha is connected, or am i missing something? Andrew, probaly workaround could be to premultiply color with alpha. Not sure it'll work all fine tho.%%%

Brecht Van Lommel commented

2013-04-16 16:02:40 +02:00

%%%The issue in this particular .blend file was about packed image files, cycles assumes all images to have premultiplied alpha as they do when coming from OpenImageIO but this was not the case here, so fixed that.

The 3.png file still has some (less noticeable) white fringes, but they show in the image editor and other image viewers outside of Blender too. So that's a problem in the image itself.

Sergey, the behavior of the image texture node after that other fix is indeed not so great, have it on my todo list to implement a better solution.%%%

%%%The issue in this particular .blend file was about packed image files, cycles assumes all images to have premultiplied alpha as they do when coming from OpenImageIO but this was not the case here, so fixed that. The 3.png file still has some (less noticeable) white fringes, but they show in the image editor and other image viewers outside of Blender too. So that's a problem in the image itself. Sergey, the behavior of the image texture node after that other fix is indeed not so great, have it on my todo list to implement a better solution.%%%

Brecht Van Lommel commented

2013-04-16 16:02:40 +02:00

Changed status from 'Open' to: 'Resolved'

Brecht Van Lommel closed this issue

2013-04-16 16:02:40 +02:00

Scott Jenkins commented

2013-04-16 21:27:55 +02:00

%%%Hi all, I am a coder, looking to get involved in the blender project and figured best way to start was to pick a bug and go. I picked this one, b/c I figured it was easy to reproduce and it is. What I've found is if the image is if the image is unpacked it works as intended, otherwise no. This behavior seems to be consistent for all packed/unpacked images. That being said, we have a UV editor that is showing a straight value and rendered we're getting something else, premultiplied. If indeed the premultiplied is required, then we need some workflow where the user is notified that the images aren't going to be what they thought they were?%%%

Brecht Van Lommel commented

2013-04-17 04:03:01 +02:00

%%%Ah, yes the bug is already fixed, it might be a good idea to mention you're looking into a bug so we can avoid working on the same bug.

I'm not sure how you would notify the user about this, I think it's something that would be mentioned in documentation? The way I see it is that premultiplying the image does not give you something else, rather it just means the alpha information is being used, the same way it's used when viewing the full color + alpha image in the image editor.%%%

%%%Ah, yes the bug is already fixed, it might be a good idea to mention you're looking into a bug so we can avoid working on the same bug. I'm not sure how you would notify the user about this, I think it's something that would be mentioned in documentation? The way I see it is that premultiplying the image does not give you something else, rather it just means the alpha information is being used, the same way it's used when viewing the full color + alpha image in the image editor.%%%

Scott Jenkins commented

2013-04-17 04:26:46 +02:00

%%%I've just started so getting my feet wet. I'll make sure to post something on next one, but I don't want to prevent normal workflow of active development on first few bugs. I figure I can help by trying to understanding the vision of some of these features and then trying to implement some of that by working on bug list.

I think the real issue is that straight value alpha images packed or unpacked should behave the same. This might mean never use straight alpha image ever in cycles but I think the option in the uv editor that shows straight or pre-multiplied then needs to be removed to reflect that change. Currently that isn't the case, and this seems like an issue that is really going to trip up quite a few people since you have an editor that shows you using a straight alpha in the UV but then when it gets rendered its assume it is pre-multiplied.%%%

%%%I've just started so getting my feet wet. I'll make sure to post something on next one, but I don't want to prevent normal workflow of active development on first few bugs. I figure I can help by trying to understanding the vision of some of these features and then trying to implement some of that by working on bug list. I think the real issue is that straight value alpha images packed or unpacked should behave the same. This might mean never use straight alpha image ever in cycles but I think the option in the uv editor that shows straight or pre-multiplied then needs to be removed to reflect that change. Currently that isn't the case, and this seems like an issue that is really going to trip up quite a few people since you have an editor that shows you using a straight alpha in the UV but then when it gets rendered its assume it is pre-multiplied.%%%

Andrew Price commented

2013-04-17 04:46:41 +02:00

%%%Thanks again for another fast fix Brecht. Much appreciated :)%%%

Brecht Van Lommel commented

2013-04-17 05:54:08 +02:00

%%%Scott, it's not clear to me if you are talking about the behavior before or after the fix I did? With the fix, both packed and non-packed PNG images will now be automatically converted from straight to premultiplied alpha, and the attached .blend renders the same with the image packed or not packed.

It is true that Cycles non-packed images do not yet support the Straight/Premul option on image datablocks, because OpenImageIO does not support this. However this option should almost never be changed, the only reason to use that is if you have an invalid image which does not respect the file format convention. It would be nice to support that but it's considered a "known limitation" at the moment and not a very important one. For typical users the current code should load images appropriately by default without the user have to know if it was a premultiplied or straight alpha image.%%%

%%%Scott, it's not clear to me if you are talking about the behavior before or after the fix I did? With the fix, both packed and non-packed PNG images will now be automatically converted from straight to premultiplied alpha, and the attached .blend renders the same with the image packed or not packed. It is true that Cycles non-packed images do not yet support the Straight/Premul option on image datablocks, because OpenImageIO does not support this. However this option should almost never be changed, the only reason to use that is if you have an invalid image which does not respect the file format convention. It would be nice to support that but it's considered a "known limitation" at the moment and not a very important one. For typical users the current code should load images appropriately by default without the user have to know if it was a premultiplied or straight alpha image.%%%

Scott Jenkins commented

2013-04-17 06:35:29 +02:00

%%%My apologies, when you had mentioned already fixed I thought I had the latest but I noticed there was another build and both issues the alpha map behavior automatically adjusting as you mentioned and the interface issue I was looking at in the UV editor both are fixed in the very next checkout and working as intended. Sorry again for the confusion.

%%%

%%%My apologies, when you had mentioned already fixed I thought I had the latest but I noticed there was another build and both issues the alpha map behavior automatically adjusting as you mentioned and the interface issue I was looking at in the UV editor both are fixed in the very next checkout and working as intended. Sorry again for the confusion. %%%

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

PNG alpha fringe problem #34966