Del #63163

New Issue

Troy Sobotka · 2019-03-31T20:55:21+02:00

Troy Sobotka commented

2019-03-31 20:55:21 +02:00

Del

Troy Sobotka commented

2019-03-31 20:55:21 +02:00

Added subscriber: @troy_s

Brecht Van Lommel commented

2019-03-31 21:29:03 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2019-03-31 21:29:03 +02:00

Please use the bug submission template and follow the reporting guidelines:
https://developer.blender.org/maniphest/task/edit/form/1/

Particularly, mention the exact Blender version and provide exact steps to reproduce the problem.

Please use the bug submission template and follow the reporting guidelines: https://developer.blender.org/maniphest/task/edit/form/1/ Particularly, mention the exact Blender version and provide exact steps to reproduce the problem.

Troy Sobotka commented

2019-04-01 00:34:01 +02:00

This comment was removed by @troy_s

*This comment was removed by @troy_s*

Paul R commented

2019-04-01 01:29:23 +02:00

Added subscriber: @intracube

Paul R commented

2019-04-01 01:51:38 +02:00

Screenshot was from me.
extra details:

System Information
Operating system: SUSE Leap 15.0
Graphics card: NVidia GTX 560ti (official drivers)

Blender Version
Broken: 2.80, a4869df4c9, x86_64 linux, 2019-03-31 (buildbot)
Worked: -

Short description of error
Using OCIO configurations and LUTS besides the ones officially bundled (eg filmic_blender) causes the rendered 3d viewport values to skew - especially visible towards display referred peak values. Mid ranges seem unaffected.

note: This is only a realtime rendered 3d viewport issue. Applies to Cycles/Eevee. Final renders are unaffected.

Exact steps for others to reproduce the error

download blender_filmic and install: https://github.com/sobotka/filmic-blender
create an emission shader on a plane in Cycles or Eevee. set a value of (1.00, 0.00, 0.00)
do a final render
set a 3d viewport to rendered mode
compare outputs
note that 3d rendered viewport hits around (248, 1, 1) instead of (255, 0, 0)

Screenshot was from me. extra details: **System Information** Operating system: SUSE Leap 15.0 Graphics card: NVidia GTX 560ti (official drivers) **Blender Version** Broken: 2.80, a4869df4c9d2, x86_64 linux, 2019-03-31 (buildbot) Worked: - **Short description of error** Using OCIO configurations and LUTS besides the ones officially bundled (eg filmic_blender) causes the rendered 3d viewport values to skew - especially visible towards display referred peak values. Mid ranges seem unaffected. note: This is only a realtime rendered 3d viewport issue. Applies to Cycles/Eevee. Final renders are unaffected. **Exact steps for others to reproduce the error** - download blender_filmic and install: https://github.com/sobotka/filmic-blender - create an emission shader on a plane in Cycles or Eevee. set a value of (1.00, 0.00, 0.00) - do a final render - set a 3d viewport to rendered mode - compare outputs - note that 3d rendered viewport hits around (248, 1, 1) instead of (255, 0, 0)

Brecht Van Lommel commented

2019-04-02 19:56:51 +02:00

I can repro the issue in ociodisplay v1.1.0, but not in master. So it seems to be a bug in OpenColorIO that we can fix by upgrading.

v1.1.0 is the latest official release and master is v2 in development, with API breaking changes and potential instability. So upgrading is not entirely trivial. Some info here:
https://github.com/imageworks/OpenColorIO/blob/master/docs/tsc/meetings/2019-03-04.md

I can repro the issue in `ociodisplay` v1.1.0, but not in master. So it seems to be a bug in OpenColorIO that we can fix by upgrading. v1.1.0 is the latest official release and master is v2 in development, with API breaking changes and potential instability. So upgrading is not entirely trivial. Some info here: https://github.com/imageworks/OpenColorIO/blob/master/docs/tsc/meetings/2019-03-04.md

Brecht Van Lommel changed title from ~~Real-time Viewer Broken GPU Transforms~~ to Inaccurate GPU color management for custom OCIO config

