Please use the bug submission template and follow the reporting guidelines:
Particularly, mention the exact Blender version and provide exact steps to reproduce the problem.
Screenshot was from me.
Operating system: SUSE Leap 15.0
Graphics card: NVidia GTX 560ti (official drivers)
Broken: 2.80, a4869df4c9d2, x86_64 linux, 2019-03-31 (buildbot)
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)
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:
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.
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.
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:
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.