The Proxy creation in the clip editor does not take color management into account #56703

New Issue

Sebastian Koenig · 2018-09-06T12:44:31+02:00

Sebastian Koenig commented

2018-09-06 12:44:31 +02:00

System Information
elementaryOS 0.4.1, GTX1080

Blender Version
Broken: 2.79.6, 7ff1750

Short description of error
When generating proxies from Blender's Clip Editor while using a different Color Management View profile other than Default, that color profile is not taken into account, making the proxies look different than the actual movie in the Clip Editor.

Exact steps for others to reproduce the error
The whole issue came up when trying to work with footage shot with the Arri Alexa.
The footage is a ProRes file, encode with Arri Wide Gamut in LogC. I am currently working with @troy_s on making that work inside Blender. The way we do that currently is as follows:
By using Blackmagic Fusion I convert the ProRes to a Linear EXR, but not rec709, instead it's Linear Arri Wide Gamut, in order to keep the data of that colorspace intact.
Loading this in Blender looks wrong of course, since Blender assumes an EXR file to be Linear Rec709.
In order to work around that, @troy_s thankfully created a new OpenColorIO config file, that uses the AWG colorspace when setting the view to Filmic.
Using that new config.ocio the Footage looks correct in the Clip Editor.
Obviously I need the Background Images in the 3D Viewport to look the same, since I want to integrate 3D elements into the footage.
However, when I generate the Proxies, they seem to use the Default Rec709 View Transform.
See this screenshot:

The colors in MCE at the bottom are correct, but wrong in the 3d View above.
I can understand that the 3D View cannot do realtime color conversions in order to maintain a decent playback. However, that's why I think the proxies need to take CM into account, including gamma and exposure.
For anyone who wants to try it, I have attached a folder with one frame from that footage, the proxy, the blendfile, as well as a the adjusted colormanagement folder with the new config.ocio. (I left out the film responce curves).
proxy_color.zip

**System Information** elementaryOS 0.4.1, GTX1080 **Blender Version** Broken: 2.79.6, 7ff1750 **Short description of error** When generating proxies from Blender's Clip Editor while using a different Color Management View profile other than Default, that color profile is not taken into account, making the proxies look different than the actual movie in the Clip Editor. **Exact steps for others to reproduce the error** The whole issue came up when trying to work with footage shot with the Arri Alexa. The footage is a ProRes file, encode with Arri Wide Gamut in LogC. I am currently working with @troy_s on making that work inside Blender. The way we do that currently is as follows: By using Blackmagic Fusion I convert the ProRes to a Linear EXR, but not rec709, instead it's Linear Arri Wide Gamut, in order to keep the data of that colorspace intact. Loading this in Blender looks wrong of course, since Blender assumes an EXR file to be Linear Rec709. In order to work around that, @troy_s thankfully created a new OpenColorIO config file, that uses the AWG colorspace when setting the view to Filmic. Using that new config.ocio the Footage looks correct in the Clip Editor. Obviously I need the Background Images in the 3D Viewport to look the same, since I want to integrate 3D elements into the footage. However, when I generate the Proxies, they seem to use the Default Rec709 View Transform. See this screenshot: ![proxy_colors.jpeg](https://archive.blender.org/developer/F4594896/proxy_colors.jpeg) The colors in MCE at the bottom are correct, but wrong in the 3d View above. I can understand that the 3D View cannot do realtime color conversions in order to maintain a decent playback. However, that's why I think the proxies need to take CM into account, including gamma and exposure. For anyone who wants to try it, I have attached a folder with one frame from that footage, the proxy, the blendfile, as well as a the adjusted colormanagement folder with the new config.ocio. (I left out the film responce curves). [proxy_color.zip](https://archive.blender.org/developer/F4595165/proxy_color.zip)

Sebastian Koenig commented

2018-09-06 12:44:31 +02:00

Added subscribers: @troy_s, @sebastian_k

Sergey Sharybin was assigned by Sebastian Koenig

2018-09-06 12:44:49 +02:00

Bastien Montagne commented

2018-09-08 16:11:41 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2018-09-08 16:11:41 +02:00

@Sergey guess that one is for you to handle? Though am not sure there is any bug here tbh…

Sebastian Koenig commented

2019-07-13 18:11:45 +02:00

I would like to come back to this issue.
@Sergey told me a while ago that this is indeed a bug, and for the upcoming VFX course this should be fixed.

The issue does not just arise with fancy custom wide gamut colorspaces, it's already a problem with Filmic / Standard view transform.

When you load some footage into the Clip Editor, the view transform is applied to that clip as well, and that's fine.
Now, when you use that clip as Camera Background Images in the 3d Viewport in order to setup your scene, with lighting and textures, etc., the background images do NOT use Filmic as view transform! So it is not possible to match your scene to the footage in the 3d viewport.
So what to do? First idea is to build proxies.
But when you create Proxies from your clip in the Clip Editor, the resulting proxies do not have the view transform nor the look applied to them. I do think they should though!

Another way to deal with this would be an option to apply color management to background images.
It might make sense to not use colormanagement for background images if you use reference images for modeling or so, but when it comes to Camera Background Images, which are mostly used for VFX, there should at least some option to apply your scene's View Transform to the background images as well. "View as Render" from the image editor comes to mind...

Now, let's say I have proxies with Filmic baked into them, in that case I would want to disable the imaginary "View as Render" button from above, instead the Standard sRGB view transform would be used for them, just as it is the case now, probably for performance reasons.

I would like to come back to this issue. @Sergey told me a while ago that this is indeed a bug, and for the upcoming VFX course this should be fixed. The issue does not just arise with fancy custom wide gamut colorspaces, it's already a problem with Filmic / Standard view transform. When you load some footage into the Clip Editor, the view transform is applied to that clip as well, and that's fine. Now, when you use that clip as Camera Background Images in the 3d Viewport in order to setup your scene, with lighting and textures, etc., the background images do NOT use Filmic as view transform! So it is not possible to match your scene to the footage in the 3d viewport. So what to do? First idea is to build proxies. But when you create Proxies from your clip in the Clip Editor, the resulting proxies do not have the view transform nor the look applied to them. I do think they should though! Another way to deal with this would be an option to apply color management to background images. It might make sense to not use colormanagement for background images if you use reference images for modeling or so, but when it comes to Camera Background Images, which are mostly used for VFX, there should at least some option to apply your scene's View Transform to the background images as well. "View as Render" from the image editor comes to mind... Now, let's say I have proxies with Filmic baked into them, in that case I would want to disable the imaginary "View as Render" button from above, instead the Standard sRGB view transform would be used for them, just as it is the case now, probably for performance reasons.

Troy Sobotka commented

2019-07-13 18:33:09 +02:00

So what to do?

There is only one answer, and it remains the same:

Always honour the intent of the RGB encoding. Always. That means there is never a case where pixel management is turned off or assumed, as it is a fundamental misunderstanding as to how pixel management works and what the intention of the encoded values in an RGB encoding represent.

>So what to do? There is only one answer, and it remains the same: Always honour the intent of the RGB encoding. *Always*. That means there is *never* a case where pixel management is turned off or assumed, as it is a fundamental misunderstanding as to how pixel management works and what the *intention of the encoded values in an RGB encoding represent*.

Sergey Sharybin was unassigned by Dalai Felinto

2019-12-23 16:36:00 +01:00

Dalai Felinto commented

2019-12-23 16:36:00 +01:00

Added subscriber: @Sergey

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

The Proxy creation in the clip editor does not take color management into account #56703