Page MenuHome

Background images ignore View transform
Closed, ResolvedPublicKNOWN ISSUE


System Information
Operating system: Darwin-18.7.0-x86_64-i386-64bit 64 Bits
Graphics card: Intel(R) Iris(TM) Plus Graphics 655 Intel Inc. 4.1 INTEL-12.10.12

Blender Version
Broken: version: 2.80 (sub 75), branch: master, commit date: 2019-07-28 07:53, hash: rB233f78c01746
Worked: (optional)

Short description of error
View transform is ignored for both images and movie clips used as a background images in the viewport.

Ideally image will follow its "View as Render", and movie clip probably should just always respect view transform, similar to what's happening in the Clip Editor.

Exact steps for others to reproduce the error
Open attached file and see the difference between how texture on a cube is color managed and how is the background image is not.

Note that changes to color space might not be immediately visible in the viewport due to T66872 (which is a sepaarte root of the issue, and i'll fix that).

Event Timeline

Sergey Sharybin (sergey) lowered the priority of this task from 90 to 50.

@Brecht Van Lommel (brecht), on a more technical note i've looked into gpu_texture_create_from_ibuf which is used by the background images, but it is not really clear to me how view transform fits there. Linearize the result of view transform, and apply sRGB transform in there? Or separate split the background image and make them always be in display space?

As discussed, this is a consequence of the current design and similar to 2.7. Background images are drawn as overlays, and those are drawn without view transform.

The solution would probably be to either pre-transform the image on the CPU, or the change the overlay background image shader to optionally included a view transform. This would be based on the View as Render setting, with the goal of matching the image in the image editor and 3D viewport.

Wouldn't mind take a look on this task, after the T65347: Unify overlay engines that is currently in development. This task is somewhat related as it is hard to keep track of the loose changes.

@Jeroen Bakker (jbakker), be my guest to pick it up, you'll be more familiar with the draw manager thingamajig anyway :)

Jeroen Bakker (jbakker) changed the subtype of this task from "Report" to "Bug".
Jeroen Bakker (jbakker) changed the subtype of this task from "Bug" to "To Do".

It is actually a todo as it wasn't designed this way.

This is marked with the 2.82 milestone. If no fix is planned for that release, please move it to 2.83 or untag it from a specific milestone.

Ping, is this for 2.82 or not?

Ow, was too busy with the tracker curfew. Will set it to 2.83. Change is isolated, but would not want to add this at the last moment.

Jeroen Bakker (jbakker) triaged this task as High priority.Mar 3 2020, 4:30 PM

Users are reporting performance issues with large files. It is not sure this ticket will improve it, but we might want to check on it as it is most likely related to color management performance.
It could also be the case that the viewport color management improvements in b283 has reduced this. When the performance is still below expected we should create a new ticket to solve this.

Jeroen Bakker (jbakker) lowered the priority of this task from High to Normal.Apr 20 2020, 8:25 AM
Jeroen Bakker (jbakker) changed the subtype of this task from "To Do" to "Known Issue".Aug 18 2020, 2:28 PM