Background images ignore View transform #67832

New Issue

Sergey Sharybin · 2019-07-28T12:28:27+02:00

Sergey Sharybin commented

2019-07-28 12:28:27 +02:00

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: 233f78c017
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 #66872 (which is a sepaarte root of the issue, and i'll fix that).

colorspace_example.blend

**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: `233f78c017` 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 #66872 (which is a sepaarte root of the issue, and i'll fix that). [colorspace_example.blend](https://archive.blender.org/developer/F7633353/colorspace_example.blend) ![mango.exr](https://archive.blender.org/developer/F7633354/mango.exr)

Sergey Sharybin commented

2019-07-28 12:28:27 +02:00

Added subscriber: @Sergey

blender-admin commented

2019-07-28 12:28:27 +02:00

#76188 was marked as duplicate of this issue

Brecht Van Lommel was assigned by Sergey Sharybin

2019-07-28 12:30:40 +02:00

Sergey Sharybin commented

2019-07-28 12:30:40 +02:00

Added subscribers: @brecht, @sebastian_k

Sergey Sharybin commented

2019-07-28 12:30:40 +02:00

@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?

@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?

Brecht Van Lommel removed their assignment 2019-08-02 13:52:18 +02:00

Sergey Sharybin was assigned by Brecht Van Lommel

2019-08-02 13:52:18 +02:00

Brecht Van Lommel commented

2019-08-02 13:52:18 +02:00

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.

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.

Jeroen Bakker commented

2019-11-04 10:12:17 +01:00

Added subscriber: @Jeroen-Bakker

Jeroen Bakker commented

2019-11-04 10:17:17 +01:00

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

Sergey Sharybin commented

2019-11-04 10:23:52 +01:00

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

Julien Leménicier commented

2019-12-07 15:26:18 +01:00

Added subscriber: @lemenicier_julien

Sergey Sharybin was unassigned by Dalai Felinto

2019-12-23 16:33:30 +01:00

Jeroen Bakker self-assigned this 2020-01-10 13:23:15 +01:00

Jeroen Bakker commented

2020-01-10 13:23:15 +01:00

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

Brecht Van Lommel commented

2020-01-15 17:04:01 +01:00

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.

Brecht Van Lommel commented

2020-01-28 15:10:18 +01:00

Ping, is this for 2.82 or not?

Jeroen Bakker commented

2020-01-28 16:12:29 +01:00

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 commented

2020-03-03 16:33:34 +01:00

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.

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.

Francesco Siddi commented

2020-03-04 16:44:46 +01:00

Added subscriber: @fsiddi