Multilayer EXR UDIMs display incorrectly #101320

New Issue

Michael Kowalski · 2022-09-23T23:49:51+02:00

Michael Kowalski commented

2022-09-23 23:49:51 +02:00

Blender Version
Broken: since introduction of UDIM in 2.82

This issue was encountered when investigating #100452 (USD Alab v2 import errors)

The attached zip archive contains two blend files, which are identical except that they reference EXR and PNG UDIMs, respectively. alab_chair_exr_udim.blend, referencing the EXRs, displays incorrectly in the viewport (first image). alab_chair_png_udim.blend, referencing PNGs, displays correctly (second image).

blender_exr_udim_bug.zip

When the EXRs have multiple layers, even just 1, the problem occurs:

ok	not ok - uses a single layer called 'rgb'

Multilayer EXRs have a custom loading sequence and storage location inside the Image->rr (RenderResult) field.

That code is quite intertwined with the RenderLayer/RenderPass system. It's unclear why this was chosen for multi-layer images. Maybe because it was the system that knew how to select layers/passes already? In any case, it is not UDIM aware and I'm not sure if the RenderLayer/RenderPass system should be aware of them.

Since I don't have a full understanding of the history here a proper fix seems non trivial at first inspection.

**Blender Version** Broken: since introduction of UDIM in 2.82 This issue was encountered when investigating #100452 (USD Alab v2 import errors) The attached zip archive contains two blend files, which are identical except that they reference EXR and PNG UDIMs, respectively. `alab_chair_exr_udim.blend`, referencing the EXRs, displays incorrectly in the viewport (first image). `alab_chair_png_udim.blend`, referencing PNGs, displays correctly (second image). ![image.png](https://archive.blender.org/developer/F13561239/image.png) ![image.png](https://archive.blender.org/developer/F13561235/image.png) [blender_exr_udim_bug.zip](https://archive.blender.org/developer/F13561241/blender_exr_udim_bug.zip) When the EXRs have multiple layers, even just 1, the problem occurs: | ok | not ok - uses a single layer called 'rgb' | | -- | -- | | ![ok.png](https://archive.blender.org/developer/F13561308/ok.png) | ![not-ok.png](https://archive.blender.org/developer/F13561310/not-ok.png) | ---- Multilayer EXRs have a custom loading sequence and storage location inside the `Image->rr (RenderResult)` field. That code is quite intertwined with the RenderLayer/RenderPass system. It's unclear why this was chosen for multi-layer images. Maybe because it was the system that knew how to select layers/passes already? In any case, it is not UDIM aware and I'm not sure if the RenderLayer/RenderPass system should be aware of them. Since I don't have a full understanding of the history here a proper fix seems non trivial at first inspection.

Jesse Yurkovich was assigned by Michael Kowalski

2022-09-23 23:49:51 +02:00

Michael Kowalski commented

2022-09-23 23:49:51 +02:00

Added subscriber: @makowalski

Jesse Yurkovich commented

2022-09-24 00:01:50 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Jesse Yurkovich changed title from ~~UDIM EXR textures display incorrectly~~ to Multilayer EXR UDIMs display incorrectly

2022-09-24 03:39:22 +02:00

Jesse Yurkovich removed their assignment 2022-09-27 21:33:12 +02:00

Jesse Yurkovich commented

2022-09-27 21:33:12 +02:00

Added subscriber: @deadpin

Jesse Yurkovich commented

2022-09-27 21:33:12 +02:00

Will place this up for grabs right now. This needs HQ insight to help fill in the history and decide how to proceed; will try to surface to them in the meantime.

冰糖雪狸 commented

2022-09-29 15:48:57 +02:00

Added subscriber: @NekoSilverfox

冰糖雪狸 commented

2022-09-29 15:49:01 +02:00

Removed subscriber: @NekoSilverfox

Brecht Van Lommel commented

2022-10-08 01:24:22 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2022-10-08 01:24:22 +02:00

That code is quite intertwined with the RenderLayer/RenderPass system. It's unclear why this was chosen for multi-layer images. Maybe because it was the system that knew how to select layers/passes already?

I expect it was just the quickest way to get something working at the time.

Since I don't have a full understanding of the history here a proper fix seems non trivial at first inspection.

A proper fix may indeed take some significant refactoring.

I think ideally UDIMs, layers/passes, views and even sequences should all be possible to combine in a single image datablock, and be orthogonal concepts. The image multilayer code outside of rendering should stop relying on RenderResult.

We already have a ListBase tiles and ListBase views in Image, I think we should also have a ListBase layers of ImageLayer, which contains a ListBase passes of ImagePass. These layer and pass lists can be populated from a file on disk, render result, and eventually manually created by the user. Views already work like this, and layers and pass populating and syncing could be done in all the same places.

Image buffers are currently stored in an image cache that has key (frame, view) , where frame is also abused as UDIM tile index. Instead the key should be (frame, view, tile, layer, pass).

> That code is quite intertwined with the RenderLayer/RenderPass system. It's unclear why this was chosen for multi-layer images. Maybe because it was the system that knew how to select layers/passes already? I expect it was just the quickest way to get something working at the time. > Since I don't have a full understanding of the history here a proper fix seems non trivial at first inspection. A proper fix may indeed take some significant refactoring. I think ideally UDIMs, layers/passes, views and even sequences should all be possible to combine in a single image datablock, and be orthogonal concepts. The image multilayer code outside of rendering should stop relying on `RenderResult`. We already have a `ListBase tiles` and `ListBase views` in `Image`, I think we should also have a `ListBase layers` of `ImageLayer`, which contains a `ListBase passes` of `ImagePass`. These layer and pass lists can be populated from a file on disk, render result, and eventually manually created by the user. Views already work like this, and layers and pass populating and syncing could be done in all the same places. Image buffers are currently stored in an image cache that has key `(frame, view)` , where `frame` is also abused as UDIM tile index. Instead the key should be `(frame, view, tile, layer, pass)`.

Brecht Van Lommel commented

2022-10-08 04:32:11 +02:00

This also aligns with the plans for texture layers and baking, where we want to rely on multilayer images like this more. The idea there is to bake multiple passes to multilayer image datablocks. This datablock could then correspond to a single multilayer EXR file, but also e.g. separate PNG files for each pass. UDIM tiles, views and sequence frames are already separate image files in one image datablock so it's a natural extension to that.

Ashley referenced this issue

2023-02-09 15:24:58 +01:00

USD: fix various import problems with the Alab V2 scene #104515

Bastien Montagne added

and removed

labels 2023-02-10 12:08:49 +01:00

Sign in to join this conversation.