![]() Registered Member ![]()
|
I want to use Openexr format to export from Blender, so I can have values outside the 0-255 range. But . . . .
Whenever I load an Openexr into Krita, both single and multi-layer Openexr, the transparent pixels show up as pure black. I don't know much about Openexr, but I know something is wrong, because Gimp can open single-layer Openexr and the alpha channels work as expected, with transparency. Does anyone else use Openexr and can tell me what I am doing wrong? Krita 4.0.0 beta 1 Mint 18 |
![]() Registered Member ![]()
|
(main menu) "Image" > "Properties..." > "Background Opacity"=0? |
![]() Registered Member ![]()
|
That almost works, but it adds some transparency to pixels when the alpha value should be 100%.
And I wonder why this option is even needed, if the file is saved and the alpha value of some pixels is less than 100%, shouldn't Krita open it with the proper alpha values? In Blender, I can use the left mouse click on the render results screen and I can see the alpha values per each pixel. This is so weird. The idea of a multi-layer Openexr is to export all the passes like diffuse, specular, and shadow to a multi-layer file. Gimp 2.9 is great with single layer, but my hope was to have all the passes in a single file. |
![]() Registered Member ![]()
|
In Blender, when I render a layered EXR modified with Krita I don't see any added transparency to 100% opaque pixels.
Actually I can see all the passes of a layered EXR as layers in Krita. |
![]() Registered Member ![]()
|
Okay, I stopped doing this on Friday, but now I am back to it today and I want to share my issue.
This is the check in Blender of a specific pixel. Alpha value is 1.0: ![]() And then I save it as an Openexr and open in Krita, testing the exact same pixel on the 'combined' pass: ![]() What is going on here? I mean I understand that this may be an issue outside of Krita. Perhaps it is Blender, or maybe it is how Openexr itself works. I have no idea what is going on here. That pixel should be 100% alpha. Not only that, but something has changed the RGB values. I think the Blender community has collectively lost its mind over the new Filmic tone mapping, and that may be the issue because I am trying it now, but it should not have changed the apha values. |
![]() Registered Member ![]()
|
Actually, I take that back; I am not using the Filmic colors in that shot
|
![]() KDE Developer ![]()
|
Well, I don't remember the details, it's ages since we last touched the exr converter code, but alpha was always tricky, I seem to remember. http://www.openexr.com/TechnicalIntroduction.pdf has some details.
|
![]() KDE Developer ![]()
|
That's due premultiplied alpha. Krita doesn't premultiply alpha or have such color spaces, I think for openexr it is intended to be the default.
You can see this by doing some maths: Red = 0.227279 * 0.753587 = 0.171274499773 Which is... almost the same value as in blender, but sure a lot closer than unmultiplied ![]() The final difference might be related to the filmic tone mapping, as you say, or could be something else. (If you can reproduce this RGB difference on an exr where you don't think the tonemapping is fiddling with things report a bug with an attached exr.) (You could also see if there's other programs wich can view exrs that show the problem or not at all, to be sure) |
![]() Registered Member ![]()
|
Actually, I think I figured this out. . . hold on
|
![]() Registered Member ![]()
|
Ok TheraHedwig is probably right, and mvowada was correct from the beginning.
I did not notice the sample radius in my color picker. Wow this is a little embarrassing. On Friday I almost threw my computer out the window over this oversight. I had this massive sample radius on my color picker, so of course I was getting strange alpha values. Now having admitted that, the RGB values are still slightly different. |
Registered users: Bing [Bot], Google [Bot], kde-naveen, Sogou [Bot], Yahoo [Bot]