I haven’t found much info yet that’s why I changed this post title to see if anyone could shed some light on this issue.
1 Like
I’m currently using AGX and it’s not a problem with AGX.
Try changing the settings of the Alpha Channel part
I tested it and it has an impact.
※ I don’t know why, but the attached file was set to Channel Packed. (default setting is Straight)
Alpha Channel (https://docs.blender.org/manual/en/latest/glossary/index.html#term-Alpha-Channel)
Additional channel in an image for transparency.
Straight Alpha
Method where RGBA channels are stored as (R, G, B, A) channels, with the RGB channels unaffected by the alpha channel. This is the alpha type used by paint programs such as Photoshop or Gimp, and used in common file formats like PNG, BMP or Targa. So, image textures or output for the web are usually straight alpha.
Premultiplied Alpha
Method where RGBA channels are stored as (R × A, G × A, B × A, A), with the alpha multiplied into the RGB channel.
This is the natural output of render engines, with the RGB channels representing the amount of light that comes toward the viewer, and alpha representing how much of the light from the background is blocked. The OpenEXR file format uses this alpha type. So, intermediate files for rendering and compositing are often stored as premultiplied alpha.
Conversion (Straight/Premultiplied) Alpha
Conversion between the two alpha types is not a simple operation and can involve data loss, as both alpha types can represent data that the other cannot, though it is often subtle.
Straight alpha can be considered to be an RGB color image with a separate alpha mask. In areas where this mask is fully transparent, there can still be colors in the RGB channels. On conversion to premultiplied alpha, this mask is applied and the colors in such areas become black and are lost.
Premultiplied alpha, on the other hand, can represent renders that are both emitting light and letting through light from the background. For example, a transparent fire render might be emitting light, but also letting through all light from objects behind it. On converting to straight alpha, this effect is lost.
Channel Packed
A separate image map is stored for each color and alpha channel. Channel packing is commonly used by game engines to save memory and to optimize memory access.
1 Like
Just did some testing.
When the sRGB space is defined with OCIO’s feature (power 2.2 or piece-wise doesn’t matter, both would produce the issue):
The issue appears:
When you replace that line with a LUT that does the exact same thing as the original exponent transform line:
sRGB_EOTF.spi1d (48.1 KB)
The issue disappear:
I promise you the exponent transform line does the exact same thing as the LUT that I uploaded here. Here is the python code I used to generate this LUT:
Thus this is not an AgX issue.
EDIT:
Just did some more testing, it seems it has to do with a simple clamping:
It seems with this clamp in place, the issue is gone:
I guess the sRGB LUT clips it for you.
But I am not going to implement the clamping, since OCIO doesn’t support only clipping one channel, and clipping all channels would cause:
You lost all the data by a round trip between Linear BT.709 and sRGB, since you just clipped the data in sRGB.
I would guess that the straight alpha mode clips the alpha data for you, while the channel pack mode acts more like Non-Color data, it keeps everything unchanged since the alpha channel might be stuff like emission strength maps etc., therefore it doesn’t clip it.
3 Likes
I see that using straight the issue is gone but why does it remain when using channel packed? What files did you change? So is that a LUT you created? Not sure how the code works in the OCIO file but did you add that part to the AGX OCIO file?
I just read about the alpha in Blender docs and yes you are right it should be using straight instead of channel packed. That was my mistake from the beginning. For some reason I switched to that because it wasn’t working at some point and left it like that thinking it was the right method.
This is now when using “Straight” in 3.4.1 and AGX
And this is using “Channel Packed”:
So it is the opposite in this case. This is getting me confused.
There seems to be a problem with blender 3.4.1. But I don’t think it’s a problem with AGX,
it’s a problem with Blender. (I don’t think I can answer)
I think you’d better report a bug.
※ And AGX is not yet an officially supported feature on Blender. It’s stable,
but we don’t know what problems will arise. 
Yes I might report that. I know AGX is not supported maybe I should not use it anyway because even though it handles the range better than Filmic it has some other issues.
1 Like
There is no need to mention AgX if you report it, since it’s actually completely not relevant to AgX.
Here is how you can reproduce the issue with Blender’s current default config:
These two lines are completely the same as the sRGB LUTs Blender was using. Here is the stanza:
- !<ColorSpace>
name: sRGB
family:
equalitygroup:
bitdepth: 32f
description: |
sRGB display space
isdata: false
to_reference: !<ExponentWithLinearTransform> {gamma: 2.4, offset: 0.055}
from_reference: !<ExponentWithLinearTransform> {gamma: 2.4, offset: 0.055, direction: inverse}
Maybe but somehow changing the transform was giving different results so I wasn’t sure what was causing it. So you say it is 100% internally and nothing to do with the OCIO file? Would you say it is a transform issue but not specifically AGX?
As I already explained:
The nature of LUTs is that it would clip the incoming data, while the OCIO transform feature does not clip. Meaning somehow Cycles has errors when the data sent to it is not clamped. Or is it error or is it the correct behavior? You see, the alpha channle could be an emission strength map, should it clip it? I am not quite sure about this.
So you just simply don’t clip the sRGB space, then you can reproduce the issue, this is completely irrelevant to AgX.
Test the stanza I posted above if you have doubt. Just replace the sRGB stanza in default config.
I am a bit confused where did you get those 2 new lines from? Changing those in 3.4.1 original config file doesn’t change anything for me. Maybe I don’t understand exactly what you want me to test. in Blender 3.6.0 Alpha that I am testing it has the exact same ! sRGB settings as the 3.4.1. In fact both files are exactly the same yet 3.6.0 doesn’t have that issue.
Here is what I see in 3.6 alpha from yesterday with the two lines modified:
Using your test file.
And only Cycles seem to act this way, Eevee doesn’t
Have You consider that could be the alpha file the problem? I notice tha PS create bad alphas in PNG format. So I solved using a plugin for made better alpha or using B&W images instead of the alpha channel.
Bye
Matteo
I have used some other formats in the past but never had issues with PSD up until now. The problem is that using another image isn’t really efficient for me as I have to change lots of things all the time. 3.6.1 does not seem to have the problem reported in this thread anymore. I hope it keeps on working from now on. Thanks for your input.
1 Like