Mandelbulber 2.14 - 32 bit EXR Bugs

  • 14 Replies
  • 487 Views

0 Members and 1 Guest are viewing this topic.

Offline stilikon

  • *
  • Fractal Fanatic
  • ***
  • Posts: 31
« on: October 18, 2018, 07:33:10 PM »
Hi,
I am trying to get a proper image output for compositing out of Mandelbulber. (I come from a VFX Background)

When outputting as a 32 Bit EXR (or 16 Bit EXR), there is a couple of odd things (All compared to 8, or 16Bit PNG output)
1. the image is stored in sRGB even though its 32 EXR (or 16), which should be in linear color space.
     - I correct this in Nuke by color transforming it from sRGB to Linear (but then there is no benefit in actually outputting 32 Bit)
2. The same happens for the ZBuffer and Normal, but with 2 other problems (after sRGB to Linear)
     - The blue channel of the normal layer, comes out almost white, it has to be manually gamma corrected with 1/2.2 and multiplied by 0.2 to be correct


Might there be a way to fix this?
I think it would be a pitty if 32 Bit output is not properly usable.


Thanks a lot!
Best

Adrian

« Last Edit: October 19, 2018, 09:44:42 AM by stilikon »

Offline mclarekin

  • *
  • Fractal Frankfurter
  • *
  • Posts: 590
« Reply #1 on: October 19, 2018, 08:24:16 AM »
Hi Adrian, I have alerted the other Mandelbulber team members to your posts.  I have never tested exr or anti-aliasing so can not help.

Offline stilikon

  • *
  • Fractal Fanatic
  • ***
  • Posts: 31
« Reply #2 on: October 19, 2018, 09:44:59 AM »
Thanks!

Offline zebastian

  • *
  • Fractal Friend
  • **
  • Posts: 14
« Reply #3 on: October 19, 2018, 10:35:59 AM »
Hi @stilikon,

>About the colorspace:

The image channel colorspace of exr indeeed defaults to non-linear:
```
Channel (PixelType type = HALF,
        int xSampling = 1,
        int ySampling = 1,
        bool pLinear = false);
```
We will work something out to have this configurable for linear output.

> The blue channel of the normal layer, comes out almost white, it has to be manually gamma corrected with 1/2.2 and multiplied by 0.2 to be correct

The blue channel is mapped to the full range only for the positive direction 0 - 1 (blender like mode), maybe this is causing the discrepancy?

"...
    Normal maps in Blender store a normal as follows:

        Red maps from (0 - 255) to X (-1.0 - 1.0)
        Green maps from (0 - 255) to Y (-1.0 - 1.0)
        Blue maps from (0 - 255) to Z (0.0 - 1.0)

    Since normals all point towards a viewer, negative Z values are not stored (they would be invisible anyway). In Blender we store a full blue range, although some other implementations also map blue colors (128 - 255) to (0.0 - 1.0). The latter convention is used in Doom 3 for example.
..."
see here for full explanation: https://docs.blender.org/manual/fi/dev/render/blender_render/textures/properties/influence/bump_normal.html?highlight=bump

Offline zebastian

  • *
  • Fractal Friend
  • **
  • Posts: 14
« Reply #4 on: October 19, 2018, 12:39:55 PM »

Offline mancoast

  • *
  • Fractal Freshman
  • *
  • Posts: 5
« Reply #5 on: October 19, 2018, 04:30:16 PM »
Great catch here stilikon. Hope you enjoy the program! Are you using Windows or Linux or Mac release? I can get you a link to the latest developmental build package that includes Zebastions work.

Offline stilikon

  • *
  • Fractal Fanatic
  • ***
  • Posts: 31
« Reply #6 on: October 23, 2018, 01:57:30 PM »
Hey guys,
thanks so much for the quick response!
Really good to know that there is such a comitted team behind that.
Especially because I am now working on quite a large scale VFX VR project, where we chose Mandelbulber as main tool for our Fractal pipeline that we will build around it.


For the linear exr:
Great!
One thing I wanted to recheck though:
"PixelType type = HALF"
When selecting 32Bit EXR it should be set to "FULL" right?

@mancoast Would be awesome to get access to that build. Thanks.



For the normal issue:
Interesting with the "Blender Mode".
I checked the normal output more closely in nuke now though.
Two things are strange:
1. I would still expect the 16Bit PNG Normal too look similar to the 32BIT EXR normal right? But they look totally different in the blue channel.
2. For the EXR Normals, they are in a 0-1 range for red and green, but in a 0-~5 range for blue (0-~2 if not converting from sRGB to Linear). In the 16BIT PNG its all 0-1.

So too me it still looks that there might be some bug in the normal export?
See Image attached...

Thanks!

Adrian



Offline zebastian

  • *
  • Fractal Friend
  • **
  • Posts: 14
« Reply #7 on: October 24, 2018, 10:09:58 PM »
hi adrian,

yes, the 16 bit per channel is the exr specific "HALF" data format.
32 bit is the ordinary FLOAT format, which is the full data format. (IMHO recommended 32 bit per channel data format for vfx pipelines.)
Best stick to the 32bit format, as long as storage and bandwidth is not an issue.

Interesting, seems you are right. I will take a deeper look at this blue-channel-issue. PNG and EXR should look alike...

Did you get the same result with 16bit exr?

Offline zebastian

  • *
  • Fractal Friend
  • **
  • Posts: 14
« Reply #8 on: October 25, 2018, 10:37:29 PM »
hi adrian,

i double checked the code but could not find any issues yet.

