5
$\begingroup$

TL;DR: How can I properly save a picture with semi-transparent "emit" pixels coming from a bloom? I understand that .PNG can't handle that, but I'd expect TIFF/Targa/.EXR to handle it properly... and they don't (see below what I tried).

When generating an image with bloom (here some simple cubes in EEVE) and transparent background (see that I'm also using the default Filmic profile):

enter image description here

I can't find a good format to export it, in such a way that I can directly use it in other softwares to display it on top of other figures (if possible, I'd like it to work with Krita, Gimp, but also if possible in game engines like Godot or Unity, or (in my dream) in LaTeX/TikZ…):

What I tried:

.PNG does not work because it uses only straight alpha (so it means that it is impossible to have a "emit" pixel which fully transmits the light and also adds some colors). As you can see, all semi-transparent "bloom" parts are removed (I added here a black background):

enter image description here

.EXR (OpenEXR) are also not ideal: as I understand, they contain basically RAW data (linear space, ie colors basically belong to [0,+∞)), but they can be interpreted in many different ways, and I can't find any software that can accurately open it. For instance here you can see that the blue cube has bad colors in Krita (more precisely, it is displayed like if the "View Transform" in blender was configured to Standard instead of Filmic):

enter image description here

I tried to setup OpenColorIO with "filmic" in Krita (Parameters > Dockers > LUT, then taking the OCIO configuration from <blender install path>/2.92/datafiles/colormanagement/config.ocio):

enter image description here

but I get an error when I load the filmic view (and often a segfault later):

Error The specified transform file '/nix/store/pzi5xl05mifb53apxz6vhqmz7xp8zi66-blender-2.92.0/share/blender/2.92/datafiles/colormanagement/filmic/filmic_desat65cube.spi3d' could not be loaded. Not enough entries found. sending event 3 to object qt_scrollarea_viewport

If I open it with gimp, it's even worse, all semi-transparent area are removed, and GIMP does not support OCIO:

enter image description here

So .EXR files are really not ideal to work with, and I guess I've zero chance to make it work in Unity/Godot/LaTeX if softwares like Krita/Gimp can't open it properly.

Targa or TIFF The Targa and TIFF format are supposed to handle premultiplied alpha (this one allows us to have emit pixels), so in theory it should work (I guess)... but in practice it's not working better than .PNG, like if blender uses premultiplied alpha instead of straight alpha:

Here is an example with TIFF

enter image description here

and with Targa:

enter image description here

Is it a blender bug that Targa/TIFF output does not properly render the emit pixels? Is there a way to get a format (if possible quite widely used and that do not expect me to properly configure OCIO) that accurately represents the "Filmic" view given by blender? I'm desperate enough to accept convertion via imagemagick...

$\endgroup$
2

1 Answer 1

0
$\begingroup$

I don't assume per-se it may be a alpha-layer incongruence of any sort,

Reminder: In most circumstances PNG and TARGA will be the most gamma respecting formats, EXR will make some minor distortions, but sometimes more accurate than TARGA itself.

  • Minimal compression on any format will trash the luma details which Blender handles pretty well.

  • PNG does not have color profile embedded in the files, Targa only has a gamma value which can be problematic; EXR and JPEG do have embedded color profiles which may be interpreted independently by any application or hardware,


  • Then advance to hardware settings. You may find not all programs do respect the OS color models in all circumstances.


  • Try disabling color management at the OS level and use only the monitor presets, that should respect gamma the most and use the preference of the LCD itself,

  • then try to follow which programs do make use of native OS color models and find the appropiate program for each format.


  • Remember setting file compression to zero. in the case of PNG to 9 which preserves the luminosities.

    Finally try following the OS rules on monitor settings or finding updated color profile matching drivers for each monitor.
    Good luck.
    $\endgroup$

    You must log in to answer this question.

    Not the answer you're looking for? Browse other questions tagged .