2019-04-02 20:01:52 +02:00

Troy Sobotka changed title from ~~Inaccurate GPU color management for custom OCIO config~~ to Inaccurate GPU color management

2019-04-02 21:34:43 +02:00

Brecht Van Lommel changed title from ~~Inaccurate GPU color management~~ to Inaccurate GPU color management for custom OCIO config

2019-04-02 21:50:14 +02:00

Brecht Van Lommel commented

2019-04-02 21:50:50 +02:00

As far as I know this does not happen with the builtin config, so please leave the more descriptive title.

Troy Sobotka commented

2019-04-02 22:05:41 +02:00

This comment was removed by @troy_s

*This comment was removed by @troy_s*

Brecht Van Lommel commented

2019-04-02 22:21:23 +02:00

So a case where a user has specified a custom config rather than the Blender builtin one.

Troy Sobotka commented

2019-04-03 00:51:22 +02:00

This comment was removed by @troy_s

*This comment was removed by @troy_s*

Brecht Van Lommel commented

2019-04-03 01:49:18 +02:00

The config.ocio and its default sRGB transform as bundled with Blender work fine as far as I can tell. Perhaps because it has a larger output range than 0..1 which somehow sidesteps the problem.

Editing the builtin config to use a different sRGB transform could of course show the bug, but then it's a different config.

Since the same bug happens in ociodisplay with your filmic config, it seems the bug is in OpenColorIO and not Blender. I don't see any indication of the Blender GPU code being broken. There may be a way to work around the bug in your filmic config, so that it also works in other apps integrating OpenColorIO that presumably have the same problem if they support GPU acceleration.

We're not likely to spend time fixing a bug in OpenColorIO v1 if v2 is coming out soon enough.

The config.ocio and its default sRGB transform as bundled with Blender work fine as far as I can tell. Perhaps because it has a larger output range than 0..1 which somehow sidesteps the problem. Editing the builtin config to use a different sRGB transform could of course show the bug, but then it's a different config. Since the same bug happens in `ociodisplay` with your filmic config, it seems the bug is in OpenColorIO and not Blender. I don't see any indication of the Blender GPU code being broken. There may be a way to work around the bug in your filmic config, so that it also works in other apps integrating OpenColorIO that presumably have the same problem if they support GPU acceleration. We're not likely to spend time fixing a bug in OpenColorIO v1 if v2 is coming out soon enough.

Troy Sobotka commented

2019-04-03 02:17:39 +02:00

This comment was removed by @troy_s

*This comment was removed by @troy_s*

Brecht Van Lommel commented

2019-04-03 02:40:38 +02:00

Well, I have clear evidence of the bug being in OpenColorIO since it's also broken in ociodisplay. You only seem to be speculating that it must work because it's a basic transform. So the conclusion to me is clear, which is that it's not a bug in the Blender code unless someone proves otherwise.

Well, I have clear evidence of the bug being in OpenColorIO since it's also broken in `ociodisplay`. You only seem to be speculating that it must work because it's a basic transform. So the conclusion to me is clear, which is that it's not a bug in the Blender code unless someone proves otherwise.

Paul R commented

2019-04-04 18:20:06 +02:00

In #63163#653815, @brecht wrote:
The config.ocio and its default sRGB transform as bundled with Blender work fine as far as I can tell. Perhaps because it has a larger output range than 0..1 which somehow sidesteps the problem.

Yep, I modified the bundled srgb.spi1d to match the same range as the one provided by blender_filmic and the same issue then appears. So as you say, possibly the extension at the top end of the LUT hides the issue.

Since the same bug happens in ociodisplay with your filmic config, it seems the bug is in OpenColorIO and not Blender.

I can't reproduce the bug with ociodisplay set to Image ColorSpace->sRGB OETF + Transform->sRGB OETF - but, if ociodisplay is left with the default ('Linear') Image ColorSpace, then OCIO v1.1.0 does have reduced highlights, which look suspiciously similar to the issue in Blender, although not exactly the same values (240, 1, 1).

