Page MenuHome

Del
Closed, InvalidPublic

Description

Del

Details

Type
Bug

Event Timeline

Brecht Van Lommel (brecht) lowered the priority of this task from Needs Triage by Developer to Needs Information from User.EditedMar 31 2019, 9:29 PM

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.

This comment was removed by Troy Sobotka (sobotka).
Troy Sobotka (sobotka) updated the task description. (Show Details)
Troy Sobotka (sobotka) updated the task description. (Show Details)
Paul R (intracube) added a comment.EditedApr 1 2019, 1:51 AM

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 (brecht) raised the priority of this task from Needs Information from User to Confirmed, Medium.EditedApr 2 2019, 7:56 PM

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 (brecht) renamed this task from Real-time Viewer Broken GPU Transforms to Inaccurate GPU color management for custom OCIO config.Apr 2 2019, 8:01 PM
Troy Sobotka (sobotka) renamed this task from Inaccurate GPU color management for custom OCIO config to Inaccurate GPU color management.Apr 2 2019, 9:34 PM
Brecht Van Lommel (brecht) renamed this task from Inaccurate GPU color management to Inaccurate GPU color management for custom OCIO config.Apr 2 2019, 9:50 PM

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

This comment was removed by Troy Sobotka (sobotka).

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

This comment was removed by Troy Sobotka (sobotka).

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.

This comment was removed by Troy Sobotka (sobotka).

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 (intracube) added a comment.EditedApr 4 2019, 6:20 PM

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:

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.

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

This comment was removed by Troy Sobotka (sobotka).

Huh, @Paul R (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.

This comment was removed by Troy Sobotka (sobotka).

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 (sobotka) renamed this task from Inaccurate GPU color management for custom OCIO config to Del.Apr 4 2019, 10:37 PM
Troy Sobotka (sobotka) closed this task as Invalid.
Troy Sobotka (sobotka) lowered the priority of this task from Confirmed, Medium to Confirmed, Low.
Troy Sobotka (sobotka) updated the task description. (Show Details)