Isolate File Encoding Colour Management #58805

New Issue

Troy Sobotka · 2018-12-05T17:45:49+01:00

Troy Sobotka commented

2018-12-05 17:45:49 +01:00

Currently, a pixel pusher with the correct view set for an Apple Display [P3](https://archive.blender.org/developer/P3.txt) Display, ends up baking in the Display [P3](https://archive.blender.org/developer/P3.txt) transform into file encodes due to the way Blender encodes the file based off of the currently selected view.

Solution is to isolate the file encoding from the other output contexts such as displays and views.

Currently, a pixel pusher with the correct view set for an `Apple Display [P3](https://archive.blender.org/developer/P3.txt) Display`, ends up baking in the `Display [P3](https://archive.blender.org/developer/P3.txt)` transform into file encodes due to the way Blender encodes the file based off of the currently selected view. Solution is to isolate the file encoding from the other output contexts such as displays and views.

Troy Sobotka commented

2018-12-05 17:45:49 +01:00

Added subscriber: @troy_s

Brecht Van Lommel commented

2018-12-05 18:35:48 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2018-12-05 18:35:48 +01:00

This is not a bug per our bug tracker policy, nor does it have the required information:
https://developer.blender.org/maniphest/task/edit/form/1/

If you want to create a design task and work on this area that's fine, but it's not clear to me what your intent is here.

This is not a bug per our bug tracker policy, nor does it have the required information: https://developer.blender.org/maniphest/task/edit/form/1/ If you want to create a design task and work on this area that's fine, but it's not clear to me what your intent is here.

Troy Sobotka commented

2018-12-05 18:54:05 +01:00

Intent is that a person who saves a file using a proper transform doesn't end up with the proper file.

That's a bug, no?

Intent is that a person who saves a file using a proper transform doesn't end up with the proper file. That's a bug, no?

Brecht Van Lommel commented

2018-12-05 18:59:25 +01:00

No, it's a limitation of the color management implementation, more of a to do item.

The design for this is not obvious as well, which settings are shared between display and output, which OpenColorIO settings or color spaces to use.

No, it's a limitation of the color management implementation, more of a to do item. The design for this is not obvious as well, which settings are shared between display and output, which OpenColorIO settings or color spaces to use.

Jose commented

2019-12-12 17:29:56 +01:00

Added subscriber: @Dogway

Jose commented

2019-12-12 17:31:51 +01:00

I think currently this behavior only applies to byte type formats (ie EXR half-float unaffected)

Troy Sobotka commented

2019-12-12 18:43:31 +01:00

EXRs are designed to encode any type of data, which may include but is not limited to:

scene linear colour data
display linear colour data
scene nonlinear colour data, typically via a log-like transform
display nonlinear colour date
linear or nonlinear non-colour data such as depth, normals, cryptomattes, alpha occlusion, etc.

So while you are correct that the current behaviour is for byte encoded data, it would also technically impact EXRs based on the colour space input setting, as the saving of EXRs is based on the in-reference memory state.

For the colour data components, proper transform chains are required for all, even when saving from one already linearized format to another.

In terms of a design, a simple stack of transforms would suffice, with a “default” set via preferences. The preferences would be set by default based on OCIO default roles, and overridden where the audience has set a specific default.

EXRs are designed to encode any type of data, which may include but is not limited to: * scene linear colour data * display linear colour data * scene nonlinear colour data, typically via a log-like transform * display nonlinear colour date * linear or nonlinear non-colour data such as depth, normals, cryptomattes, alpha occlusion, etc. So while you are correct that the _current_ behaviour is for byte encoded data, it would also technically impact EXRs based on the colour space input setting, as the saving of EXRs is based on the in-reference memory state. For the colour data components, proper transform chains are required for all, even when saving from one already linearized format to another. In terms of a design, a simple stack of transforms would suffice, with a “default” set via preferences. The preferences would be set by default based on OCIO default roles, and overridden where the audience has set a specific default.

Wouter Stomp commented

2020-05-07 14:52:17 +02:00

Added subscriber: @blenderrocket

William Schilthuis commented

2020-05-10 21:34:42 +02:00

Added subscriber: @WilliamSchilthuis

Stefan Werner commented

2020-07-17 12:40:38 +02:00

Added subscriber: @Stefan_Werner

Vit Kovalcik commented

2020-07-30 13:35:09 +02:00

Added subscriber: @Blackx

baoyu commented

2021-12-21 21:27:11 +01:00

Added subscriber: @baoyu

baoyu commented

2021-12-21 21:27:11 +01:00

a pixel pusher with the correct view set for an Apple Display P3 Display, ends up baking in the Display P3 transform into file encodes

For display referred file formats, it's the right strategy. While for exrs, blender as the image producer, should write the gamut metadata(I assume blender already did this since a patch some time ago).
As a recommandation: for the display referred file formats like jpg and pngs, blender should write a "srgb.icc" or "p3.icc" into the image file, since if not, a external composite software would have no clue the image's gamut.

> a pixel pusher with the correct view set for an Apple Display [P3](https://archive.blender.org/developer/P3.txt) Display, ends up baking in the Display [P3](https://archive.blender.org/developer/P3.txt) transform into file encodes For display referred file formats, it's the right strategy. While for exrs, blender as the image producer, should write the gamut metadata(I assume blender already did this since a patch some time ago). As a recommandation: for the display referred file formats like jpg and pngs, blender should write a "srgb.icc" or "p3.icc" into the image file, since if not, a external composite software would have no clue the image's gamut.

Felix Herbst commented

2022-07-12 23:23:25 +02:00

Added subscriber: @herbst

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Isolate File Encoding Colour Management #58805