OCIO master (2019-04-04) hits peak display values and looks correct:

But if this is related, why is Blender using the Linear path for display instead of sRGB/sRGB?

Source test image:

> In #63163#653815, @brecht wrote: > The config.ocio and its default sRGB transform as bundled with Blender work fine as far as I can tell. Perhaps because it has a larger output range than 0..1 which somehow sidesteps the problem. Yep, I modified the bundled srgb.spi1d to match the same range as the one provided by blender_filmic and the same issue then appears. So as you say, possibly the extension at the top end of the LUT hides the issue. > Since the same bug happens in `ociodisplay` with your filmic config, it seems the bug is in OpenColorIO and not Blender. I can't reproduce the bug with ociodisplay set to `Image ColorSpace->sRGB OETF + Transform->sRGB OETF` - but, if ociodisplay is left with the default ('Linear') Image ColorSpace, then OCIO v1.1.0 does have reduced highlights, which look suspiciously similar to the issue in Blender, although not exactly the same values (240, 1, 1). OCIO master (2019-04-04) hits peak display values and looks correct: ![ociodisplay_1.1.0_vs_master_2019-04-04.png](https://archive.blender.org/developer/F6911799/ociodisplay_1.1.0_vs_master_2019-04-04.png) But if this is related, why is Blender using the Linear path for display instead of sRGB/sRGB? Source test image: ![colour_block_testchart.png](https://archive.blender.org/developer/F6911809/colour_block_testchart.png)

Brecht Van Lommel commented

2019-04-04 18:37:48 +02:00

But if this is related, why is Blender using the Linear path for display instead of sRGB/sRGB?

Rendering works in Linear color space, that's what we need to convert from.

> But if this is related, why is Blender using the Linear path for display instead of sRGB/sRGB? Rendering works in Linear color space, that's what we need to convert from.

Paul R commented

2019-04-04 19:00:37 +02:00

Just tried v1.1.1 as it was released yesterday. Unfortunately the same behaviour as 1.1.0.

Troy Sobotka commented

2019-04-04 20:13:19 +02:00

This comment was removed by @troy_s

*This comment was removed by @troy_s*

Brecht Van Lommel commented

2019-04-04 20:24:13 +02:00

Huh, @intracube posted a screenshot confirming it doesn't work in ociodisplay?

If sRGB -> sRGB works that's irrelevant, that's not the transform needed and it's a no-op.

Huh, @intracube posted a screenshot confirming it doesn't work in ociodisplay? If sRGB -> sRGB works that's irrelevant, that's not the transform needed and it's a no-op.

Troy Sobotka commented

2019-04-04 21:58:28 +02:00

This comment was removed by @troy_s

*This comment was removed by @troy_s*

Brecht Van Lommel commented

2019-04-04 22:05:51 +02:00

If you select the same color space for Image ColorSpace and Transform in ociodisplay, like Image ColorSpace->sRGB OETF + Transform->sRGB OETF, that's a no-op.

Please stop wasting my time and make an effort to understand what is going on here, instead of claiming I'm wrong without any logical explanation.

If you select the same color space for Image ColorSpace and Transform in ociodisplay, like `Image ColorSpace->sRGB OETF + Transform->sRGB OETF`, that's a no-op. Please stop wasting my time and make an effort to understand what is going on here, instead of claiming I'm wrong without any logical explanation.

Troy Sobotka changed title from ~~Inaccurate GPU color management for custom OCIO config~~ to Del

2019-04-04 22:37:16 +02:00

Troy Sobotka commented

2019-04-04 22:37:16 +02:00

Changed status from 'Open' to: 'Archived'

Troy Sobotka closed this issue

2019-04-04 22:37:16 +02:00

Acrivec Cevirca commented

2019-04-27 22:22:39 +02:00

Added subscriber: @Acrivec

Acrivec Cevirca commented

2019-04-27 22:22:39 +02:00

Wow, a rage quit in bugtracker.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Del #63163