find attached two examples of an exr output of the default mandelbulb with 16bpc and 32bpc (for all channels).
The comparison of the normal channels with exrdisplay looked OK so far. Can you double check with your software? -> What is the range of values in the n.Z channel?

Offline stilikon

  • *
  • Fractal Fanatic
  • ***
  • Posts: 31
« Reply #9 on: October 29, 2018, 08:09:42 PM »
Hey,
thanks for investigating.
I'm gonna check your images tomorrow morning...
Haven't tested with 16Bit EXR myself.

But I'm using 32Bit for normals and zDepth anyways.

Offline stilikon

  • *
  • Fractal Fanatic
  • ***
  • Posts: 31
« Reply #10 on: October 30, 2018, 11:01:12 AM »
Hey,
so I've checked it again.

1. Your Images are still in sRGB colorspace, but I guess you just haven't used the fix yet? (but no problem, for now i can just convert them from sRGB to linear)

2. There is no difference in the values between your 16Bit .exr and the 32Bit .exr, so that seems to work fine!

3. The values of the blue channel (so n.Z) are still in a ~ 0-5 range, the rest 0-1, so something must be broken there. If you look at the n.Z channel alone its basically white, also the background with empty space has small values in n.X and n.Y, but a value of almost 5 for n.Z. In the background they should all be 0.
To me it looks like there is some kind of value offset in the n.Z.

4. I have attached a image that shows this, + the render output of a noised sphere with the standard utitilty AOVs like normal and world position, just like you would have in Blender. (also attached the multi channel .exr itself)
You can see that the "Object Space Normal" range is 0-1, also in the n.Z channel.
The normals from Mandelbulber look something like "Object Space Normals", even though in 3D and compositing they are not really usefull and actually "World Space Normals" are the important AOV.
They are what their name suggests, normal vectors in World Space, so camera independent, and having a range of (-1) - 1 in n.X, n.Y, n.Z.
I think they should actually be easy to get. Hence you already have the "Object Space Normals", "World Space Normals" could maybe be added as an additional AOV?

Also you see and example of a world position pass here, also being what the name says, just storing the world position value of the sample in raw XYZ coordinate values.



Do you have access to a Software like Nuke whre you can properly inspect the values of a Multi Channel EXR?
If not, I think you can do it with https://www.exr-io.com/, a free Photoshop Plugin.
Or maybe GIMP can also handle Multi Channel EXRs? Not sure.

Offline claude

  • *
  • 3f
  • ******
  • Posts: 1232
    • mathr.co.uk
« Reply #11 on: October 30, 2018, 11:55:46 AM »
3. The values of the blue channel (so n.Z) are still in a ~ 0-5 range, the rest 0-1, so something must be broken there.

maybe it is storing depth in Z?  you only really need 2x components for a normal, because the 3rd value can be computed from the other two by assuming it is normalized (unit length) and pointing towards you..
(this is just a guess, I'm not very familiar with Mandelbulber, and I've never used EXR)

Offline 3DickUlus

  • *
  • 3f
  • ******
  • Posts: 1315
    • Digilantism
« Reply #12 on: October 31, 2018, 03:03:07 AM »
The OpenEXR package comes with some utils for manipulating EXR data and OpenImageIO has a very nice EXR viewer that lets you look at layers and internal file structure.
Fragmentarium is not a toy, it is a very versatile tool that can be used to make toys ;)

https://en.wikibooks.org/wiki/Fractals/fragmentarium

Offline stilikon

  • *
  • Fractal Fanatic
  • ***
  • Posts: 31
« Reply #13 on: November 22, 2018, 03:55:29 PM »
Hey guys,
any news here concerning the normal topic?

Checked in 2.15, still the same issue.

Offline stilikon

  • *
  • Fractal Fanatic
  • ***
  • Posts: 31
« Reply #14 on: November 22, 2018, 04:02:54 PM »
And thanks for implementing the linear EXR option in 2.15!

Unfortunately something must have gone a bit wrong there...

The colors in the linear EXR come out very strange, and its impossible to match the look of the correct looking 8 or 16Bit JPG or PNG in normal sRGB (or Gamma 2.2).
It looks like the might just have to be brightend up a bit or change the gamme a bit, but this doesnt work.
Wouldn't be a problem if it was justa bit different, but the colors are completely different and very odd in the linear EXR.

(for understanding, when I display a linear EXR in a Software like Nuke, or any other 32bit capable software, it reads it as linear and then for display converts it to SRGB. When reading a sRGB JPG or PNG it reads them as sRGB and displays them as such. So normally, a render of a sRGB JPG and linear EXR look identical in the viewer, if everything is correct).

See images below:


Thanks!


xx
I've just found a whole constellation of bugs in gallery commenting

Started by pauldelbrot on Forum Help And Support

9 Replies
282 Views
Last post January 21, 2018, 12:55:15 PM
by Fraktalist
xx
Mandelbulber v2 2.13

Started by buddhi on Downloads

0 Replies
574 Views
Last post April 01, 2018, 07:56:23 PM
by buddhi
xx
Mandelbulber 2.18

Started by buddhi on Mandelbulber

2 Replies
227 Views
Last post June 02, 2019, 03:49:02 PM
by kohlenstoff
xx
Mandelbulber 2.19

Started by buddhi on Mandelbulber

2 Replies
231 Views
Last post August 02, 2019, 12:25:40 AM
by Tas_mania
xx
Mandelbulber v2 2.14

Started by buddhi on Downloads

0 Replies
1315 Views
Last post June 13, 2018, 09:00:08 PM
by buddhi