Replace Default OCIO config with AgX (Filmic v2) #106355

Closed
Zijun Zhou wants to merge 112 commits from (deleted):main into main

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
Contributor
Filmic AgX
Filmic_Monkey_Orange_Lights AgX_Monkey_Orange_Lights
Filmic_Apple_Under_Sunset AgX_Apple_Under_Sunset
Filmic_Monkey_Light_BT2020_Green AgX_Monkey_Light_BT2020_Green
Filmic_Siren_arri_alexa35 AgX_Siren_ARRI_Alexa_35
Filmic_blue_bar AgX_blue_bar
Filmic_Cityscape AgX_Cityscape

Note: some info here is outdated, for updated info, see the GitHub repo:
https://github.com/EaryChow/AgX

What?

Eary's AgX is an OCIO v2 configuration made with the intention to replace Blender's default config, to give Blender a better color management and image formation for the upcoming Spectral Cycles.

The config was built more specifically for Blender, but other software that supports OCIO v2 should also be able to use it.

The two featuring image formations (view transforms) are Guard Rail and AgX. Guard Rail is targeted as a replacement for Blender's "Standard", while AgX is targeted as a replacement for "Filmic".

"AgX" the name is a pseudo-chemical notation of silver halide, commonly used in photographic film, therefore, AgX is an alias of Filmic.

AgX is similar to Filmic as a sigmoid-driven formation, while Guard Rail is a minimalist image formation that broke-out from AgX, that only touches values out of the valid [0, 1] target display medium range.

AgX Image formation does two things

  • It forms a [0.0, 1.0] closed domain image from the unbounded radiometric-like tristimulus data that modern 3D render engines like Cycles and Eevee produce.
  • It provides smooth chromatic attenuation in the image across challenging use cases including wider gamut rendering, real-camera-produced colorimetry etc.

This config also comes with a different colorspace naming scheme, but with backwards compatibility setup with OCIO v2 feature of aliases, so that texture colorspaces in old .blend files will get auto-converted to the new names.

Three of the frequently asked space names are:

  • ̶G̶e̶n̶e̶r̶i̶c̶ ̶D̶a̶t̶a̶,̶ ̶t̶h̶i̶s̶ ̶c̶o̶r̶r̶e̶s̶p̶o̶n̶d̶s̶ ̶t̶o̶ ̶t̶h̶e̶ ̶l̶e̶g̶a̶c̶y̶ ̶N̶o̶n̶-̶C̶o̶l̶o̶r̶ ̶a̶n̶d̶ ̶R̶a̶w̶
  • ̶̶s̶R̶G̶B̶ ̶2̶.̶2̶̶,̶ ̶t̶h̶i̶s̶ ̶c̶o̶r̶r̶e̶s̶p̶o̶n̶d̶s̶ ̶t̶o̶ ̶t̶h̶e̶ ̶l̶e̶g̶a̶c̶y̶ ̶̶s̶R̶G̶B̶̶
  • Linear BT.709 I-D65, this corresponds to the legacy Linear

Why?

Because the current Filmic has issues like the Notorious Six, meaning Filmic collapses all colors into six before attenuating to white. Filmic also doesn't have the capability to handle wider gamut render produced by wider working space, spectral rendering, real-camera-produced colorimetry etc.

AgtX_vs_Filmic Sweep
AgX (Left) vs Filmic (Right)

View Transforms

The config includes the following view transform:

  • Guard RailThe minimalist image formation that only touches "the invalid", replaces Blender's legacy "Standard".
  • AgX The Filmic-like sigmoid based image formation with 16.5 stops of dynamic range.
  • AgX Log The Log encoding with chroma-inset and rotation of primaries included. Uses BT.2020 primaries with Log 2 encoding from -12.47393 to 12.5260688117(25 stops of dynamic range) and I-D65 white point.
  • AgX False Color A heat-map-like imagery derived from AgX's formed image. uses BT.2020's CIE 2012 luminance for luminance coefficients evaluation.

False Color ranges

Different from False Color in current Blender or the Filmic-Blender config, the false color here is a post-formation closed domain evaluation. Therefore, all values below will be linearized 0 to 1 value written in percentage.

[0.0, 1.0] Closed Domain Linear Color
Low Clip Black
0.0001% to 0.05% Blue
0.05% to 0.5% Blue-Cyan
0.5% to 5% Cyan
5% to 16% Green-Cyan
16% to 22% Grey
22% to 35% Green-Yellow
35% to 55% Yellow
55% to 80% Orange
80% to 97% Red
High Clip White

ea6deefe57f43e8684b6be27e3964fae_d676374d-3b8b-4e65-b048-5a17fd083a7f

Looks
"Looks" are artistic adjustment to the image formation chain.

  • Punchy A contrast look that makes the image look more “punchy” by darkening the image.

  • Greyscale Turn the image into greyscale. Luminance coefficients are BT.2020’s CIE 2012 values, evaluated in Linear state.

  • Seven Contrast Looks. Similar to Filmic’s contrast looks. All operates in AgX Log, with pivot set in 0.18 middle grey. All using OCIO v2’s Grading Primary Transform feature, meaning you can customize your contrast just by editing the values in the config.

Colorimetric Information

  • Reference Every OCIO config has their own reference space, all other spaces are defined with how they transform “from” and/or “to” the reference space. While Blender’s previous config has been using Linear BT.709 I-D65 as reference, this config uses 1931 CIE XYZ E white point chromaticity as reference. This is a sane decision, since CIE XYZ is the root for everything else color management related. FilmLight’s TCAMv2 config also has CIE XYZ as reference.

  • AgX Base image formation space The AgX in this config has one single image formed in the BT.2020 display medium, then the images for other mediums are produced from the formed image in BT.2020.

  • Supported Image Display Mediums:

    • sRGB, Generic sRGB / REC.709 displays with 2.2 native power function
    • BT.1886, Generic sRGB / REC.709 displays with 2.4 native power function
    • Display P3 P3 displays with 2.2 native power function. Examples include:
      Apple MacBook Pros from 2016 on.
      Apple iMac Pros.
      Apple iMac from late 2015 on.
    • BT.2020BT.2020 displays with 2.4 native power function.

    It's very unlikely someone would use a BT.2020 2.4 display as of now, but since we have the image formed in BT.2020, supporting it is just a "why not?" thing to do.

  • Colorspaces
    This config supports the following colorspaces:

    • Linear CIE-XYZ I-E This is the standard 1931 CIE chromaticity standard used as reference.
    • Linear CIE-XYZ I-D65 This is the chromatic-adaptated to I-D65 version of the XYZ chromaticity. Method used is Bradford
    • Linear BT.709 I-E Open Domain Linear BT.709 Tristimulus with I-E white point
    • Linear BT.709 I-D65 Open Domain Linear BT.709 Tristimulus with I-D65 white point
    • Linear DCI-P3 I-E Open Domain Linear P3 Tristimulus with I-E white point
    • Linear DCI-P3 I-D65 Open Domain Linear P3 Tristimulus with I-D65 white point
    • Linear BT.2020 I-E Open Domain Linear BT.2020 Tristimulus with I-E white point
    • Linear BT.2020 I-D65 Open Domain Linear BT.2020 Tristimulus with I-D65 white point
    • ACES2065-1 Open Domain AP0 Tristimulus with ACES white point
    • ACEScg Open Domain AP1 Tristimulus with ACES white point
    • Linear E-Gamut I-D65 Open Domain Linear E Gamut Tristimulus with I-D65 white point
    • sRGB ̶ ̶2̶.̶2̶ sRGB 2.2 Exponent Reference EOTF Display
    • BT.1886 ̶ ̶2̶.̶4̶ BT.1886 2.4 Exponent EOTF Display
    • Display P3 ̶ ̶2̶.̶2̶Display P3 2.2 Exponent EOTF Display
    • BT.2020 ̶ ̶2̶.̶4̶ BT.2020 2.4 Exponent EOTF Display
    • ̶̶G̶e̶n̶e̶r̶i̶c̶ ̶D̶a̶t̶a̶̶ Non-Color Generic data that is not color, will not apply any color transform

Note: I-E is short for “Illuminant E”, I-D65 is short for “Illuminant D65”.

  • The use of I-E white point

    The main reason for supporting the I-E version of the spaces is to be prepared for the upcoming Spectral Cycles. Spectral renderers with capability to input RGB textures require an I-E based RGB working space to ensure an error-free spectral reconstruction/upsampling process.

    Note for using Eary’s AgX for Spectral Cycles: Remember to change the XYZ role to the I-E version of the XYZ chromaticity.

| Filmic| AgX | | -------- | -------- | | ![Filmic_Monkey_Orange_Lights](https://blenderartists.org/uploads/default/original/4X/4/e/3/4e395ca129226b8ecb01471b403bd283bb953df4.jpeg) | ![AgX_Monkey_Orange_Lights](https://blenderartists.org/uploads/default/original/4X/6/0/6/6068672959b2cb435234b5891f1c3e41144f3f4c.png)| | ![Filmic_Apple_Under_Sunset](https://blenderartists.org/uploads/default/original/4X/c/8/a/c8a48e84ac64557148104974f0f218c16fc27c57.jpeg) | ![AgX_Apple_Under_Sunset](https://blenderartists.org/uploads/default/original/4X/f/7/f/f7f41039013fa5d5c231346958f896ba35e14217.jpeg)| | ![Filmic_Monkey_Light_BT2020_Green](https://blenderartists.org/uploads/default/original/4X/3/2/6/3264a918f717246f0fd693792dca7f1ea65da4d1.jpeg) | ![AgX_Monkey_Light_BT2020_Green](https://blenderartists.org/uploads/default/original/4X/d/1/c/d1c005acb299ce839d143cb12e03358d00ff6945.jpeg)| |![Filmic_Siren_arri_alexa35](https://blenderartists.org/uploads/default/original/4X/7/6/f/76faa52a80bdd623efe9894c6121e58a774ba98c.jpeg)| ![AgX_Siren_ARRI_Alexa_35](https://blenderartists.org/uploads/default/original/4X/f/6/6/f665d1a9dd8a4a63447f017261d1bb5c18772ced.jpeg) | |![Filmic_blue_bar](https://blenderartists.org/uploads/default/original/4X/b/8/0/b8071bb2d02c13bfe600a9709eb91ab8e17b5140.png)| ![AgX_blue_bar](https://blenderartists.org/uploads/default/original/4X/7/e/7/7e768bd91be75ae9c8c9753cb3efb69322744c3f.png)| | ![Filmic_Cityscape](https://blenderartists.org/uploads/default/original/4X/6/0/0/6008dbfe018cbd493d43c73f71a9167ca9f0086d.jpeg) | ![AgX_Cityscape](https://blenderartists.org/uploads/default/original/4X/7/5/2/7523eca77c192011b0cbc7cf108b8dd2f80a444d.jpeg) | Note: some info here is outdated, for updated info, see the GitHub repo: https://github.com/EaryChow/AgX **What?** Eary's AgX is an OCIO v2 configuration made with the intention to replace Blender's default config, to give Blender a better color management and image formation for the upcoming Spectral Cycles. The config was built more specifically for Blender, but other software that supports OCIO v2 should also be able to use it. The two featuring image formations (view transforms) are Guard Rail and AgX. Guard Rail is targeted as a replacement for Blender's "Standard", while AgX is targeted as a replacement for "Filmic". "AgX" the name is a pseudo-chemical notation of silver halide, commonly used in photographic film, therefore, AgX is an alias of Filmic. AgX is similar to Filmic as a sigmoid-driven formation, while Guard Rail is a minimalist image formation that broke-out from AgX, that only touches values out of the valid [0, 1] target display medium range. `AgX` Image formation does two things - It forms a [0.0, 1.0] closed domain image from the unbounded radiometric-like tristimulus data that modern 3D render engines like Cycles and Eevee produce. - It provides smooth chromatic attenuation in the image across challenging use cases including wider gamut rendering, real-camera-produced colorimetry etc. This config also comes with a different colorspace naming scheme, but with backwards compatibility setup with OCIO v2 feature of aliases, so that texture colorspaces in old .blend files will get auto-converted to the new names. Three of the frequently asked space names are: - ̶G̶e̶n̶e̶r̶i̶c̶ ̶D̶a̶t̶a̶,̶ ̶t̶h̶i̶s̶ ̶c̶o̶r̶r̶e̶s̶p̶o̶n̶d̶s̶ ̶t̶o̶ ̶t̶h̶e̶ ̶l̶e̶g̶a̶c̶y̶ ̶N̶o̶n̶-̶C̶o̶l̶o̶r̶ ̶a̶n̶d̶ ̶R̶a̶w̶ - ̶`̶s̶R̶G̶B̶ ̶2̶.̶2̶`̶,̶ ̶t̶h̶i̶s̶ ̶c̶o̶r̶r̶e̶s̶p̶o̶n̶d̶s̶ ̶t̶o̶ ̶t̶h̶e̶ ̶l̶e̶g̶a̶c̶y̶ ̶`̶s̶R̶G̶B̶`̶ - `Linear BT.709 I-D65`, this corresponds to the legacy `Linear` **Why?** Because the current Filmic has issues like the Notorious Six, meaning Filmic collapses all colors into six before attenuating to white. Filmic also doesn't have the capability to handle wider gamut render produced by wider working space, spectral rendering, real-camera-produced colorimetry etc. ![AgtX_vs_Filmic Sweep](https://user-images.githubusercontent.com/59176246/228655449-0b9b5e7b-e962-400f-bfb5-56c104bc7cd9.png) AgX (Left) vs Filmic (Right) **View Transforms** The config includes the following view transform: - `Guard Rail`The minimalist image formation that only touches "the invalid", replaces Blender's legacy "Standard". - `AgX` The Filmic-like sigmoid based image formation with 16.5 stops of dynamic range. - `AgX Log` The Log encoding with chroma-inset and rotation of primaries included. Uses BT.2020 primaries with Log 2 encoding from `-12.47393` to `12.5260688117`(25 stops of dynamic range) and I-D65 white point. - `AgX False Color` A heat-map-like imagery derived from `AgX`'s formed image. uses BT.2020's CIE 2012 luminance for luminance coefficients evaluation. **False Color ranges** Different from False Color in current Blender or the Filmic-Blender config, the false color here is a post-formation closed domain evaluation. Therefore, all values below will be linearized 0 to 1 value written in percentage. | [0.0, 1.0] Closed Domain Linear | Color | | ---- | ---- | Low Clip | Black | | 0.0001% to 0.05% | Blue | | 0.05% to 0.5% | Blue-Cyan | | 0.5% to 5% | Cyan | | 5% to 16% | Green-Cyan | | 16% to 22% | Grey | | 22% to 35% | Green-Yellow | | 35% to 55% | Yellow | | 55% to 80% | Orange | | 80% to 97% | Red | | High Clip | White | ![ea6deefe57f43e8684b6be27e3964fae_d676374d-3b8b-4e65-b048-5a17fd083a7f](/attachments/305fa0b3-cccd-4742-8664-05a3928575f6) **Looks** "Looks" are artistic adjustment to the image formation chain. - `Punchy` A contrast look that makes the image look more “punchy” by darkening the image. - `Greyscale` Turn the image into greyscale. Luminance coefficients are BT.2020’s CIE 2012 values, evaluated in Linear state. - Seven Contrast Looks. Similar to Filmic’s contrast looks. All operates in AgX Log, with pivot set in 0.18 middle grey. All using OCIO v2’s `Grading Primary Transform` feature, meaning you can customize your contrast just by editing the values in the config. **Colorimetric Information** - `Reference` Every OCIO config has their own reference space, all other spaces are defined with how they transform “from” and/or “to” the reference space. While Blender’s previous config has been using `Linear BT.709 I-D65` as reference, this config uses `1931 CIE XYZ E white point chromaticity` as reference. This is a sane decision, since CIE XYZ is the root for everything else color management related. FilmLight’s TCAMv2 config also has CIE XYZ as reference. - `AgX Base image formation space` The AgX in this config has one single image formed in the BT.2020 display medium, then the images for other mediums are produced from the formed image in BT.2020. - Supported Image Display Mediums: - `sRGB`, Generic sRGB / REC.709 displays with 2.2 native power function - `BT.1886`, Generic sRGB / REC.709 displays with 2.4 native power function - `Display P3` P3 displays with 2.2 native power function. Examples include: Apple MacBook Pros from 2016 on. Apple iMac Pros. Apple iMac from late 2015 on. - `BT.2020`BT.2020 displays with 2.4 native power function. It's very unlikely someone would use a BT.2020 2.4 display as of now, but since we have the image formed in BT.2020, supporting it is just a "why not?" thing to do. - `Colorspaces` This config supports the following colorspaces: - `Linear CIE-XYZ I-E` This is the standard 1931 CIE chromaticity standard used as reference. - `Linear CIE-XYZ I-D65` This is the chromatic-adaptated to I-D65 version of the XYZ chromaticity. Method used is `Bradford` - `Linear BT.709 I-E` Open Domain Linear BT.709 Tristimulus with I-E white point - `Linear BT.709 I-D65` Open Domain Linear BT.709 Tristimulus with I-D65 white point - `Linear DCI-P3 I-E` Open Domain Linear P3 Tristimulus with I-E white point - `Linear DCI-P3 I-D65` Open Domain Linear P3 Tristimulus with I-D65 white point - `Linear BT.2020 I-E` Open Domain Linear BT.2020 Tristimulus with I-E white point - `Linear BT.2020 I-D65` Open Domain Linear BT.2020 Tristimulus with I-D65 white point - `ACES2065-1` Open Domain AP0 Tristimulus with ACES white point - `ACEScg` Open Domain AP1 Tristimulus with ACES white point - `Linear E-Gamut I-D65` Open Domain Linear E Gamut Tristimulus with I-D65 white point - `sRGB ̶ ̶2̶.̶2̶` sRGB 2.2 Exponent Reference EOTF Display - `BT.1886 ̶ ̶2̶.̶4̶` BT.1886 2.4 Exponent EOTF Display - `Display P3 ̶ ̶2̶.̶2̶`Display P3 2.2 Exponent EOTF Display - `BT.2020 ̶ ̶2̶.̶4̶` BT.2020 2.4 Exponent EOTF Display - ̶`̶G̶e̶n̶e̶r̶i̶c̶ ̶D̶a̶t̶a̶`̶ `Non-Color` Generic data that is not color, will not apply any color transform Note: `I-E` is short for “Illuminant E”, `I-D65` is short for “Illuminant D65”. - The use of I-E white point The main reason for supporting the I-E version of the spaces is to be prepared for the upcoming Spectral Cycles. Spectral renderers with capability to input RGB textures require an I-E based RGB working space to ensure an error-free spectral reconstruction/upsampling process. Note for using Eary’s AgX for Spectral Cycles: Remember to change the XYZ role to the I-E version of the XYZ chromaticity.
Zijun Zhou added 28 commits 2023-03-31 04:53:02 +02:00
8bd63ae47b revert 610788d62b
revert Upload AgX
Zijun Zhou requested review from Brecht Van Lommel 2023-03-31 05:11:22 +02:00
Zijun Zhou requested review from Sergey Sharybin 2023-03-31 05:12:52 +02:00
Zijun Zhou added 1 commit 2023-03-31 10:06:28 +02:00

Thanks, AgX looks great.

Filmic should still be included in the default Blender config for backwards compatibility, even if only supported for the sRGB display.

Color space names like "Non-Color" and "sRGB", and view names like "Standard" should not be changed. It can be debated what the right name is, but I don't see a reason to move to another naming convention, especially if that convention is different than other applications or the new standard OCIO configs.

Thanks, AgX looks great. Filmic should still be included in the default Blender config for backwards compatibility, even if only supported for the sRGB display. Color space names like "Non-Color" and "sRGB", and view names like "Standard" should not be changed. It can be debated what the right name is, but I don't see a reason to move to another naming convention, especially if that convention is different than other applications or the new standard OCIO configs.
Author
Contributor

Filmic should still be included in the default Blender config for backwards compatibility, even if only supported for the sRGB display.

Filmic sRGB the space is still there, but my concern is people might use Filmic view with AgX looks, they shouldn't be used together, so I only included the space, but not listing it in the views.

Color space names like "Non-Color" and "sRGB" should not be changed. It can be debated what the right name is, but I don't see a reason to move to another naming convention, especially if that convention is different than other applications or the new standard OCIO configs.

Legacy names are in aliases so backwards compatibility should be good. Non-Color has been one of the most misunderstood colorspace names, many people actually believe "Non-Color" means black and white textures. Generic Data actually states what it is, the space has isdata: true, and has been referenced that way in the python API as data as well.

Example would be in node wrangler:
image

It's the good chance to get rid of unclear and easy-to-misunderstand names.

As for sRGB 2.2, the reasoning is to make it clear that we are not using the piece-wise sRGB that curshes shadows for legacy CRT displays, and instead using the power function for the modern style color management. But this one I am fine to change back to sRGB if you insist.

> Filmic should still be included in the default Blender config for backwards compatibility, even if only supported for the sRGB display. `Filmic sRGB` the space is still there, but my concern is people might use Filmic view with AgX looks, they shouldn't be used together, so I only included the space, but not listing it in the views. > Color space names like "Non-Color" and "sRGB" should not be changed. It can be debated what the right name is, but I don't see a reason to move to another naming convention, especially if that convention is different than other applications or the new standard OCIO configs. Legacy names are in aliases so backwards compatibility should be good. `Non-Color` has been one of the most misunderstood colorspace names, many people actually believe "Non-Color" means black and white textures. `Generic Data` actually states what it is, the space has `isdata: true`, and has been referenced that way in the python API as data as well. Example would be in node wrangler: ![image](/attachments/e1b82133-043f-4bc7-94de-4a2e558bac2a) It's the good chance to get rid of unclear and easy-to-misunderstand names. As for `sRGB 2.2`, the reasoning is to make it clear that we are not using the piece-wise sRGB that curshes shadows for legacy CRT displays, and instead using the power function for the modern style color management. But this one I am fine to change back to sRGB if you insist.
Zijun Zhou added 1 commit 2023-03-31 11:39:38 +02:00
Author
Contributor

I have removed the power value number from names like sRGB, Display P3, etc. But for Generic Data, I am unwilling to change it, reasoning has been stated above.

I have removed the power value number from names like sRGB, Display P3, etc. But for `Generic Data`, I am unwilling to change it, reasoning has been stated above.

Filmic must remain available as a view transform still for there to be backwards compatibility. Maybe something needs to be done to ensure looks are only available for appropriate view transforms.

I understand there are arguments for everything to be named one way or the other. But we have naming conventions and guidelines in Blender that should be followed, and that are not up for debate now. Color space debates tend to be very time consuming and I don't want to do that.

The convention is that we should name things by their purpose or meaning for users and not their technical implementation. We should also follow industry standard names when possible. Therefore, "sRGB 2.2" is too technical and we should not invent a new term like "Generic Data". These are just two examples, all names in the configuration should be evaluated based on this.

Filmic must remain available as a view transform still for there to be backwards compatibility. Maybe something needs to be done to ensure looks are only available for appropriate view transforms. I understand there are arguments for everything to be named one way or the other. But we have naming conventions and guidelines in Blender that should be followed, and that are not up for debate now. Color space debates tend to be very time consuming and I don't want to do that. The convention is that we should name things by their purpose or meaning for users and not their technical implementation. We should also follow industry standard names when possible. Therefore, "sRGB 2.2" is too technical and we should not invent a new term like "Generic Data". These are just two examples, all names in the configuration should be evaluated based on this.

aces_interchange should be added to this configuration, and ideally cie_xyz_d65_interchange as well.

`aces_interchange` should be added to this configuration, and ideally `cie_xyz_d65_interchange` as well.
Author
Contributor

aces_interchange currently overwrites the XYZ role, causing problem for Spectral Cycles to access the XYZ I-E chromaticity. We can add it back after the XYZ chromaticity in the render engines is using XYZ role again.

`aces_interchange` currently overwrites the XYZ role, causing problem for Spectral Cycles to access the XYZ I-E chromaticity. We can add it back after the XYZ chromaticity in the render engines is using XYZ role again.

Render engines should use aces_interchange for determining XYZ chromaticity. Using the XYZ role was only done because there no standard OCIO role to determine this. But now there is and that's what should be used.

Render engines should use `aces_interchange` for determining XYZ chromaticity. Using the `XYZ` role was only done because there no standard OCIO role to determine this. But now there is and that's what should be used.
Author
Contributor

I still disagree but I can add it back. Note Spectral Cycles requires XYZ chromaticity with I-E white point, the current aces_interchange role doesn't deal with that. Keep in mind we might need to deal with that in the future.

I still disagree but I can add it back. Note Spectral Cycles requires XYZ chromaticity with I-E white point, the current `aces_interchange` role doesn't deal with that. Keep in mind we might need to deal with that in the future.
Zijun Zhou added 1 commit 2023-03-31 12:28:34 +02:00
Zijun Zhou added 1 commit 2023-03-31 12:34:15 +02:00
Zijun Zhou added 1 commit 2023-03-31 12:39:56 +02:00
Zijun Zhou added 1 commit 2023-03-31 12:55:01 +02:00
f6f0cf260e Reintroduce View name `Standard` back as requested
I don't quite like the name but it is requested
Author
Contributor

I believe I have addressed all the comments.

I believe I have addressed all the comments.
Zijun Zhou added 1 commit 2023-03-31 13:35:18 +02:00
First-time contributor

Maybe something needs to be done to ensure looks are only available for appropriate view transforms.

This would be a very welcome change.

For now though, since that is not yet avaliable, should the Looks be named such that it's obvious what they connect to? So for instance

"Very High Contrast - Filmic"
"Very High Contrast - AgX"

or perhaps the reverse

"Filmic - Very High Contast"
"AgX - Very High Contrast"

Otherwise, if both AgX and Filmic are there, it's gonna be difficult to differentiate which Looks to pick

> Maybe something needs to be done to ensure looks are only available for appropriate view transforms. This would be a very welcome change. For now though, since that is not yet avaliable, should the Looks be named such that it's obvious what they connect to? So for instance "Very High Contrast - Filmic" "Very High Contrast - AgX" or perhaps the reverse "Filmic - Very High Contast" "AgX - Very High Contrast" Otherwise, if both AgX and Filmic are there, it's gonna be difficult to differentiate which Looks to pick
Author
Contributor

The current config does not have Filmic looks in there, if you want to go down that route, you need to make sure all other views can still use those looks but for Filmic, the looks are empty. But from another angle, you can still use those Looks with Filmic, just keep in mind those looks were not designed with Filmic in mind therefore the High contrast look + Filmic is not going to look the same as it is in Blender 3.5.

Looks are artistic adjustments anyways, it's not as strict nor as technical.

The current config does not have Filmic looks in there, if you want to go down that route, you need to make sure all other views can still use those looks but for Filmic, the looks are empty. But from another angle, you can still use those Looks with Filmic, just keep in mind those looks were not designed with Filmic in mind therefore the High contrast look + Filmic is not going to look the same as it is in Blender 3.5. Looks are artistic adjustments anyways, it's not as strict nor as technical.

The Filmic looks are needed for backwards compatibility. We also can't just change their name to add - Filmic since that breaks compatibility too. So some solution in the code is needed.

The Filmic looks are needed for backwards compatibility. We also can't just change their name to add `- Filmic` since that breaks compatibility too. So some solution in the code is needed.
First-time contributor

I've tested the version of AgX you published on your Github, and found a couple issues/regressions.

Main issues I've found are with picking colors.
For example inputting an RGB of 1.0, 0.0, 0.0 results in #FF150B, and inputting #FF0000 sets the RGB to 0.887905, 0.0, 0.0 as well as immediately changes the hex value. This doesn't occur in either Standard or Filmic in the "Vanilla" configuration.
Additionally while using Guard Rail, shadeless materials (emission shader with strength set to 1.0) do not display the actual color, as evident from color picking giving a slightly different value. This also didn't happen in Standard view transform in Vanilla.

Please let me know if this is intended/by design, and if so, how one can work around it. I can see this as a major issue for people who do flat graphics and video editing.

I've tested the version of AgX you published on your Github, and found a couple issues/regressions. Main issues I've found are with picking colors. For example inputting an RGB of 1.0, 0.0, 0.0 results in #FF150B, and inputting #FF0000 sets the RGB to 0.887905, 0.0, 0.0 as well as immediately changes the hex value. This doesn't occur in either Standard or Filmic in the "Vanilla" configuration. Additionally while using Guard Rail, shadeless materials (emission shader with strength set to 1.0) do not display the actual color, as evident from color picking giving a slightly different value. This also didn't happen in Standard view transform in Vanilla. Please let me know if this is intended/by design, and if so, how one can work around it. I can see this as a major issue for people who do flat graphics and video editing.
Author
Contributor

For example inputting an RGB of 1.0, 0.0, 0.0 results in #FF150B, and inputting #FF0000 sets the RGB to 0.887905, 0.0, 0.0 as well as immediately changes the hex value. This doesn't occur in either Standard or Filmic in the "Vanilla" configuration.

HEX values are not robust and universal, but rather the opposite, it's the enemy of proper color management, it's colorspace-unaware and does not tie to the root XYZ chromaticity. It's a bad idea to assume a HEX code holds some universal meaning across every software, because they don't.

Additionally while using Guard Rail, shadeless materials (emission shader with strength set to 1.0) do not display the actual color, as evident from color picking giving a slightly different value. This also didn't happen in Standard view transform in Vanilla.

It's designed to be almost the same, it can be a little bit different for two reasons, 1. the current working space is I-E based, for preparation for Spectral Cycles, therefore the output result would be adaptated to I-D65 for the display device. 2. Can be because of LUT precision. Though it's still there, I have tried my best to minimize the LUT precision issue, I reckon people won't really see the difference, like between 1.0 and 0.99 by eyeballing.

I can assure you the difference is small enough:
image
image

> For example inputting an RGB of 1.0, 0.0, 0.0 results in #FF150B, and inputting #FF0000 sets the RGB to 0.887905, 0.0, 0.0 as well as immediately changes the hex value. This doesn't occur in either Standard or Filmic in the "Vanilla" configuration. HEX values are not robust and universal, but rather the opposite, it's the enemy of proper color management, it's colorspace-unaware and does not tie to the root XYZ chromaticity. It's a bad idea to assume a HEX code holds some universal meaning across every software, because they don't. > Additionally while using Guard Rail, shadeless materials (emission shader with strength set to 1.0) do not display the actual color, as evident from color picking giving a slightly different value. This also didn't happen in Standard view transform in Vanilla. It's designed to be almost the same, it can be a little bit different for two reasons, 1. the current working space is I-E based, for preparation for Spectral Cycles, therefore the output result would be adaptated to I-D65 for the display device. 2. Can be because of LUT precision. Though it's still there, I have tried my best to minimize the LUT precision issue, I reckon people won't really see the difference, like between `1.0` and `0.99` by eyeballing. I can assure you the difference is small enough: ![image](/attachments/602e3ef3-817a-4871-9184-32f545af3658) ![image](/attachments/a369ba51-6064-4c32-98c3-34e3057390b1)
230 KiB
292 KiB
Author
Contributor

The Filmic looks are needed for backwards compatibility. We also can't just change their name to add - Filmic since that breaks compatibility too. So some solution in the code is needed.

I remember we have a hack back when Filmic was first introduced, adding Filmic - in front of the look name would make the look only appear when choosing Filmic. Maybe we can use that trick to bring back Filmic looks first, and then specified in the code to only show looks with Filmic - in front when choosing Filmic, so AgX looks won't appear when choosing Filmic?

> The Filmic looks are needed for backwards compatibility. We also can't just change their name to add `- Filmic` since that breaks compatibility too. So some solution in the code is needed. I remember we have a hack back when Filmic was first introduced, adding `Filmic - ` in front of the look name would make the look only appear when choosing Filmic. Maybe we can use that trick to bring back Filmic looks first, and then specified in the code to only show looks with `Filmic - ` in front when choosing Filmic, so AgX looks won't appear when choosing Filmic?
Zijun Zhou added 1 commit 2023-04-01 07:16:57 +02:00
Zijun Zhou added 1 commit 2023-04-01 07:18:37 +02:00
Zijun Zhou added 1 commit 2023-04-01 07:20:54 +02:00
Zijun Zhou added 1 commit 2023-04-01 07:21:40 +02:00
Zijun Zhou added 1 commit 2023-04-01 07:25:16 +02:00
Zijun Zhou added 1 commit 2023-04-01 07:25:46 +02:00
Zijun Zhou added 1 commit 2023-04-01 07:26:11 +02:00
Zijun Zhou added 1 commit 2023-04-01 07:27:42 +02:00
Author
Contributor

I added back the Filmic Look LUTs, but not in the config yet. Will wait until the code specifies to only show looks with Filmic - in front when choosing Filmic.

I added back the Filmic Look LUTs, but not in the config yet. Will wait until the code specifies to only show looks with `Filmic - ` in front when choosing Filmic.

HEX values are not robust and universal, but rather the opposite, it's the enemy of proper color management, it's colorspace-unaware and does not tie to the root XYZ chromaticity. It's a bad idea to assume a HEX code holds some universal meaning across every software, because they don't.

Hex values in Blender should be sRGB. It doesn't mean every application necessarily interprets it that way, but it has a well defined meaning in Blender and should work as before.

It's designed to be almost the same, it can be a little bit different for two reasons, 1. the current working space is I-E based, for preparation for Spectral Cycles, therefore the output result would be adaptated to I-D65 for the display device. 2. Can be because of LUT precision. Though it's still there, I have tried my best to minimize the LUT precision issue, I reckon people won't really see the difference, like between 1.0 and 0.99 by eyeballing.

I can assure you the difference is small enough:

Video editing should not be compromised by future plans for spectral rendering. It's not enough for the difference to be small enough that a visual inspection doesn't make it clear, there should not be subtle data loss in unexpected places at all. There can be some error from floating point precision, but 0.01 is too much.

To take full advantage of spectral rendering a wider gamut is needed anyway. I don't think we should switch this one to be I-E based if it causes such issues.

> HEX values are not robust and universal, but rather the opposite, it's the enemy of proper color management, it's colorspace-unaware and does not tie to the root XYZ chromaticity. It's a bad idea to assume a HEX code holds some universal meaning across every software, because they don't. Hex values in Blender should be sRGB. It doesn't mean every application necessarily interprets it that way, but it has a well defined meaning in Blender and should work as before. > It's designed to be almost the same, it can be a little bit different for two reasons, 1. the current working space is I-E based, for preparation for Spectral Cycles, therefore the output result would be adaptated to I-D65 for the display device. 2. Can be because of LUT precision. Though it's still there, I have tried my best to minimize the LUT precision issue, I reckon people won't really see the difference, like between `1.0` and `0.99` by eyeballing. > > I can assure you the difference is small enough: Video editing should not be compromised by future plans for spectral rendering. It's not enough for the difference to be small enough that a visual inspection doesn't make it clear, there should not be subtle data loss in unexpected places at all. There can be some error from floating point precision, but 0.01 is too much. To take full advantage of spectral rendering a wider gamut is needed anyway. I don't think we should switch this one to be I-E based if it causes such issues.
Author
Contributor

To take full advantage of spectral rendering a wider gamut is needed anyway. I don't think we should switch this one to be I-E based if it causes such issues.

I am sure none of these use cases will be negatively affected by the I-E working space. It's just the nature of any different working space, you can't expect the open domain scene-linear value to be exactly what the view tranform outputs. Let's say ACEScg as working space, it has a non-CIE standard weirdly decided white point (it's not D60) with primaries no monitor can produce, no view transform can output 1:1 the value. Users just need to understand that open-doamin scene-linear value 1:1 output as a view transform is not what we are looking for.

As far as replacing "Standard", the current Guard Rail will do the job. Guard Rail does not replace the technical sRGB conversion, it only replaces the view transform, the image formation.

> To take full advantage of spectral rendering a wider gamut is needed anyway. I don't think we should switch this one to be I-E based if it causes such issues. I am sure none of these use cases will be negatively affected by the I-E working space. It's just the nature of any different working space, you can't expect the open domain scene-linear value to be exactly what the view tranform outputs. Let's say ACEScg as working space, it has a non-CIE standard weirdly decided white point (it's not D60) with primaries no monitor can produce, no view transform can output 1:1 the value. Users just need to understand that open-doamin scene-linear value 1:1 output as a view transform is not what we are looking for. As far as replacing "Standard", the current Guard Rail will do the job. Guard Rail does not replace the technical sRGB conversion, it only replaces the view transform, the image formation.

Realistic rendering is not the only use case for Blender. If for example #FF0000 sets the RGB to 0.887905, 0.0, 0.0 that is a negative for important use cases.

We can add additional view transform, displays and color spaces now. However changing the working space is not something we can do without user control.

Realistic rendering is not the only use case for Blender. If for example #FF0000 sets the RGB to 0.887905, 0.0, 0.0 that is a negative for important use cases. We can add additional view transform, displays and color spaces now. However changing the working space is not something we can do without user control.
Author
Contributor

OK I can change the working space back to I-D65 for now. But note for Spectral Cycles, I-E working space is an absolute must, we are just delaying the decision to when Spectral Cycles's turn comes.

OK I can change the working space back to I-D65 for now. But note for Spectral Cycles, I-E working space is an absolute must, we are just delaying the decision to when Spectral Cycles's turn comes.
Zijun Zhou added 1 commit 2023-04-01 10:05:15 +02:00
Zijun Zhou added 1 commit 2023-04-01 12:55:04 +02:00
First-time contributor

But note for Spectral Cycles, I-E working space is an absolute must, we are just delaying the decision to when Spectral Cycles's turn comes.

It feels like that just letting the user switch between spaces (or maybe automatically do it when switching to spectral mode, when that gets implemented?) seems like the obvious solution. Is there something that makes that hard to implement?

> But note for Spectral Cycles, I-E working space is an absolute must, we are just delaying the decision to when Spectral Cycles's turn comes. It feels like that just letting the user switch between spaces (or maybe automatically do it when switching to spectral mode, when that gets implemented?) seems like the obvious solution. Is there something that makes that hard to implement?
First-time contributor

It's been said that:

As far as replacing "Standard", the current Guard Rail will do the job. Guard Rail does not replace the technical sRGB conversion, it only replaces the view transform, the image formation.

@xZaki raised some concerns about this, but there's no data from a real-world NPR workflow on this PR yet. I've done some quick testing on this image, made in Blender using emissive shaders on grease pencil and mesh:
Honeyview_full_front_face.png

(Note that it's been heavily compressed for upload). I sampled the values of the skin tone, the dress, the earring metal, and the earring highlight both with Standard and with the proposed Guard Rail, using an external (non-Blender) color picker.

Standard Guard Rail
Skin #9E5B4A #A25C4C
Dress #130F10 #141011
Earring Metal #666666 #666666
Earring Highlight #FBFEFF #F9FBFE

In every case except pure gray, Guard Rail causes significant changes to the color data.

It's been said that: > As far as replacing "Standard", the current Guard Rail will do the job. Guard Rail does not replace the technical sRGB conversion, it only replaces the view transform, the image formation. @xZaki raised some concerns about this, but there's no data from a real-world NPR workflow on this PR yet. I've done some quick testing on this image, made in Blender using emissive shaders on grease pencil and mesh: ![Honeyview_full_front_face.png](/attachments/669c6dd8-2755-4e3c-88d8-1cd6e5d75b96) (Note that it's been heavily compressed for upload). I sampled the values of the skin tone, the dress, the earring metal, and the earring highlight both with Standard and with the proposed Guard Rail, using an external (non-Blender) color picker. | | Standard | Guard Rail | | -------- | -------- | -------- | | Skin | #9E5B4A | #A25C4C | | Dress | #130F10 | #141011 | | Earring Metal | #666666 | #666666 | | Earring Highlight | #FBFEFF | #F9FBFE | In every case except pure gray, Guard Rail causes significant changes to the color data.
Author
Contributor

Again, the goal of view transform is not technical sRGB conversion, it's instead, image formation. Therefore as long as visually extremely similar, it's acceptable.

Guard Rail is not meant to replace the technical sRGB conversion. I'll say it again. That's why I hide Guard Rail from the colorspace list.

Technically it's completely impossible to have the 3D LUT completely not changing anythying, I just tried to increase the 3D LUT resolution to 129 (max resolution Blender supports, file size 63.4 MB) and it still wouldn't work like that. Even though I already set a "bypass if within [0, 1]" in the python script, the generated 3D LUT just wouldn't completely unchange the color, it's just impossible due to 3D LUT precision. It would work if I could set the "bypass the LUT if within [0, 1]" within the config instead of the python LUT generator, but sadly OCIO doesn't have this feature.

The inclusion of the "Standard" view transform has actually never been a standard practice, in fact, none of the ACES configs has it, TCAMv2 config doesn't have it. It's existance should not be taken as a technical sRGB conversion.

Again, think of a BT.2020 or ACEScg working space, in former's case you can only see the straight output in an HDR projector, in latter's case you will never be able to see a straight output. The function a view transform takes has never been "keep the color data unchanged"

At this rate, if you just want a simple sRGB conversion, doing it in compositor or using the Gamma of 2.2 setting with view set to none might be a better choice, though expect the latter solution to break when we eventually change the working space to something else. It's fine for now as the working space has been set to Linear BT.709 I-D65.

And be aware my GitHub version is still using I-E working space. Use the version in this PR if you want the I-D65 working space.

Again, the goal of view transform is not technical sRGB conversion, it's instead, image formation. Therefore as long as visually extremely similar, it's acceptable. Guard Rail is not meant to replace the technical sRGB conversion. I'll say it again. That's why I hide Guard Rail from the colorspace list. Technically it's completely impossible to have the 3D LUT completely not changing anythying, I just tried to increase the 3D LUT resolution to 129 (max resolution Blender supports, file size 63.4 MB) and it still wouldn't work like that. Even though I already set a "bypass if within [0, 1]" in the python script, the generated 3D LUT just wouldn't completely unchange the color, it's just impossible due to 3D LUT precision. It would work if I could set the "bypass the LUT if within [0, 1]" within the config instead of the python LUT generator, but sadly OCIO doesn't have this feature. The inclusion of the "Standard" view transform has actually never been a standard practice, in fact, none of the ACES configs has it, TCAMv2 config doesn't have it. It's existance should not be taken as a technical sRGB conversion. Again, think of a BT.2020 or ACEScg working space, in former's case you can only see the straight output in an HDR projector, in latter's case you will never be able to see a straight output. The function a view transform takes has never been "keep the color data unchanged" At this rate, if you just want a simple sRGB conversion, doing it in compositor or using the `Gamma` of 2.2 setting with view set to none might be a better choice, though expect the latter solution to break when we eventually change the working space to something else. It's fine for now as the working space has been set to Linear BT.709 I-D65. And be aware my GitHub version is still using I-E working space. Use the version in this PR if you want the I-D65 working space.
First-time contributor

Therefore as long as visually extremely similar, it's acceptable.

Not for all use cases. The United Way, for example, has a zero tolerance policy for hex color deviations, and they color check every graphic. This PR makes Blender unusable for any case involving this organization, and that's just the one I am aware of.

> Therefore as long as visually extremely similar, it's acceptable. Not for all use cases. The United Way, for example, has a zero tolerance policy for hex color deviations, and they color check every graphic. This PR makes Blender unusable for any case involving this organization, and that's just the one I am aware of.
Zijun Zhou added 1 commit 2023-04-02 01:54:19 +02:00
c78263eac6 Add `Legacy Standard`
Not a good idea in my opinion, but people are complaining it's absence.
Author
Contributor

Ok I added the sRGB display's native back as Legacy Standard. Design-wise I am not comfortable with this decision. I hope the community in the long run can get rid of the out-dated practice of using sRGB inverse EOTF as view transform. Guard Rail is a step forward in this sense.

Ok I added the sRGB display's native back as `Legacy Standard`. Design-wise I am not comfortable with this decision. I hope the community in the long run can get rid of the out-dated practice of using sRGB inverse EOTF as view transform. Guard Rail is a step forward in this sense.
Zijun Zhou added 1 commit 2023-04-02 06:44:29 +02:00
58e7d134c8 Modify Bypass range of Guard Rail sRGB for better precision of valid values
Trying a bit hacky approach, leaving in a little bit of negative and higher-than-1.0 values, though violates Guard Rail's design principal, it does improve the valid values' precision.
Zijun Zhou added 1 commit 2023-04-02 06:50:21 +02:00
fecdf7f96b revert `Modify Bypass range of Guard Rail sRGB`, that commit causes clippings in wider gamut render
revert Modify Bypass range of Guard Rail sRGB for better precision of valid values

Trying a bit hacky approach, leaving in a little bit of negative and higher-than-1.0 values, though violates Guard Rail's design principal, it does improve the valid values' precision.
Zijun Zhou added 1 commit 2023-04-02 07:25:21 +02:00
aeccba9f69 Implement hack in config to compensate for purity lost due to Guard Rail LUT's precision
Using a hack in Guard Rail, use CDL sat to bring back a bit of purity, this causes wider gamut render to be a bit less smooth but the degree is acceptable. Might remove this hack in the future if better approach comes or when the community cares less about "looking exactly like display's native".
Author
Contributor

I just added a hack to compensate for Guard Rail sRGB's chroma lost from LUT precision. Plus added back the Legacy Standard, the issue reguarding that should be over now.

I just added a hack to compensate for Guard Rail sRGB's chroma lost from LUT precision. Plus added back the `Legacy Standard`, the issue reguarding that should be over now.
Zijun Zhou added 1 commit 2023-04-02 07:43:24 +02:00

It's not clear to me what Guard Rail does and what its purpose is, the name or description does not make it clear to me.

The main use cases we need to cover are:

  • Realistic rendering
  • Non-photorealistic rendering and grease pencil
  • Video editing

In which use cases would you recommend using it, and to achieve which goal?

Renaming Standard to Legacy Standard breaks compatibility. And I don't think calling it "legacy" is good because I think it's a legitimate to want to pass colors through Blender unchanged. The reason it was called "standard" is because it does exactly the standard EOTF and nothing else.

It's not clear to me what Guard Rail does and what its purpose is, the name or description does not make it clear to me. The main use cases we need to cover are: * Realistic rendering * Non-photorealistic rendering and grease pencil * Video editing In which use cases would you recommend using it, and to achieve which goal? Renaming Standard to Legacy Standard breaks compatibility. And I don't think calling it "legacy" is good because I think it's a legitimate to want to pass colors through Blender unchanged. The reason it was called "standard" is because it does exactly the standard EOTF and nothing else.
Zijun Zhou added 1 commit 2023-04-02 10:07:41 +02:00

Again, the goal of view transform is not technical sRGB conversion, it's instead, image formation. Therefore as long as visually extremely similar, it's acceptable.

According to wikipedia, the study of image formation encompasses the radiometric and geometric processes by which 2D images of 3D objects are formed.

That is not the only purpose of view transforms and color management in Blender. You also want to be able to take as input an image that has already been formed or that never was based on 3D objects to begin with, edit it, and then output it to the same or another display device without changing the look in any way.

> Again, the goal of view transform is not technical sRGB conversion, it's instead, image formation. Therefore as long as visually extremely similar, it's acceptable. [According to wikipedia](https://en.wikipedia.org/wiki/Image_formation), the study of image formation encompasses the radiometric and geometric processes by which 2D images of 3D objects are formed. That is not the only purpose of view transforms and color management in Blender. You also want to be able to take as input an image that has already been formed or that never was based on 3D objects to begin with, edit it, and then output it to the same or another display device without changing the look in any way.
Author
Contributor

It's not clear to me what Guard Rail does and what its purpose is, the name or description does not make it clear to me.

Guard Rail's design principal is to keep the valid range of [0.0, 1.0] completely the same as "Standard", and deal with out-of-display-range values gracefully. Therefore in theory, in our original design, it would have been a perfect replacement for "Standard", it's supposed to be the "Standard" that does not produce the Notorious Six.

Guard Rail is part of AgX, in that AgX's BT.2020 version needs to go through the "negative handling" part of Guard Rail before going through the sigmoid, and then the sRGB version of AgX is produced from the BT.2020 version going through sRGB's Guard Rail. Guard Rail is our tool to deal with out-of-display-range values.

The problem though, as I explained, is that 3D LUT doesn't take in a value and output it like nothing happened, although our color processing in python script did have [0.0, 1.0] range completely the same as "Standard", when we produced a 3D LUT from it, the LUT precision is shifting the color just a little bit. Visually the difference is small enough for most cases to be ignored, but for people using color pickers and compare the HEX code, it's surely different.

I compromised now, I renamed Legacy Standard back to Standard, and Guard Rail back to Guard Rail.

I would still say, for people that stopped using Filmic because of it's "too grey", try Guard Rail out, you may like it.

Guard_Rail_Sweep

> It's not clear to me what Guard Rail does and what its purpose is, the name or description does not make it clear to me. Guard Rail's design principal is to keep the valid range of [0.0, 1.0] completely the same as "Standard", and deal with out-of-display-range values gracefully. Therefore in theory, in our original design, it would have been a perfect replacement for "Standard", it's supposed to be the "Standard" that does not produce the Notorious Six. Guard Rail is part of AgX, in that AgX's BT.2020 version needs to go through the "negative handling" part of Guard Rail before going through the sigmoid, and then the sRGB version of AgX is produced from the BT.2020 version going through sRGB's Guard Rail. Guard Rail is our tool to deal with out-of-display-range values. The problem though, as I explained, is that 3D LUT doesn't take in a value and output it like nothing happened, although our color processing in python script did have [0.0, 1.0] range completely the same as "Standard", when we produced a 3D LUT from it, the LUT precision is shifting the color just a little bit. Visually the difference is small enough for most cases to be ignored, but for people using color pickers and compare the HEX code, it's surely different. I compromised now, I renamed `Legacy Standard` back to `Standard`, and Guard Rail back to `Guard Rail`. I would still say, for people that stopped using Filmic because of it's "too grey", try Guard Rail out, you may like it. ![Guard_Rail_Sweep](/attachments/41d0be40-789e-4c88-a39a-24cb47f49911)

I don't understand how it can be both exactly the same as standard in the [0.0, 1.0] range, and still give significantly different Hex colors which are always within the [0.0, 1.0] range.

Unless that was all explained by the I-E and I-D65 difference and the Guard Rail in this config does exactly give the same Hex color (or maybe off by one bit due to some precision issue).

If so we may only need one, or consider making Guard Rail the default in the grease pencil template.

I don't understand how it can be both exactly the same as standard in the [0.0, 1.0] range, and still give significantly different Hex colors which are always within the [0.0, 1.0] range. Unless that was all explained by the I-E and I-D65 difference and the Guard Rail in this config does exactly give the same Hex color (or maybe off by one bit due to some precision issue). If so we may only need one, or consider making Guard Rail the default in the grease pencil template.
Author
Contributor

I don't understand how it can be both exactly the same as standard in the [0.0, 1.0] range, and still give significantly different Hex colors which are always within the [0.0, 1.0] range.

Again, it's because of 3D LUT precision. If there is a way we can implement it algorithmically instead of using a baked 3D LUT, it would be exactly the same. But for now we can only use the LUT.

But it would still be a valid option as view transform, especially those people in DevTalk saying their renders are ruined by Filmic "greying out". AgX uses the same kind of sigmoid so it would still "grey it out", Guard Rail would be a good option for them.

or consider making Guard Rail the default in the grease pencil template.

This is a good idea actually, especially as GP can be influenced by lighting and get values above 1.0. Or the future potential of wider gamut painting? Guard Rail also deals with wider gamut gracefully.

> I don't understand how it can be both exactly the same as standard in the [0.0, 1.0] range, and still give significantly different Hex colors which are always within the [0.0, 1.0] range. Again, it's because of 3D LUT precision. If there is a way we can implement it algorithmically instead of using a baked 3D LUT, it would be exactly the same. But for now we can only use the LUT. But it would still be a valid option as view transform, especially those people in DevTalk saying their renders are ruined by Filmic "greying out". AgX uses the same kind of sigmoid so it would still "grey it out", Guard Rail would be a good option for them. > or consider making Guard Rail the default in the grease pencil template. This is a good idea actually, especially as GP can be influenced by lighting and get values above 1.0. Or the future potential of wider gamut painting? Guard Rail also deals with wider gamut gracefully.
Zijun Zhou added 1 commit 2023-04-02 12:13:54 +02:00
954d9e9eba revert 810a49c241 Made a mistake
revert Rename Guard Rail back to `Guard Rail` and `Legacy Standard` back to Standard
Zijun Zhou added 1 commit 2023-04-02 12:14:49 +02:00

If the only remaining difference is the 3D LUT precision, I imagine it's possible to improve the precision by factoring the EOTF out of the LUT. Or maybe doing a remapping before and after the LUT to allocate a bigger portion to the 0..1 range.

If the only remaining difference is the 3D LUT precision, I imagine it's possible to improve the precision by factoring the EOTF out of the LUT. Or maybe doing a remapping before and after the LUT to allocate a bigger portion to the 0..1 range.
Author
Contributor

The 2.2 EOTF is already out of the LUT. Remapping before and after the LUT is already there as well, I decided not to use the log 2 curve because people reported the log 2 curve caused a shift of 0.0 lower bound value due to precision. I am now using St.2084 10nits curve + 1.5 power curve, seem to work the best so far.

We also need the LUT input encoding to be rather wide gamut, especically include those negative luminance non-sense virtual values that real cameras tend to produce, therefore I used E-gamut. But larger input gamut also paid a toll on precision.

Will continue to investigate better options.

The 2.2 EOTF is already out of the LUT. Remapping before and after the LUT is already there as well, I decided not to use the log 2 curve because people reported the log 2 curve caused a shift of 0.0 lower bound value due to precision. I am now using St.2084 10nits curve + 1.5 power curve, seem to work the best so far. We also need the LUT input encoding to be rather wide gamut, especically include those negative luminance non-sense virtual values that real cameras tend to produce, therefore I used E-gamut. But larger input gamut also paid a toll on precision. Will continue to investigate better options.

It may be possible to align 0 and 1 exactly to grid vertices in the 3D LUT in such a way that values in that range get exactly linearly interpolated, making precision error very small.

It may be possible to align 0 and 1 exactly to grid vertices in the 3D LUT in such a way that values in that range get exactly linearly interpolated, making precision error very small.
Zijun Zhou added 1 commit 2023-04-03 09:07:26 +02:00
Zijun Zhou added 1 commit 2023-04-03 09:09:56 +02:00
Zijun Zhou added 1 commit 2023-04-03 09:12:11 +02:00
Author
Contributor

I tried some method to minimize the precision error, now the error should be extremely small. Welcome testing.

Guard Rail sRGB

I tried some method to minimize the precision error, now the error should be extremely small. Welcome testing. ![Guard Rail sRGB](/attachments/47ad1361-942c-4972-8d68-6fb282b49a3c)
Author
Contributor

Tester has reported posterization in wider gamut after the matrix commit. Will revert it.

Tester has reported posterization in wider gamut after the matrix commit. Will revert it.
Zijun Zhou added 1 commit 2023-04-03 14:02:42 +02:00
a00316165a revert 83e5bd2a8f
revert Use matrix to minimize Guard Rail precision issue
Zijun Zhou added 1 commit 2023-04-27 04:33:05 +02:00
Zijun Zhou added 1 commit 2023-04-27 04:36:12 +02:00
Zijun Zhou added 1 commit 2023-04-27 04:38:00 +02:00
Zijun Zhou added 1 commit 2023-04-27 04:39:56 +02:00
Zijun Zhou added 1 commit 2023-04-27 04:41:06 +02:00
Zijun Zhou added 1 commit 2023-04-27 04:43:27 +02:00
Zijun Zhou added 1 commit 2023-04-27 04:44:21 +02:00
Zijun Zhou added 1 commit 2023-04-27 04:45:15 +02:00
c2deec50d3 Update config to use updated LUTs
The LUTs are updated in order to improve LUT precision
Zijun Zhou added 1 commit 2023-04-27 04:52:49 +02:00
Author
Contributor

I updated the LUTs to improve the LUT precision.

I updated the LUTs to improve the LUT precision.
Zijun Zhou added 1 commit 2023-04-27 05:06:38 +02:00
Zijun Zhou added 1 commit 2023-04-27 05:07:19 +02:00
Zijun Zhou added 1 commit 2023-04-27 05:12:11 +02:00
First-time contributor

Trying out the new version (should've really uploaded it to your github, was a bit of a pain to download each file individually). Omitted the lowercase "luts" folder since Windows physically didn't let me make it in the same folder as LUTs.

Precision on Guard Rail has seemingly improved.
Standard while using the AgX config does is very slightly less precise than in Vanilla Blender, though that might be due to me being unable to replicate the config as the statement above.

Overall i do hope algorithmic LUTs can be attempted at some point as previously mentioned, but time for 3.6 is running short, and i do really hope AgX can still make it this release.

Trying out the new version (should've really uploaded it to your github, was a bit of a pain to download each file individually). Omitted the lowercase "luts" folder since Windows physically didn't let me make it in the same folder as LUTs. Precision on Guard Rail has seemingly improved. Standard while using the AgX config does is **very** slightly less precise than in Vanilla Blender, though that might be due to me being unable to replicate the config as the statement above. Overall i do hope algorithmic LUTs can be attempted at some point as previously mentioned, but time for 3.6 is running short, and i do really hope AgX can still make it this release.
Author
Contributor

Standard while using the AgX config does is very slightly less precise than in Vanilla Blender

It's not "less precise", I have already mentioned before but again, it's a design decision to:

As for sRGB 2.2, the reasoning is to make it clear that we are not using the piece-wise sRGB that curshes shadows for legacy CRT displays, and instead using the power function for the modern style color management.

If you use sRGB textures, the import export should be the inverse of the same function so there should be no change regarding that; If you are directly inputing the linear sRGB values, the end result you see on monitor is either:

  1. sRGB 2.2 values being displayed on piece-wise calibrated monitor, shadow gets a little tiny bit brighter

  2. sRGB 2.2 values being displayed 2.2 calibrated monitor, displayed as intended.

VS if we use piece-wise function:

  1. sRGB piece-wise value on being displayed on 2.2 calibrated monitor, resulting in shadows getting crushed. (was the ideal behavior in old-school CRT color management, but not anymore in modern color managment workflow)
  2. sRGB piece-wise value on being displayed on piece-wise calibrated monitor, properly displayed.

I remember Filmlight did a survey about whether people calibrate to 2.2 or piece-wise more, the result, IIRC, was that most people nowadays calibrated their monitors to pure power function, instead of piece-wise function.

Also, shadows looking a bit brighter seem to be a better risk to take than crushed shadows, it's also a risk that is less likely to happen since most people calibrate their monitors to pure power function.

but time for 3.6 is running short, and i do really hope AgX can still make it this release.

I believe I have done all I can do right now. If I am not mistaken, the only thing left is Filmic Looks. I have been waiting for the code change Brecht mentioned, since if I just do anything in config without code change, this would happen:
image
Both Filmic Looks and AgX Looks are present at the same time when choosing Filmic, which is confusing.

I think they need to just implement a "hide non-Filmic looks when using Filmic" or something, I remember the same thing being done to 2.79, not really sure though because nothing has been comfirmed to me yet regarding how they are trying to do this.

@brecht Am I correct on the plan regarding Filmic Looks?

> Standard while using the AgX config does is **very** slightly less precise than in Vanilla Blender It's not "less precise", I have already mentioned before but again, it's a design decision to: > As for sRGB 2.2, the reasoning is to make it clear that we are not using the piece-wise sRGB that curshes shadows for legacy CRT displays, and instead using the power function for the modern style color management. If you use sRGB textures, the import export should be the inverse of the same function so there should be no change regarding that; If you are directly inputing the linear sRGB values, the end result you see on monitor is either: 1. sRGB 2.2 values being displayed on piece-wise calibrated monitor, shadow gets a little tiny bit brighter 2. sRGB 2.2 values being displayed 2.2 calibrated monitor, displayed as intended. VS if we use piece-wise function: 1. sRGB piece-wise value on being displayed on 2.2 calibrated monitor, resulting in shadows getting crushed. (was the ideal behavior in old-school CRT color management, but not anymore in modern color managment workflow) 2. sRGB piece-wise value on being displayed on piece-wise calibrated monitor, properly displayed. I remember Filmlight did a survey about whether people calibrate to 2.2 or piece-wise more, the result, IIRC, was that most people nowadays calibrated their monitors to pure power function, instead of piece-wise function. Also, shadows looking a bit brighter seem to be a better risk to take than crushed shadows, it's also a risk that is less likely to happen since most people calibrate their monitors to pure power function. > but time for 3.6 is running short, and i do really hope AgX can still make it this release. I believe I have done all I can do right now. If I am not mistaken, the only thing left is Filmic Looks. I have been waiting for the code change Brecht mentioned, since if I just do anything in config without code change, this would happen: ![image](/attachments/1a4fd1ae-ccd6-415f-aab8-5106e49d4f16) Both Filmic Looks and AgX Looks are present at the same time when choosing Filmic, which is confusing. I think they need to just implement a "hide non-Filmic looks when using Filmic" or something, I remember the same thing being done to 2.79, not really sure though because nothing has been comfirmed to me yet regarding how they are trying to do this. @brecht Am I correct on the plan regarding Filmic Looks?
Zijun Zhou added 1 commit 2023-05-09 12:43:14 +02:00
Author
Contributor

Just for the record, AgX is perfectly ready in my view point, the only thing I am waiting for is the code change that Brecht mentioned, so that we can bring back Filmic Looks. After that, at least from my current understanding, we should be able to merge immediately, I have been modifying things according to requests all along, if Filmic Looks is not the only left, I don't know what we are waiting for.

Just for the record, AgX is perfectly ready in my view point, the only thing I am waiting for is the code change that Brecht mentioned, so that we can bring back Filmic Looks. After that, at least from my current understanding, we should be able to merge immediately, I have been modifying things according to requests all along, if Filmic Looks is not the only left, I don't know what we are waiting for.
Author
Contributor

Or if we can delay it to 4.0 or some version where we can drop some backwards campatibility, in that case we can just drop the support for Filmic Looks. It's not that the new contrast looks are going to be very very very different from Filmic's contrast looks anyways.

But I need comfirmation on the plan we are going towards.

Or if we can delay it to 4.0 or some version where we can drop some backwards campatibility, in that case we can just drop the support for Filmic Looks. It's not that the new contrast looks are going to be very very very different from Filmic's contrast looks anyways. But I need comfirmation on the plan we are going towards.
Zijun Zhou added 1 commit 2023-05-17 10:45:06 +02:00
Zijun Zhou added 1 commit 2023-05-17 10:54:52 +02:00
010df80284 Try resolving merge conflict
I don't see any buttom on the Gitea website to resolve it, trying to see if there is some other way to do it.
Zijun Zhou added 1 commit 2023-05-17 11:17:41 +02:00
Zijun Zhou added 1 commit 2023-05-17 12:52:50 +02:00
837ad59865 Redo startup file change after solving merge conflict
Set default startup view transform to AgX
First-time contributor

AgX False Color is completely posterized, unlike in vanilla Blender where it has a smooth transition. I assume this isn't intentional.
image image

AgX False Color is completely posterized, unlike in vanilla Blender where it has a smooth transition. I assume this isn't intentional. ![image](/attachments/e2189a68-0fb8-4f5a-800d-1fcc0e958221) ![image](/attachments/2f53e08a-1cac-4bf6-9c33-e858fe15830f)
Author
Contributor

It is actually intentional, the entire point of the false color in the first place is to posterize for better visualization of different zones.

The previous False Color Blender used was 3D LUT. The 3D LUT might create some smooth transition because of 3D LUT's precision issue. After changing to 1D LUT, the intentional posterization is more nicely kept, though you can still see some smoothness in the extremely low ranges.

It is actually intentional, the entire point of the false color in the first place is to posterize for better visualization of different zones. The previous False Color Blender used was 3D LUT. The 3D LUT might create some smooth transition because of 3D LUT's precision issue. After changing to 1D LUT, the intentional posterization is more nicely kept, though you can still see some smoothness in the extremely low ranges.
First-time contributor

@Eary AgX looks absolutely awesome!

Apart from that, given that False color in Blender still appears to be different from the Filmic master on GitHub #98405 shouldn't we also invite @troy_s to clear things up?

Otherwise I have to feeling that adding yet another View Transform is going to result in Color Management chaos for the average user, where to the already existing 2 versions of Filmic, there will be AgX which for most users will also look like some version of Filmic additionally .

@Eary AgX looks absolutely awesome! Apart from that, given that False color in Blender still appears to be different from the Filmic master on GitHub https://projects.blender.org/blender/blender/issues/98405 shouldn't we also invite @troy_s to clear things up? Otherwise I have to feeling that adding yet another View Transform is going to result in Color Management chaos for the average user, where to the already existing 2 versions of Filmic, there will be AgX which for most users will also look like some version of Filmic additionally .
Author
Contributor

I made AgX False Color completely from scratch, with our previous conversation about False Color in mind. Specifically, previous False Color has some problem with the luminance coefficients being evaluated in Log state, instead of Linear state, we also had talked about how it could have been just a 1D LUT.

And this is exactly what I did in AgX False Color, for reference, here is Filmic False Colour with Luminance Coefficients evaluated in Filmic Log:
Filmic_False_Colour.png

Here is AgX False Color done in post-formation Linear state:
AgX_False_Color.png

It is different from the Github's Filmic False Colour, but it makes more sense.

Otherwise I have to feeling that adding yet another View Transform is going to result in Color Management chaos for the average user, where to the already existing 2 versions of Filmic, there will be AgX which for most users will also look like some version of Filmic additionally .

FIlmic is there in the menu for backwards compatibilty concerns. Users are encouraged to use AgX once it's merged, unless their personal aesthetic taste somehow dislike AgX, I guess it's fine then.

I made AgX False Color completely from scratch, with our previous conversation about False Color in mind. Specifically, previous False Color has some problem with the luminance coefficients being evaluated in Log state, instead of Linear state, we also had talked about how it could have been just a 1D LUT. And this is exactly what I did in AgX False Color, for reference, here is Filmic False Colour with Luminance Coefficients evaluated in Filmic Log: ![Filmic_False_Colour.png](/attachments/e58c19db-aef6-4287-b601-20d1615b460f) Here is AgX False Color done in post-formation Linear state: ![AgX_False_Color.png](/attachments/d676374d-3b8b-4e65-b048-5a17fd083a7f) It is different from the Github's Filmic False Colour, but it makes more sense. > Otherwise I have to feeling that adding yet another View Transform is going to result in Color Management chaos for the average user, where to the already existing 2 versions of Filmic, there will be AgX which for most users will also look like some version of Filmic additionally . FIlmic is there in the menu for backwards compatibilty concerns. Users are encouraged to use AgX once it's merged, unless their personal aesthetic taste somehow dislike AgX, I guess it's fine then.
First-time contributor

Otherwise I have to feeling that adding yet another View Transform is going to result in Color Management chaos for the average user, where to the already existing 2 versions of Filmic, there will be AgX which for most users will also look like some version of Filmic additionally .

FIlmic is there in the menu for backwards compatibilty concerns. Users are encouraged to use AgX once it's merged, unless their personal aesthetic taste somehow dislike AgX, I guess it's fine then.

If chaos is a concern then maybe just hide Filmic by default under experimental as a toggle, like the Legacy Undo?

> > Otherwise I have to feeling that adding yet another View Transform is going to result in Color Management chaos for the average user, where to the already existing 2 versions of Filmic, there will be AgX which for most users will also look like some version of Filmic additionally . > > FIlmic is there in the menu for backwards compatibilty concerns. Users are encouraged to use AgX once it's merged, unless their personal aesthetic taste somehow dislike AgX, I guess it's fine then. If chaos is a concern then maybe just hide Filmic by default under experimental as a toggle, like the Legacy Undo?
Author
Contributor

Adding back Filmic to the view transform menu was requested by Brecht, I believe the idea is to have old .blend files being kept completely the same as before, to make it able to auto select Filmic upon opening old files.

Adding back Filmic to the view transform menu was requested by Brecht, I believe the idea is to have old .blend files being kept completely the same as before, to make it able to auto select Filmic upon opening old files.
First-time contributor

@Eary Personally I don't see a reason why Filmic should be removed. It works and is liked by many people, and sure AgX may have it's advantages over Filmic but some people may just prefer the look of AgX or Filmic.

So I think that simply adding AgX to the View Transforms is better than outright replacing Filmic. It's not like we've got that many options to choose from right now anyway.

@Eary Personally I don't see a reason why Filmic should be removed. It works and is liked by many people, and sure AgX may have it's advantages over Filmic but some people may just prefer the look of AgX or Filmic. So I think that simply adding AgX to the View Transforms is better than outright replacing Filmic. It's not like we've got that many options to choose from right now anyway.
First-time contributor

A while ago I stumbled upon Feedback / Development: Filmic, Baby Step to a V2? I take that this is the Pull Request relating to it?

A while ago I stumbled upon [Feedback / Development: Filmic, Baby Step to a V2?](https://blenderartists.org/t/feedback-development-filmic-baby-step-to-a-v2/1361663) I take that this is the Pull Request relating to it?
Author
Contributor

So I think that simply adding AgX to the View Transforms is better than outright replacing Filmic. It's not like we've got that many options to choose from right now anyway.

Not sure what we are arguing here, as I said, "adding back Filmic to the view transform menu was requested by Brecht", that request has been fullfilled for a couple of months now.

A while ago I stumbled upon Feedback / Development: Filmic, Baby Step to a V2? I take that this is the Pull Request relating to it?

Yes.

> So I think that simply adding AgX to the View Transforms is better than outright replacing Filmic. It's not like we've got that many options to choose from right now anyway. Not sure what we are arguing here, as I said, "adding back Filmic to the view transform menu was requested by Brecht", that request has been fullfilled for a couple of months now. > A while ago I stumbled upon [Feedback / Development: Filmic, Baby Step to a V2?](https://blenderartists.org/t/feedback-development-filmic-baby-step-to-a-v2/1361663) I take that this is the Pull Request relating to it? Yes.
First-time contributor

I'm not trying to argue with you, I just wanted to say that I also think that it was the right choice. :-)

I'm not trying to argue with you, I just wanted to say that I also think that it was the right choice. :-)
Zijun Zhou added 1 commit 2023-06-03 18:56:38 +02:00
Zijun Zhou added 1 commit 2023-06-07 00:19:14 +02:00
Zijun Zhou added 2 commits 2023-06-12 17:18:08 +02:00
Zijun Zhou added 2 commits 2023-06-14 17:57:24 +02:00
48275fb39c Improve Rate of Change Again
I think this should be the last edit reguarding rate of change, if nothing unexpected pop up.
Zijun Zhou added 1 commit 2023-06-14 17:58:12 +02:00
Zijun Zhou added 2 commits 2023-06-15 05:19:28 +02:00
First-time contributor

So, are we going to have AgX (Filmic v2) in the Blender 3.6 release?

So, are we going to have AgX (Filmic v2) in the Blender 3.6 release?
Member

So, are we going to have AgX (Filmic v2) in the Blender 3.6 release?

Blender 4.0 at the earliest.

> So, are we going to have AgX (Filmic v2) in the Blender 3.6 release? Blender 4.0 at the earliest.
First-time contributor

So, are we going to have AgX (Filmic v2) in the Blender 3.6 release?

If you want it you can download the the files of this PR and replace the existing config with them, problems will just arise if you give away the files you make because it will reset to standard for those who don't have a matching config.

> So, are we going to have AgX (Filmic v2) in the Blender 3.6 release? If you want it you can download the the files of this PR and replace the existing config with them, problems will just arise if you give away the files you make because it will reset to standard for those who don't have a matching config.
Author
Contributor

@brecht @pablovazquez I want to get some comfirmation, is there another dev in charge of the UI that can help with the Filmic Looks' view-based filtering? I honestly have no idea how to change the Blender UI side of things.

For the record:
lQLPJx71Lz1ifULMjc0F2LAzl3uA2WOPsgSj27igANUB_1496_141

@brecht @pablovazquez I want to get some comfirmation, is there another dev in charge of the UI that can help with the Filmic Looks' view-based filtering? I honestly have no idea how to change the Blender UI side of things. For the record: ![lQLPJx71Lz1ifULMjc0F2LAzl3uA2WOPsgSj27igANUB_1496_141](/attachments/303729c7-1686-4713-afe0-b82adab160f0)
Zijun Zhou added 2 commits 2023-06-22 18:45:09 +02:00
Zijun Zhou added 1 commit 2023-06-22 19:17:33 +02:00
Member

Looking at 3cd27374ee (diff-12aec181a13f7921c34e80fae1a1340814469586) , 9f4b090eec , and https://projects.blender.org/blender/blender/src/branch/main/source/blender/imbuf/intern/colormanagement.cc#L3210 , I was able to figure out that you can limit looks to a specific View by adding the View and a hyphen separator as a prefix to the Look Name.

So Filmic - Very High Contrast and AgX - Very High Contrast

Looking at https://projects.blender.org/blender/blender/commit/3cd27374ee53bc2ae3fd08b0b73c0a3118f81020#diff-12aec181a13f7921c34e80fae1a1340814469586 , https://projects.blender.org/blender/blender/commit/9f4b090eec395d49b11a8fffe7ad2908a9de409a , and https://projects.blender.org/blender/blender/src/branch/main/source/blender/imbuf/intern/colormanagement.cc#L3210 , I was able to figure out that you can limit looks to a specific View by adding the View and a hyphen separator as a prefix to the Look Name. So `Filmic - Very High Contrast` and `AgX - Very High Contrast`
Author
Contributor

Thanks but again the current situation is:

image
Both Filmic Looks and AgX Looks are present at the same time when choosing Filmic, which is confusing.

Thanks but again the current situation is: > ![image](/attachments/1a4fd1ae-ccd6-415f-aab8-5106e49d4f16) > Both Filmic Looks and AgX Looks are present at the same time when choosing Filmic, which is confusing.
Member

Try it.

Note that by adding the AgX - prefix, the looks won't show up under AgX Log, Guard Rail, ect. EDIT: which is a problem. It would be better if we could add looks to multiple views, like how OCIO added the ability to add shared views to several displays in v 2.0

Try it. Note that by adding the `AgX -` prefix, the looks won't show up under AgX Log, Guard Rail, ect. EDIT: which is a problem. It would be better if we could add looks to multiple views, like how OCIO added the ability to add shared views to several displays in v 2.0
Author
Contributor

Ok I see what you are doing.

Note that by adding the AgX - prefix, the looks won't show up under AgX Log, Guard Rail, ect.

But this doesn't sound ideal. I would like AgX Log and Guard Rail etc. to be able to use the looks. I guess this approach can be our last resort if the further UI modification doesn't work.

Ok I see what you are doing. > Note that by adding the `AgX -` prefix, the looks won't show up under AgX Log, Guard Rail, ect. But this doesn't sound ideal. I would like `AgX Log` and `Guard Rail` etc. to be able to use the looks. I guess this approach can be our last resort if the further UI modification doesn't work.
Zijun Zhou added 2 commits 2023-07-15 09:57:06 +02:00
Zijun Zhou added 1 commit 2023-07-15 09:59:03 +02:00
Author
Contributor

Note that by adding the AgX - prefix, the looks won't show up under AgX Log, Guard Rail, ect.

But this doesn't sound ideal. I would like AgX Log and Guard Rail etc. to be able to use the looks. I guess this approach can be our last resort if the further UI modification doesn't work.

After thinking a bit more, I decided to take the method for now, until we have something better. It's committed. At least Filmic looks are back in the menu and they are not mixed together with AgX ones now.

image

I kept Greyscale in there, since it also works for Filmic.

> > Note that by adding the `AgX -` prefix, the looks won't show up under AgX Log, Guard Rail, ect. > > But this doesn't sound ideal. I would like `AgX Log` and `Guard Rail` etc. to be able to use the looks. I guess this approach can be our last resort if the further UI modification doesn't work. After thinking a bit more, I decided to take the method for now, until we have something better. It's committed. At least Filmic looks are back in the menu and they are not mixed together with AgX ones now. ![image](/attachments/ccd4b3be-d208-46d1-9c3e-a196b62343f9) I kept `Greyscale` in there, since it also works for Filmic.
Zijun Zhou added 2 commits 2023-07-21 11:37:56 +02:00
Zijun Zhou added 2 commits 2023-07-21 11:53:53 +02:00
fec15a22c7 Encode False Color to display encodings
Original thought for not doing this was thinking I would like to use the maximum "purity" for the color-coded ranges, but after thinking it through, different displays' primaries have different perceptual "hue", therefore it will become confusing if I don't properly encode it.

I was testing and digging into this patch quite a bit today. The AgX view makes things look so much more interesting! Would really be nice to finish this project for Blender 4.0.

Before going to some technical points, I'd like to mention that backwards compatibility is important. We value it a lot. So even though it is a new major Blender version in the works, we can not that easily break things. It is forward compatibility which is allowed to be broken, but even that has some limits. You can read more about exact details in the Compatibility Handling Wiki page.

One of the first thing I did was to run the regression tests, and a lot of them has failed. A lot of images are now rendering noticably brighter, even though they do not use any image textures and use Standard view transform. For example the anisotropic ashikhmin test from BSDF render collection: Screenshot 2023-07-21 at 15.56.09.png

Not entirely sure yet which exact change of this patch leads to this brightening.

Another test I did was with some of the Tears of Steal frames (beware: is quite big EXR, just some random HDR i had around). Simply opening the file shows quite big change:

main PR
Screenshot - main.png Screenshot - PR.png

This is interesting because neither view nor look transform are supposed to be applied. Additionally, enabling View as Render and View Transform set to Standard does not change the look in the main branch, but changes the look by quite a lot with this patch. My speculation is is that it is due to sRGB space having a higher clamping value (in the main branch it only goes up to 4.875, not sure yet what it goes up to in the PR). Having wider sRGB range would be beneficial for some other work (perhaps the EDL story in #105662, for example), but it worth ensuring that the difference is indeed caused by it.

Another thing I've noticed on the interface is the more options for the linear space. I think it is useful to extend the available options, but to me it is not immediately clear why they are coupled to the AgX view.

On a review side I really think we need to break things down into smaller verifiable steps. It will speed up troubleshooting of regressions, and will allow things to go to main sooner, as well as will help bisecting possible regressions.

The way I see the breakdown is:

  • Have few EXR images which demonstrates the benefit of AgX the best (helps for communication and demonstration, but also to ensure that changes we do as part of the review/moving things to the main branch do not case unintended result changes of the AgX)
  • Extend the sRGB space (seems it is needed for this patch, and will bring benefits for other projects)
  • Add AgX view (based on the existing at that time state of the config.ocio)
  • Add extra linear space options for the interop
  • Add extra display options and AgX view to them

Thing I am not sure about is the reference space change. I am not sure whether it is somehow required for the AgX transform to work, or whether it is more of a future-proofing for possible spectral story. If it is the former I'd really appreciate having details about it. If it is the latter, it would need to be a separate point in the break-down list.

I can see that this might sound like a lot of extra work, and that the final state will probably end up being somewhat close to the current state of the patch .But I believe it worth it and it will actually save time while nailing down known regressive changes, and will help nailing down possible regressions discovered later. I did experiment with porting minimal set of the patch to the current configuration and it wasn't bad at all!

What do you think about it? Anything I am missing? Do you think it is something you can help us with?

I was testing and digging into this patch quite a bit today. The AgX view makes things look so much more interesting! Would really be nice to finish this project for Blender 4.0. Before going to some technical points, I'd like to mention that backwards compatibility is important. We value it a lot. So even though it is a new major Blender version in the works, we can not that easily break things. It is forward compatibility which is allowed to be broken, but even that has some limits. You can read more about exact details in the [Compatibility Handling](https://wiki.blender.org/wiki/Process/Compatibility_Handling) Wiki page. One of the first thing I did was to run the regression tests, and a lot of them has failed. A lot of images are now rendering noticably brighter, even though they do not use any image textures and use Standard view transform. For example the [anisotropic ashikhmin](https://svn.blender.org/svnroot/bf-blender/trunk/lib/tests/render/bsdf/anisotropic_ashikhmin.blend) test from BSDF render collection: ![Screenshot 2023-07-21 at 15.56.09.png](/attachments/109c47f7-b129-4ed7-a1ad-315afed84a20) Not entirely sure yet which exact change of this patch leads to this brightening. Another test I did was with some of the [Tears of Steal frames](https://download.blender.org/ftp/sergey/attic/A003C014_12050700000.exr) (beware: is quite big EXR, just some random HDR i had around). Simply opening the file shows quite big change: | main | PR | | ---- | ---- | | ![Screenshot - main.png](/attachments/54b31971-e0e2-48d2-a1fa-b14186b20bc1) | ![Screenshot - PR.png](/attachments/c85d8b02-2e1b-4c04-9f88-286218ee63e3) This is interesting because neither view nor look transform are supposed to be applied. Additionally, enabling `View as Render` and `View Transform` set to `Standard` does not change the look in the main branch, but changes the look by quite a lot with this patch. My speculation is is that it is due to sRGB space having a higher clamping value (in the main branch it only goes up to 4.875, not sure yet what it goes up to in the PR). Having wider sRGB range would be beneficial for some other work (perhaps the EDL story in #105662, for example), but it worth ensuring that the difference is indeed caused by it. Another thing I've noticed on the interface is the more options for the linear space. I think it is useful to extend the available options, but to me it is not immediately clear why they are coupled to the AgX view. On a review side I really think we need to break things down into smaller verifiable steps. It will speed up troubleshooting of regressions, and will allow things to go to main sooner, as well as will help bisecting possible regressions. The way I see the breakdown is: * Have few EXR images which demonstrates the benefit of AgX the best (helps for communication and demonstration, but also to ensure that changes we do as part of the review/moving things to the main branch do not case unintended result changes of the AgX) * Extend the sRGB space (seems it is needed for this patch, and will bring benefits for other projects) * Add AgX view (based on the existing at that time state of the config.ocio) * Add extra linear space options for the interop * Add extra display options and AgX view to them Thing I am not sure about is the reference space change. I am not sure whether it is somehow required for the AgX transform to work, or whether it is more of a future-proofing for possible spectral story. If it is the former I'd really appreciate having details about it. If it is the latter, it would need to be a separate point in the break-down list. I can see that this might sound like a lot of extra work, and that the final state will probably end up being somewhat close to the current state of the patch .But I believe it worth it and it will actually save time while nailing down known regressive changes, and will help nailing down possible regressions discovered later. I did experiment with porting minimal set of the patch to the current configuration and it wasn't bad at all! What do you think about it? Anything I am missing? Do you think it is something you can help us with?
First-time contributor

Have few EXR images which demonstrates the benefit of AgX the best

I think the exrs in the PR demonstrate it quite well. I'm guessing you mean it should be fewer than that. How many, do you think, would be a good number?
Right now it's three exrs from renders and three "real" ones (i.e. photos/video stills)

> Have few EXR images which demonstrates the benefit of AgX the best I think the exrs in the PR demonstrate it quite well. I'm guessing you mean it should be fewer than that. How many, do you think, would be a good number? Right now it's three exrs from renders and three "real" ones (i.e. photos/video stills)
Author
Contributor

Thanks for the testings!

A lot of images are now rendering noticably brighter, even though they do not use any image textures and use Standard view transform.

I believe this is due to the fact that we switched to the pure power function sRGB in this patch, rather than the piece-wise sRGB we have been using. If we decide to change it back to piece-wise, I can do that quite easily but I also want to type out my reasonings here for the record.

FilmLight has a video on the topic: https://www.youtube.com/watch?v=NzhUzeNUBuM&ab_channel=FilmLight

The sRGB standard specified a pure power 2.2 display device, but a peice-wise linear+2.4 function for the file encoding, the reason is to implicitly include a flare compensation for CRT displays. It's been explained in the video I posted above:
image

The result, as I have writtem here before, would be:

  1. sRGB 2.2 values being displayed on piece-wise calibrated monitor, shadow gets a little tiny bit brighter
  2. sRGB 2.2 values being displayed 2.2 calibrated monitor, displayed as intended.

VS if we use piece-wise function:

  1. sRGB piece-wise value on being displayed on 2.2 calibrated monitor, resulting in shadows getting crushed. (was the ideal behavior in old-school CRT color management, but not anymore in modern color managment workflow)
  2. sRGB piece-wise value on being displayed on piece-wise calibrated monitor, properly displayed.

FilmLight also included a survey they did:
lALPM4AfHpjgvyrNBDjNB4A_1920_1080

From the survey, most people assume sRGB to be pure power 2.2. Therefore most people actually saw the shadows get crushed by default when using piece-wise sRGB.

image

That's why I believe moving to pure 2.2 is a good choice, I also made it explicit that I was using a 2.2 curve by naming the space sRGB 2.2, but Brecht requested to rename it back to sRGB, therefore I did.

I would like to confirm the decision, are we reverting back to piece-wise sRGB? If answer is yes, will commit

This is interesting because neither view nor look transform are supposed to be applied. Additionally, enabling View as Render and View Transform set to Standard does not change the look in the main branch, but changes the look by quite a lot with this patch.

I believe this is because the Guard Rail view transform has been set to the first one on the list, and that was an intentional choice as well. Again, if it's requested to put Standard back to the first on the list, it's an easy change. But I again would like to type out my reasonings for the record.

This one is simpler, because I would like users to see this by default when dragging their HDRI to the image editor:
image

Instead of this skewing to cyan sky:
image

Since Guard Rail means the fence on the edge of the cliff to prevent colors from falling into accidental skewings, it was designed to be the default. It also doesn't impact the texture preview functionality so I thought it should be fine.

But again, if you confirm we still want Standard to be the default, will commit.

Thing I am not sure about is the reference space change. I am not sure whether it is somehow required for the AgX transform to work, or whether it is more of a future-proofing for possible spectral story.

Partially for the spectral branch. But it's also more straight forward for the definition of the color spaces.

If we want to define the BT.2020 space in the config shipped with 3.6, we need to convert Linear BT.709 to Linear CIE-XYZ I-D65, and then apply the standard XYZ to RGB matrix for BT.2020. Practically you can of course combine the two matrix into one mathmatically, but in principle, CIE XYZ is just where all RGB spaces are defined down to the root. So it makes more sense to work from ground up, instead climbing down from the BT.709 tree branch to the XYZ root, and then climb up to another space branch every time. The use of I-E white point is also trying to provide the needed option for spectral branch. It's also more reasonable because the actual CIE standard XYZ has always been I-E (Resolve's CIE XYZ space is also I-E. If user exports EXR with CIE XYZ encoding and want to import into Resolve, they need to use the I-E one).

If we are requested to revert the reference space back to Linear BT.709 I-D65, it can be done, but a bit more troublesome than the first two items.

So summerize the decision we need to make here:

  1. sRGB, pure power function (what most people are using) or piece-wise (the old-school "standard")?
  2. The first view transform on the list, Guard Rail or Standard?
  3. Keep Linear CIE-XYZ I-E being the reference or Linear BT.709 I-D65 as reference?
Thanks for the testings! > A lot of images are now rendering noticably brighter, even though they do not use any image textures and use Standard view transform. I believe this is due to the fact that we switched to the pure power function sRGB in this patch, rather than the piece-wise sRGB we have been using. If we decide to change it back to piece-wise, I can do that quite easily but I also want to type out my reasonings here for the record. FilmLight has a video on the topic: https://www.youtube.com/watch?v=NzhUzeNUBuM&ab_channel=FilmLight The sRGB standard specified a pure power 2.2 display device, but a peice-wise linear+2.4 function for the file encoding, the reason is to implicitly include a flare compensation for CRT displays. It's been explained in the video I posted above: ![image](/attachments/d505124f-48a2-4375-9368-644b40d7dfa9) The result, as I have writtem here before, would be: > 1. sRGB 2.2 values being displayed on piece-wise calibrated monitor, shadow gets a little tiny bit brighter > 2. sRGB 2.2 values being displayed 2.2 calibrated monitor, displayed as intended. > > VS if we use piece-wise function: > > 1. sRGB piece-wise value on being displayed on 2.2 calibrated monitor, resulting in shadows getting crushed. (was the ideal behavior in old-school CRT color management, but not anymore in modern color managment workflow) > 2. sRGB piece-wise value on being displayed on piece-wise calibrated monitor, properly displayed. FilmLight also included a survey they did: ![lALPM4AfHpjgvyrNBDjNB4A_1920_1080](/attachments/d8b1a90a-2971-4cc9-b4da-6c1f864516ab) From the survey, most people assume sRGB to be pure power 2.2. Therefore most people actually saw the shadows get crushed by default when using piece-wise sRGB. ![image](/attachments/5ec5cf54-b884-4f34-94a7-222736e6083c) That's why I believe moving to pure 2.2 is a good choice, I also made it explicit that I was using a 2.2 curve by naming the space `sRGB 2.2`, but [Brecht requested to rename it back to `sRGB`](https://projects.blender.org/blender/blender/pulls/106355#issuecomment-911981), therefore I did. I would like to confirm the decision, are we reverting back to piece-wise sRGB? If answer is yes, will commit > This is interesting because neither view nor look transform are supposed to be applied. Additionally, enabling View as Render and View Transform set to Standard does not change the look in the main branch, but changes the look by quite a lot with this patch. I believe this is because the `Guard Rail` view transform has been set to the first one on the list, and that was an intentional choice as well. Again, if it's requested to put `Standard` back to the first on the list, it's an easy change. But I again would like to type out my reasonings for the record. This one is simpler, because I would like users to see this by default when dragging their HDRI to the image editor: ![image](/attachments/729dcdcb-9085-44da-a368-e345820ad867) Instead of this skewing to cyan sky: ![image](/attachments/b625bc2b-6f17-43bc-9d31-941014c959f2) Since `Guard Rail` means the fence on the edge of the cliff to prevent colors from falling into accidental skewings, it was designed to be the default. It also doesn't impact the texture preview functionality so I thought it should be fine. But again, if you confirm we still want `Standard` to be the default, will commit. >Thing I am not sure about is the reference space change. I am not sure whether it is somehow required for the AgX transform to work, or whether it is more of a future-proofing for possible spectral story. Partially for the spectral branch. But it's also more straight forward for the definition of the color spaces. If we want to define the BT.2020 space in the config shipped with 3.6, we need to convert Linear BT.709 to Linear CIE-XYZ I-D65, and then apply the standard XYZ to RGB matrix for BT.2020. Practically you can of course combine the two matrix into one mathmatically, but in principle, CIE XYZ is just where all RGB spaces are defined down to the root. So it makes more sense to work from ground up, instead climbing down from the BT.709 tree branch to the XYZ root, and then climb up to another space branch every time. The use of I-E white point is also trying to provide the needed option for spectral branch. It's also more reasonable because the actual CIE standard XYZ has always been I-E (Resolve's CIE XYZ space is also I-E. If user exports EXR with CIE XYZ encoding and want to import into Resolve, they need to use the I-E one). If we are requested to revert the reference space back to Linear BT.709 I-D65, it can be done, but a bit more troublesome than the first two items. So summerize the decision we need to make here: 1. sRGB, pure power function (what most people are using) or piece-wise (the old-school "standard")? 2. The first view transform on the list, `Guard Rail` or `Standard`? 3. Keep Linear CIE-XYZ I-E being the reference or Linear BT.709 I-D65 as reference?
Author
Contributor

The way I see the breakdown is:

  • Have few EXR images which demonstrates the benefit of AgX the best (helps for communication and demonstration, but also to ensure that changes we do as part of the review/moving things to the main branch do not case unintended result changes of the AgX)
  • Extend the sRGB space (seems it is needed for this patch, and will bring benefits for other projects)
  • Add AgX view (based on the existing at that time state of the config.ocio)
  • Add extra linear space options for the interop
  • Add extra display options and AgX view to them

I would modify the breakdown to be:

  • EXR files (attached to this comment, all encoded in Linear BT.709 I-D65)
    (If I understand correctly you mean I need to upload the EXR files)
  • Unclipped sRGB space (which is actually a natural by-product of using built-in functionality of OCIO, instead of a LUT)
  • AgX View and Guard Rail View
  • More Linear color spaces, not only for interop but also for advanced users who want a different working space, they can modify the scene_linear role and rendering role easily. Whether we set a different working space by default is a different story, as other parts of Blender is still not well-prepared for that.
  • More Display Device support, allowing Mac users with Display P3 monitor to properly look at their render in Blender, instead of an overly-saturated (or too chroma-laden) un-color-managed result. (But Blender will still need to embed icc profiles to saved images for file saving to work properly, otherwise saved PNG file encoded as Display P3 will be assumed to be sRGB by OS or image viewer APP).
  • I-E based chromaticity as infrastructure for future Spectral rendering to use. Make sense since CIE standard chromaticity has always been I-E based.

With that said, I am still a bit confused as to what we are making this list for.

On a review side I really think we need to break things down into smaller verifiable steps

Do you mean we will discuss the points on the list in the review process? I am confused.

> The way I see the breakdown is: > > * Have few EXR images which demonstrates the benefit of AgX the best (helps for communication and demonstration, but also to ensure that changes we do as part of the review/moving things to the main branch do not case unintended result changes of the AgX) > * Extend the sRGB space (seems it is needed for this patch, and will bring benefits for other projects) > * Add AgX view (based on the existing at that time state of the config.ocio) > * Add extra linear space options for the interop > * Add extra display options and AgX view to them I would modify the breakdown to be: * EXR files (attached to this comment, all encoded in Linear BT.709 I-D65) (If I understand correctly you mean I need to upload the EXR files) * Unclipped sRGB space (which is actually a natural by-product of using built-in functionality of OCIO, instead of a LUT) * AgX View and Guard Rail View * More Linear color spaces, not only for interop but also for advanced users who want a different working space, they can modify the scene_linear role and rendering role easily. Whether we set a different working space by default is a different story, as other parts of Blender is still not well-prepared for that. * More Display Device support, allowing Mac users with Display P3 monitor to properly look at their render in Blender, instead of an overly-saturated (or too chroma-laden) un-color-managed result. (But Blender will still need to embed icc profiles to saved images for file saving to work properly, otherwise saved PNG file encoded as Display P3 will be assumed to be sRGB by OS or image viewer APP). * I-E based chromaticity as infrastructure for future Spectral rendering to use. Make sense since CIE standard chromaticity has always been I-E based. With that said, I am still a bit confused as to what we are making this list for. >On a review side I really think we need to break things down into smaller verifiable steps Do you mean we will discuss the points on the list in the review process? I am confused.
Author
Contributor

Do you mean we will discuss the points on the list in the review process? I am confused.

After reading a bit more times, I think I understand now.

Do you mean we need to start from the config currently in the main, and port this config to the main with small little steps? And each step will be their own separate PR, this PR will be just a big reference page for those smaller PRs?

If that's the case, the order of the steps will need to be re-arranged:

  • step 1. Clean Up. Delete all not longer used colorspaces and their LUT files.

This includes: nuke_rec709, lg10, XYZ display device and its standard view colorspace (there simply isn't a monitor you can buy on Amazon or Best Buy etc. that claims to be XYZ colorspace)

The None display device has duplicated functionality as the Raw view in sRGB display, will remove None device and rename Raw view to be None view instead.
(None view transform is also very straight forward, it's simply "No view transform applied")

As an extension of that, the Raw and Non-Color are duplicates of each other, we need to remove one of them. Since users are more familiar with Non-Color, and it's also the one assigned as the data role, will keep Non-Color and remove Raw.
Will change the None view (formerly Raw view) to use the Non-Color space. Will also add Raw as an alias of Non-Color

  • step 2. Use OCIO's built-in functionality for sRGB, includes changing sRGB to be un-clipped ̶,̶ ̶a̶n̶d̶ ̶a̶l̶s̶o̶ ̶u̶s̶i̶n̶g̶ ̶p̶u̶r̶e̶ ̶p̶o̶w̶e̶r̶ ̶2̶.̶2̶

  • step 3. refactor the config's transform tree to be XYZ I-E based.
    The design decision has been discussed in this PR, XYZ I-E is the actual CIE standard, it's to prepare for Spectral Cycles, but this will also make the next step more straight forward.

This includes changing the xyz_D65_to_E.spimtx to use the more accurate Bradford method instead of XYZ Scaling, and also adding xyz_E_to_D65.spimtx since the opposite direction uses a different matrix.

  • step 4. add more color spaces. Renaming of existing spaces is required, for example, the name Linear makes no sense when there are a bunch of Linear spaces.
    Will include aliases for backwards compatibility

  • step 5. Add AgX view and its components.
    Some components are added as reusable utility parts for view transforms to use, will use OCIOv2's inactive_colorspaces to hide them from UI.
    This also includes adding the extra display device support, and replacing False Color with new one, as well as AgX looks.
    A̶l̶s̶o̶ ̶s̶h̶r̶i̶n̶k̶ ̶F̶i̶l̶m̶i̶c̶ ̶d̶e̶s̶a̶t̶ ̶L̶U̶T̶ ̶s̶i̶z̶e̶ ̶d̶o̶w̶n̶ ̶w̶i̶t̶h̶ ̶n̶o̶ ̶q̶u̶a̶l̶i̶t̶y̶ ̶l̶o̶s̶s̶.̶ ̶(̶N̶e̶e̶d̶ ̶t̶o̶ ̶m̶a̶k̶e̶ ̶r̶o̶o̶m̶ ̶f̶o̶r̶ ̶A̶g̶X̶ ̶L̶U̶T̶s̶,̶ ̶t̶h̶e̶y̶ ̶a̶r̶e̶ ̶q̶u̶i̶t̶e̶ ̶l̶a̶r̶g̶e̶)̶ ̶

  • step 6. Shrink Filmic desat LUT size down with no quality loss. (Need to make room for AgX LUTs, they are quite large)

Will wait for your answers to all these questions asked, and to the steps here, to make sure we are on the same page before I start to work on this. Especially step 1 and 2, where I remove old stuff.

> Do you mean we will discuss the points on the list in the review process? I am confused. After reading a bit more times, I think I understand now. Do you mean we need to start from the config currently in the main, and port this config to the main with small little steps? And each step will be their own separate PR, this PR will be just a big reference page for those smaller PRs? If that's the case, the order of the steps will need to be re-arranged: * step 1. Clean Up. Delete all not longer used colorspaces and their LUT files. This includes: nuke_rec709, lg10, XYZ display device and its standard view colorspace (there simply isn't a monitor you can buy on Amazon or Best Buy etc. that claims to be XYZ colorspace) The `None` display device has duplicated functionality as the `Raw` view in `sRGB` display, will remove `None` device and rename `Raw` view to be `None` view instead. (`None` view transform is also very straight forward, it's simply "No view transform applied") As an extension of that, the `Raw` and `Non-Color` are duplicates of each other, we need to remove one of them. Since users are more familiar with `Non-Color`, and it's also the one assigned as the `data` role, will keep `Non-Color` and remove `Raw`. Will change the `None` view (formerly `Raw` view) to use the `Non-Color` space. Will also add `Raw` as an alias of `Non-Color` * step 2. Use OCIO's built-in functionality for sRGB, includes changing sRGB to be un-clipped ̶,̶ ̶a̶n̶d̶ ̶a̶l̶s̶o̶ ̶u̶s̶i̶n̶g̶ ̶p̶u̶r̶e̶ ̶p̶o̶w̶e̶r̶ ̶2̶.̶2̶ * step 3. refactor the config's transform tree to be XYZ I-E based. The design decision has been discussed in this PR, XYZ I-E is the actual CIE standard, it's to prepare for Spectral Cycles, but this will also make the next step more straight forward. This includes changing the `xyz_D65_to_E.spimtx` to use the more accurate `Bradford` method instead of `XYZ Scaling`, and also adding `xyz_E_to_D65.spimtx` since the opposite direction uses a different matrix. * step 4. add more color spaces. Renaming of existing spaces is required, for example, the name `Linear` makes no sense when there are a bunch of Linear spaces. Will include aliases for backwards compatibility * step 5. Add AgX view and its components. Some components are added as reusable utility parts for view transforms to use, will use OCIOv2's `inactive_colorspaces` to hide them from UI. This also includes adding the extra display device support, and replacing False Color with new one, as well as AgX looks. A̶l̶s̶o̶ ̶s̶h̶r̶i̶n̶k̶ ̶F̶i̶l̶m̶i̶c̶ ̶d̶e̶s̶a̶t̶ ̶L̶U̶T̶ ̶s̶i̶z̶e̶ ̶d̶o̶w̶n̶ ̶w̶i̶t̶h̶ ̶n̶o̶ ̶q̶u̶a̶l̶i̶t̶y̶ ̶l̶o̶s̶s̶.̶ ̶(̶N̶e̶e̶d̶ ̶t̶o̶ ̶m̶a̶k̶e̶ ̶r̶o̶o̶m̶ ̶f̶o̶r̶ ̶A̶g̶X̶ ̶L̶U̶T̶s̶,̶ ̶t̶h̶e̶y̶ ̶a̶r̶e̶ ̶q̶u̶i̶t̶e̶ ̶l̶a̶r̶g̶e̶)̶ ̶ * step 6. Shrink Filmic desat LUT size down with no quality loss. (Need to make room for AgX LUTs, they are quite large) Will wait for your answers to all these questions asked, and to the steps here, to make sure we are on the same page before I start to work on this. Especially step 1 and 2, where I remove old stuff.

@kram1032 For the EXR files story. The picture in the PR indeed demonstrates the difference well. What I meant is that it would be handy to have the original EXRs which were used to show the difference. The reason for this is because I believe we should move changes in an incremental steps. It will help speedup overall process. Having a common set of images would help with this as then we can more easily verify the result, and if some issue is uncovered we have the same repro case.

@Eary Thanks for the explanation.

I believe this is due to the fact that we switched to the pure power function sRGB in this patch, rather than the piece-wise sRGB we have been using. If we decide to change it back to piece-wise, I can do that quite easily but I also want to type out my reasonings here for the record.
That's why I believe moving to pure 2.2 is a good choice, I also made it explicit that I was using a 2.2 curve by naming the space sRGB 2.2, but Brecht requested to rename it back to sRGB, therefore I did.

Ah, good thought! I did not realize it causes such big visual difference.
I can totally see your reasoning for such change, but, unfortunately, there are still lots of areas of Blender which do not use OCIO configuration for linear<->sRGB conversion. I am not defending those areas by any means, but what I mean is: with the current state of code change from piece-wise to pure-power goes beyond OCIO configuration.

From my understanding the AgX view transform can be done with piece-wise as well, so I would really suggest moving the piece-wise->pure power to a separate project, with its own presentation, motivation, and ensuring that it is done consistently everywhere in Blender.

The Brecht's comment on this topic was mainly about naming convention, and wasn't an intent to replace sRGB to pure power in the OCIO configuration just yet (at least not, as I've mentioned above, looking into and solving all implications).

I believe this is because the Guard Rail view transform has been set to the first one on the list, and that was an intentional choice as well.

Visions of the past! I forgot there is this implicit rule, even though is something i was directly involved into... Duuuh :)

My main concern on this topic was caused by the fact that it wasn't really clear why the change in behavior was introduced. You reply clarified it very well.

It does seems to be re-occuring topic of improving the default "clipping" behavior, and it does seem that the Guard Rail provides much better solution for it. So i think it is fine to have it first in the list.

Partially for the spectral branch. But it's also more straight forward for the definition of the color spaces.

If we want to define the BT.2020 space in the config shipped with 3.6, we need to convert Linear BT.709 to Linear CIE-XYZ I-D65, and then apply the standard XYZ to RGB matrix for BT.2020.

For the spectral story we'll need to change scene linear to something much wider. But that has implications outside of the spectral rendering (current Cycles, NPR renderers, color pickers, assets, etc...). While it is something we'll need to tackle sooner than later, I'd really prefer have a dedicated design for it and tackle it separately. There are quite some questions to be figured out, and I wouldn't want the AgX view transform to be stalled because of them.

The reference space I can't say I am emotionally attached to. On the one hand, changing it risks introducing a regressive change, on another hand at some point we'd need to do change it anyway.

I think it is fine to change the reference, but as a dedicated and isolated PR, for the ease of troubleshooting.

Do you mean we need to start from the config currently in the main, and port this config to the main with small little steps? And each step will be their own separate PR, this PR will be just a big reference page for those smaller PRs?

Exactly that! It is not very practical and frustrating for both sides to work on such big changes. Breaking them down into smaller incremental steps helps a lot.


I like your plan. It does seem that a plan that we'll be able to tackle much much easier!

I did some preliminary comments of things I think are important to keep in mind when working on these steps. Surely some points you might agree, others disagree,. For keeping it practical I'd suggest not having long discussion right now, and have a more focused look and re-iteration (if needed) in the individual PRs.

Step 1. Clean Up. Delete all not longer used colorspaces and their LUT files.

nuke_rec709 and lg10 I don't think are even exposed, so seems that they indeed can just go. As well as vd16.spi1d.

The XYZ display device is indeed in some limbo state. We initially used it to master DCP, but even for that the current configuration is not complete, and we only used the display device because we did not have ability to override color space for saving. So indeed it can go.

The Standard view transform we can not remove due to compatibility reasons.

The None display was a compatibility option for the No color manegement option. I think by now it is too much obsolete. Some versioning code would need to be adjusted, but other than that I think it will be good to remove this legacy thing.

As an extension of that, the Raw and Non-Color are duplicates of each other, we need to remove one of them. Since users are more familiar with Non-Color, and it's also the one assigned as the data role, will keep Non-Color and remove Raw.

Are you talking the input color space here?
If so, is my understanding correct that we can have alias to Raw, to avoid possible compatibility breakage for .blend files which use "Raw" instead of "Non-Color"?

Step 2. Use OCIO's built-in functionality for sRGB, includes changing sRGB to be un-clipped, and also using pure power 2.2

Un-clipping is surely important! I am just a bit concerned it becoming a bigger project to tackle all implications in all related Blender areas (viewport, texturing, sequencer...). Would be nice to have it all consistent, but would also be un-ideal if doing so the AgX will be delaying.

Lets have a deeper dive when the PR is ready!

Step 3. refactor the config's transform tree to be XYZ I-E based.

It is about the reference space being XYZ I-E? Sounds good to me.

Step 4. add more color spaces. Renaming of existing spaces is required, for example, the name Linear makes no sense when there are a bunch of Linear spaces.
Will include aliases for backwards compatibility

Generally fine. The renaming I'd be careful about and would only do if it is solves ambiguity for artists.
Depending on the exact route we take we might need to commit some aliases to 3.6 branch as per the compatibility policy.

I am a bit on a split w.r.t Linear name. The conservative part of me says "leave it alone" but looking-into-future part of me says "if we plan to introduce wider-gamut configuration in Blender we'd better give a clear name to the space, to avoid people wrongly assuming it is Scene Linear. And now it is the best time to do so". More I think about it more I think renaming to "Linear rec709" is the proper way forward. Although, could be good to have a color space which always means "Scene Linear" to be used in, i.e., color space compositor node.

But lets not go ahead too much in discussion just yet, and talk in derails in the specific PR.

Step 5. Add AgX view and its components.

The most exciting part!

The only comment i have here is that maybe shrinking the Filmic LUT can be done separately from it? I am not aware of inter-dependencies, but sounds like it will be possible to do as "simple, no expected changes on user-level, just merge it now" PR.


On a higher level there are couple of points which I am curious about when it comes to adding view transforms and display devices.

One of them is the virtual display. It would be nice to have a default option which will detect the actual monitor without user specifying an exact color space (which could even change when moving Blender window across screens). It is something we're investigating in the context of the EDR/HDR support. The way mac does it is kind of convenient when we output a color space (AFAIR it is rec2020), tell it to the OS which color space it is, and leave the final transform to the OS. Do you have experience with the virtual display option? Is it something that really solves what we believe it solves?

Another point is about shared views and display_colorspaces. Is it somehow possible to utilize them to make it easier to expand AgX view transform to other color space (and possibly to also support the virtual display) ?


P.S. Apologies for the lengthy reply :) Hopefully it all makes sense =)

@kram1032 For the EXR files story. The picture in the PR indeed demonstrates the difference well. What I meant is that it would be handy to have the original EXRs which were used to show the difference. The reason for this is because I believe we should move changes in an incremental steps. It will help speedup overall process. Having a common set of images would help with this as then we can more easily verify the result, and if some issue is uncovered we have the same repro case. @Eary Thanks for the explanation. > I believe this is due to the fact that we switched to the pure power function sRGB in this patch, rather than the piece-wise sRGB we have been using. If we decide to change it back to piece-wise, I can do that quite easily but I also want to type out my reasonings here for the record. > That's why I believe moving to pure 2.2 is a good choice, I also made it explicit that I was using a 2.2 curve by naming the space sRGB 2.2, but Brecht requested to rename it back to sRGB, therefore I did. Ah, good thought! I did not realize it causes such big visual difference. I can totally see your reasoning for such change, but, unfortunately, there are still lots of areas of Blender which do not use OCIO configuration for linear<->sRGB conversion. I am not defending those areas by any means, but what I mean is: with the current state of code change from piece-wise to pure-power goes beyond OCIO configuration. From my understanding the AgX view transform can be done with piece-wise as well, so I would really suggest moving the piece-wise->pure power to a separate project, with its own presentation, motivation, and ensuring that it is done consistently everywhere in Blender. The Brecht's comment on this topic was mainly about naming convention, and wasn't an intent to replace sRGB to pure power in the OCIO configuration just yet (at least not, as I've mentioned above, looking into and solving all implications). > I believe this is because the Guard Rail view transform has been set to the first one on the list, and that was an intentional choice as well. Visions of the past! I forgot there is this implicit rule, even though is something i was directly involved into... Duuuh :) My main concern on this topic was caused by the fact that it wasn't really clear why the change in behavior was introduced. You reply clarified it very well. It does seems to be re-occuring topic of improving the default "clipping" behavior, and it does seem that the `Guard Rail` provides much better solution for it. So i think it is fine to have it first in the list. > Partially for the spectral branch. But it's also more straight forward for the definition of the color spaces. > > If we want to define the BT.2020 space in the config shipped with 3.6, we need to convert Linear BT.709 to Linear CIE-XYZ I-D65, and then apply the standard XYZ to RGB matrix for BT.2020. For the spectral story we'll need to change scene linear to something much wider. But that has implications outside of the spectral rendering (current Cycles, NPR renderers, color pickers, assets, etc...). While it is something we'll need to tackle sooner than later, I'd really prefer have a dedicated design for it and tackle it separately. There are quite some questions to be figured out, and I wouldn't want the AgX view transform to be stalled because of them. The reference space I can't say I am emotionally attached to. On the one hand, changing it risks introducing a regressive change, on another hand at some point we'd need to do change it anyway. I think it is fine to change the reference, but as a dedicated and isolated PR, for the ease of troubleshooting. > Do you mean we need to start from the config currently in the main, and port this config to the main with small little steps? And each step will be their own separate PR, this PR will be just a big reference page for those smaller PRs? Exactly that! It is not very practical and frustrating for both sides to work on such big changes. Breaking them down into smaller incremental steps helps a lot. --- I like your plan. It does seem that a plan that we'll be able to tackle much much easier! I did some preliminary comments of things I think are important to keep in mind when working on these steps. Surely some points you might agree, others disagree,. For keeping it practical I'd suggest not having long discussion right now, and have a more focused look and re-iteration (if needed) in the individual PRs. > Step 1. Clean Up. Delete all not longer used colorspaces and their LUT files. `nuke_rec709` and `lg10` I don't think are even exposed, so seems that they indeed can just go. As well as `vd16.spi1d`. The `XYZ display device` is indeed in some limbo state. We initially used it to master DCP, but even for that the current configuration is not complete, and we only used the display device because we did not have ability to override color space for saving. So indeed it can go. The `Standard` view transform we can not remove due to compatibility reasons. The `None` display was a compatibility option for the `No color manegement` option. I think by now it is too much obsolete. Some versioning code would need to be adjusted, but other than that I think it will be good to remove this legacy thing. > As an extension of that, the `Raw` and `Non-Color` are duplicates of each other, we need to remove one of them. Since users are more familiar with `Non-Color`, and it's also the one assigned as the data role, will keep `Non-Color` and remove Raw. Are you talking the input color space here? If so, is my understanding correct that we can have alias to Raw, to avoid possible compatibility breakage for .blend files which use "Raw" instead of "Non-Color"? > Step 2. Use OCIO's built-in functionality for sRGB, includes changing sRGB to be un-clipped, and also using pure power 2.2 Un-clipping is surely important! I am just a bit concerned it becoming a bigger project to tackle all implications in all related Blender areas (viewport, texturing, sequencer...). Would be nice to have it all consistent, but would also be un-ideal if doing so the AgX will be delaying. Lets have a deeper dive when the PR is ready! > Step 3. refactor the config's transform tree to be XYZ I-E based. It is about the reference space being `XYZ I-E`? Sounds good to me. > Step 4. add more color spaces. Renaming of existing spaces is required, for example, the name Linear makes no sense when there are a bunch of Linear spaces. > Will include aliases for backwards compatibility Generally fine. The renaming I'd be careful about and would only do if it is solves ambiguity for artists. Depending on the exact route we take we might need to commit some aliases to 3.6 branch as per the compatibility policy. I am a bit on a split w.r.t `Linear` name. The conservative part of me says "leave it alone" but looking-into-future part of me says "if we plan to introduce wider-gamut configuration in Blender we'd better give a clear name to the space, to avoid people wrongly assuming it is Scene Linear. And now it is the best time to do so". More I think about it more I think renaming to "Linear rec709" is the proper way forward. Although, could be good to have a color space which always means "Scene Linear" to be used in, i.e., color space compositor node. But lets not go ahead too much in discussion just yet, and talk in derails in the specific PR. > Step 5. Add AgX view and its components. The most exciting part! The only comment i have here is that maybe shrinking the Filmic LUT can be done separately from it? I am not aware of inter-dependencies, but sounds like it will be possible to do as "simple, no expected changes on user-level, just merge it now" PR. --- On a higher level there are couple of points which I am curious about when it comes to adding view transforms and display devices. One of them is the [virtual display](https://opencolorio.readthedocs.io/en/latest/guides/authoring/displays_views.html#virtual-display). It would be nice to have a default option which will detect the actual monitor without user specifying an exact color space (which could even change when moving Blender window across screens). It is something we're investigating in the context of the EDR/HDR support. The way mac does it is kind of convenient when we output a color space (AFAIR it is rec2020), tell it to the OS which color space it is, and leave the final transform to the OS. Do you have experience with the virtual display option? Is it something that really solves what we believe it solves? Another point is about [shared views](https://opencolorio.readthedocs.io/en/latest/guides/authoring/displays_views.html#shared-views) and `display_colorspaces`. Is it somehow possible to utilize them to make it easier to expand AgX view transform to other color space (and possibly to also support the virtual display) ? --- P.S. Apologies for the lengthy reply :) Hopefully it all makes sense =)
First-time contributor

One of them is the virtual display. It would be nice to have a default option which will detect the actual monitor without user specifying an exact color space (which could even change when moving Blender window across screens). It is something we're investigating in the context of the EDR/HDR support. The way mac does it is kind of convenient when we output a color space (AFAIR it is rec2020), tell it to the OS which color space it is, and leave the final transform to the OS. Do you have experience with the virtual display option? Is it something that really solves what we believe it solves?

@Sergey there's a new feature in Windows 11 called Auto Color Management (ACM) may help.
Advancing the State of Color Management in Windows
It is the color management features of windows HDR that being bringed over to SDR in 2022.

> One of them is the virtual display. It would be nice to have a default option which will detect the actual monitor without user specifying an exact color space (which could even change when moving Blender window across screens). It is something we're investigating in the context of the EDR/HDR support. The way mac does it is kind of convenient when we output a color space (AFAIR it is rec2020), tell it to the OS which color space it is, and leave the final transform to the OS. Do you have experience with the virtual display option? Is it something that really solves what we believe it solves? @Sergey there's a new feature in Windows 11 called Auto Color Management (ACM) may help. [Advancing the State of Color Management in Windows](https://devblogs.microsoft.com/directx/auto-color-management/) It is the color management features of windows HDR that being bringed over to SDR in 2022.
Author
Contributor

Thanks for the reply, that settles a lot of questions for me.

On a higher level there are couple of points which I am curious about when it comes to adding view transforms and display devices.

One of them is the virtual display. It would be nice to have a default option which will detect the actual monitor without user specifying an exact color space (which could even change when moving Blender window across screens). It is something we're investigating in the context of the EDR/HDR support. The way mac does it is kind of convenient when we output a color space (AFAIR it is rec2020), tell it to the OS which color space it is, and leave the final transform to the OS. Do you have experience with the virtual display option? Is it something that really solves what we believe it solves?

Another point is about shared views and display_colorspaces. Is it somehow possible to utilize them to make it easier to expand AgX view transform to other color space (and possibly to also support the virtual display) ?

I have experimented with these but had some concerns. Mainly two points (I also mentioned them in the other topic)

The <USE_DISPLAY_NAME> and display_colorspaces features seem to work hand in hand, and seem to require the view transforms to be listed in their own view_transforms section, which means the view transform spaces will be hidden from the color space list UI, causing a regression where user will no longer be allowed to use the Convert Colorspace node in compositor to manually apply the view transform.

And where they include an auto conversion to the display space, there is also a concern that we should instead use the Guard Rails we crafted. AgX uses a "BT.2020 master" image and uses the Guard Rail view transforms dedicated for each display, to handle the BT.2020 to other display step. I don't think the auto conversion covers the nuance, for example, BT.2020 green actually looks like more of a mint green than the more yellowish green we are used to seeing. We included a chromaticity-linear "gamut compression" (might not be the best term to describe it) in the Guard Rails that I don't think the auto conversions cover at all.

The Standard view transform we can not remove due to compatibility reasons.

Just to clarify, when I said XYZ display device and its Standard view transform space, I am referring to the dci-xyz space (which is defined in the config to be CIE XYZ I-D65 with a non-linear transfer function), not the idea of Standard view transforms in general. Do you mean we should keep the dci-xyz space or do you simply mean we keep the general idea of Standard view transforms? Because I don't see the need of keeping the DCI-XYZ space around when we are removing the XYZ display in the first place.

Thanks for the reply, that settles a lot of questions for me. >On a higher level there are couple of points which I am curious about when it comes to adding view transforms and display devices. > >One of them is the virtual display. It would be nice to have a default option which will detect the actual monitor without user specifying an exact color space (which could even change when moving Blender window across screens). It is something we're investigating in the context of the EDR/HDR support. The way mac does it is kind of convenient when we output a color space (AFAIR it is rec2020), tell it to the OS which color space it is, and leave the final transform to the OS. Do you have experience with the virtual display option? Is it something that really solves what we believe it solves? > >Another point is about shared views and display_colorspaces. Is it somehow possible to utilize them to make it easier to expand AgX view transform to other color space (and possibly to also support the virtual display) ? I have experimented with these but had some concerns. Mainly two points (I also mentioned them in the other topic) The `<USE_DISPLAY_NAME>` and `display_colorspaces` features seem to work hand in hand, and seem to require the view transforms to be listed in their own `view_transforms` section, which means the view transform spaces will be hidden from the color space list UI, causing a regression where user will no longer be allowed to use the `Convert Colorspace` node in compositor to manually apply the view transform. And where they include an auto conversion to the display space, there is also a concern that we should instead use the Guard Rails we crafted. AgX uses a "BT.2020 master" image and uses the `Guard Rail` view transforms dedicated for each display, to handle the `BT.2020 to other display` step. I don't think the auto conversion covers the nuance, for example, BT.2020 green actually looks like more of a mint green than the more yellowish green we are used to seeing. We included a chromaticity-linear "gamut compression" (might not be the best term to describe it) in the Guard Rails that I don't think the auto conversions cover at all. >The Standard view transform we can not remove due to compatibility reasons. Just to clarify, when I said XYZ display device and its `Standard` view transform space, I am referring to the dci-xyz space (which is defined in the config to be CIE XYZ I-D65 with a non-linear transfer function), not the idea of `Standard` view transforms in general. Do you mean we should keep the dci-xyz space or do you simply mean we keep the general idea of `Standard` view transforms? Because I don't see the need of keeping the DCI-XYZ space around when we are removing the XYZ display in the first place.
Zijun Zhou added 2 commits 2023-07-27 00:53:18 +02:00
Zijun Zhou added 2 commits 2023-07-27 01:18:29 +02:00
16d0e106d0 Add one more Non-Color alias I forgot to include
Add the `Utility - Raw` from the ACES config to make sure people that have been using ACES can smoothly transition to this new config.

@baoyu Thanks for the link.

From the integration into blender point of view, is it something like using the API you've linked to to query ICC, and provide this to OCIO?

@Eary Interesting.

For the guard rail story. Imagine for a moment we have some smart logic in the OCIO GPU shader (and its CPU side friend for the file output) which does smarter thing than simply clipping individual channels. Will doing so simplify some of the Guard Rail and display_colorspace ?

Just to clarify, when I said XYZ display device and its Standard view transform space

Ah, I think I've missed the "its" part, sorry. If you are talking about XYZ display, its Standard, DCI, and RAW views (and all the "loose" ends after that such removal) then we are in an agreement.

What i meant is that sRGB Standard we need to keep for the compatibility.

@baoyu Thanks for the link. From the integration into blender point of view, is it something like using the API you've linked to to query ICC, and provide this to OCIO? @Eary Interesting. For the guard rail story. Imagine for a moment we have some smart logic in the OCIO GPU shader (and its CPU side friend for the file output) which does smarter thing than simply clipping individual channels. Will doing so simplify some of the `Guard Rail` and `display_colorspace` ? > Just to clarify, when I said XYZ display device and its Standard view transform space Ah, I think I've missed the "its" part, sorry. If you are talking about XYZ display, its Standard, DCI, and RAW views (and all the "loose" ends after that such removal) then we are in an agreement. What i meant is that sRGB Standard we need to keep for the compatibility.
Author
Contributor

Imagine for a moment we have some smart logic in the OCIO GPU shader (and its CPU side friend for the file output) which does smarter thing than simply clipping individual channels. Will doing so simplify some of the Guard Rail and display_colorspace ?

It would indeed, it equals to OCIO implementing a standardized Guard Rail that we can just use. But I don't think there currently is such a thing? Otherwise why would the ACES people look at the complex CAM models (that Troy said they don't work, I am not sure on that front) to do their own "Gamut Compression" for their ACES 2.0 candidate?

If there comes such a thing in OCIO, and if it behaves just as good or even better than our implementation (probably will be better considering theirs would be shader vs ours is LUTs), it doesn't hurt to use it. But I don't think there currently is such a thing.

>Imagine for a moment we have some smart logic in the OCIO GPU shader (and its CPU side friend for the file output) which does smarter thing than simply clipping individual channels. Will doing so simplify some of the Guard Rail and display_colorspace ? It would indeed, it equals to OCIO implementing a standardized Guard Rail that we can just use. But I don't think there currently is such a thing? Otherwise why would the ACES people look at the complex CAM models (that Troy said they don't work, I am not sure on that front) to do their own "Gamut Compression" for their ACES 2.0 candidate? If there comes such a thing in OCIO, and if it behaves just as good or even better than our implementation (probably will be better considering theirs would be shader vs ours is LUTs), it doesn't hurt to use it. But I don't think there currently is such a thing.

There is indeed no such a thing in OCIO (at least not as far as I know), but it doesn't mean that we can't implement a better clipping on our side. Is not something we have a huge amount of thought, is just a topic which popped recently when we talked about adjacent topics with Nathan.

There is indeed no such a thing in OCIO (at least not as far as I know), but it doesn't mean that we can't implement a better clipping on our side. Is not something we have a huge amount of thought, is just a topic which popped recently when we talked about adjacent topics with Nathan.
First-time contributor

For old-fashioned-and-will-to-self-color-managed-app, windows allow the user to bypass ACM like this.
image

In ACM, apps want to display HDR signal or widegamut SDR signal, just use the APIs that MS provided to compose contents within the app, then send the tagged result to Desktop Window Manager (DWM). The OS will do the rest.

Here's a briefed guide to integrate windows auto color management.
AFAIK, there's only APIs for UWP, directX Apps being talked in this guide. I'm afraid that blender isn't a UWP app or DX app.
However, if an app doesn't adpat to ACM, whatever content the app outputs, it's been treated as sRGB, which is somewhat OK for now.

For old-fashioned-and-will-to-self-color-managed-app, windows allow the user to bypass ACM like this. ![image](/attachments/97d49f98-46cf-412b-a500-2c6bc2271983) In ACM, apps want to display HDR signal or widegamut SDR signal, just use the APIs that MS provided to compose contents within the app, then send the tagged result to Desktop Window Manager (DWM). The OS will do the rest. Here's a briefed [guide](https://learn.microsoft.com/en-us/windows/win32/direct3darticles/high-dynamic-range) to integrate windows auto color management. AFAIK, there's only APIs for UWP, directX Apps being talked in this guide. I'm afraid that blender isn't a UWP app or DX app. However, if an app doesn't adpat to ACM, whatever content the app outputs, it's been treated as sRGB, which is somewhat OK for now.
166 KiB
Author
Contributor

but it doesn't mean that we can't implement a better clipping on our side

Interesting, but that would probably be a project of its own. What we did in our LUTs are kind of brute force, we simply calculate the data's original luminance, offset the data until there is no negative, calculate the change in luminance the offet caused, and restore the original luminance by multiplying. We also needed to do some color opponency hack to compensate for some camera-produced colorimetry having negative luminance.

If we get to implement this (or potentially some better method) in the future, it can work. But it will probably be its own project.

> but it doesn't mean that we can't implement a better clipping on our side Interesting, but that would probably be a project of its own. What we did in our LUTs are kind of brute force, we simply calculate the data's original luminance, offset the data until there is no negative, calculate the change in luminance the offet caused, and restore the original luminance by multiplying. We also needed to do some color opponency hack to compensate for some camera-produced colorimetry having negative luminance. If we get to implement this (or potentially some better method) in the future, it can work. But it will probably be its own project.
Author
Contributor

Closing this PR since we decided to do it incrementally

Closing this PR since we decided to do it incrementally
Zijun Zhou closed this pull request 2023-07-28 07:25:07 +02:00
Author
Contributor

Step 1 PR has been posted #110559

Step 1 PR has been posted #110559
Member

Most of what has been discussed here so far makes sense to me, aside from some subtleties that we may want to consider at some point. I'll post about those later when I have time to collect my thoughts better.

But the one thing I straightforwardly disagree with is using a pure 2.2 power function for the sRGB display. @Eary wrote:

I remember Filmlight did a survey about whether people calibrate to 2.2 or piece-wise more, the result, IIRC, was that most people nowadays calibrated their monitors to pure power function, instead of piece-wise function.

While that may be the case, if people are knowingly not calibrating to the standard, then they are probably doing so for a reason, knowing that some/all of their colors will still be encoded with the actual sRGB transfer function despite their display being calibrated to decode with a 2.2 power function. And if they are unknowingly failing to calibrate to the standard, then that's an issue of education.

Further, if some of the people that are knowingly not calibrating to the standard are doing so because some software they use also doesn't adhere to the standard, then that's an issue with the software. And I would prefer Blender to not become yet another software in that list.

Having said that, I am very sympathetic to people working with color-broken software. So if that is indeed one of the issues, then perhaps we should have two sRGB displays in the OCIO config: sRGB and sRGB non-standard: power 2.2. (Better naming suggestions for the latter very welcome.) Then people that are forced to mis-calibrate their displays due to other misbehaving software can still work in Blender appropriately, but the default would still be to properly adhere to the sRGB standard.

The downside of that, of course, would be potential user confusion for users not familiar with the situation. But if that's enough of a concern to leave one of the two options out, then IMO it should be the non-standard one that's omitted.

Most of what has been discussed here so far makes sense to me, aside from some subtleties that we may want to consider at some point. I'll post about those later when I have time to collect my thoughts better. But the one thing I straightforwardly disagree with is using a pure 2.2 power function for the sRGB display. @Eary wrote: > I remember Filmlight did a survey about whether people calibrate to 2.2 or piece-wise more, the result, IIRC, was that most people nowadays calibrated their monitors to pure power function, instead of piece-wise function. While that may be the case, if people are *knowingly* not calibrating to the standard, then they are probably doing so for a reason, knowing that some/all of their colors will still be encoded with the actual sRGB transfer function despite their display being calibrated to decode with a 2.2 power function. And if they are *unknowingly* failing to calibrate to the standard, then that's an issue of education. Further, if some of the people that are knowingly not calibrating to the standard are doing so because some software they use also doesn't adhere to the standard, then that's an issue with the software. And I would prefer Blender to not become yet another software in that list. Having said that, I am very sympathetic to people working with color-broken software. So if that is indeed one of the issues, then perhaps we should have two sRGB displays in the OCIO config: `sRGB` and `sRGB non-standard: power 2.2`. (Better naming suggestions for the latter very welcome.) Then people that are forced to mis-calibrate their displays due to other misbehaving software can still work in Blender appropriately, but the default would still be to properly adhere to the sRGB standard. The downside of that, of course, would be potential user confusion for users not familiar with the situation. But if that's enough of a concern to leave one of the two options out, then IMO it should be the non-standard one that's omitted.
Author
Contributor

if people are knowingly not calibrating to the standard, then they are probably doing so for a reason, knowing that some/all of their colors will still be encoded with the actual sRGB transfer function despite their display being calibrated to decode with a 2.2 power function. And if they are unknowingly failing to calibrate to the standard, then that's an issue of education.

The issue is, 2.2 is the actual standard for the display device:
image

The file encoding decided to specify something else to create a discrepancy between display and file encoding, for flare compensation. I think the video has already explained it clearly, so it's not an issue of education.

we should have two sRGB displays in the OCIO config: sRGB and sRGB non-standard: power 2.2

Except that 2.2 is the actual standard for the display device.

image

But we will go with piece-wise for this project, as confirmed by Sergey. Whether sRGB should be changed to 2.2 will be a discussion separated from this current one.

> if people are knowingly not calibrating to the standard, then they are probably doing so for a reason, knowing that some/all of their colors will still be encoded with the actual sRGB transfer function despite their display being calibrated to decode with a 2.2 power function. And if they are unknowingly failing to calibrate to the standard, then that's an issue of education. The issue is, 2.2 is the actual standard for the display device: ![image](/attachments/f446984b-c6d8-4a8c-a21c-523bf19e98d2) The file encoding decided to specify something else to create a discrepancy between display and file encoding, for flare compensation. I think [the video](https://www.youtube.com/watch?v=NzhUzeNUBuM&ab_channel=FilmLight) has already explained it clearly, so it's not an issue of education. >we should have two sRGB displays in the OCIO config: sRGB and sRGB non-standard: power 2.2 Except that 2.2 is the actual standard for the display device. ![image](/attachments/fc2f9c35-c5a6-4849-96f1-168058d8fd5b) But we will go with piece-wise for this project, as confirmed by Sergey. Whether sRGB should be changed to 2.2 will be a discussion separated from this current one.
254 KiB
393 KiB
Member

But we will go with piece-wise for this project, as confirmed by Sergey. Whether sRGB should be changed to 2.2 will be a discussion separated from this current one.

Yeah, that's a good approach. I still want to provide counterpoints for future reference (including for my own reference, since I've taken the time to dive into this now) for when that discussion happens. But feel free to ignore for now.

I've split this into two parts: "What does the standard specify?" and "Regardless, what should current practice be?"

What does the standard specify?

The issue is, 2.2 is the actual standard for the display device

So first off, it turns out you are absolutely right that the reference display from the standard has a plain 2.2 gamma, and I was mistaken in saying that a properly calibrated display would necessarily be calibrated to the piece-wise function. However, after diving into this I believe it is a significant misreading of the standard to also say that colors sent to the display should be encoded that way, rather than with the defined CIE XYZ -> sRGB transformation. The following is a (slightly long) summary of why I think that.

The 2.2 gamma is specified in a subsection of the standard titled "Reference image display system characteristics". But that subsection is part of a larger section, "Reference conditions", that also specifies (among other things) the reference ambient lighting of the viewing environment, which effects dark values.

So the "Reference conditions" section describes a holistic viewing situation which the standard believes will produce approximately the right perceptual experience when sRGB encoded colors (encoded with the piece-wise function) are sent to the display. The reference display subsection is not supposed to be taken in isolation.

The introductory text of the standard supports that interpretation:

There are two parts to the methodology described in this standard: the encoding transformations and the reference conditions. The encoding transformations provide all of the necessary information to encode an image for optimum display in the reference conditions.

In other words, the specified piece-wise encoding should be sent directly to the display for (they believe) accurate color rendering under the reference conditions.

And I think this is where the confusion starts. Immediately after that, the standards document says:

If actual conditions differ from reference conditions, additional rendering transformations may be required.

One interpretation of this is to say that as ambient lighting changes, the way the color is encoded should be changed as well. So, for example, in a darker viewing environment the encoding should converge on an actual gamma of 2.2 to match the reference display.

However, this ignores that the reference display is itself part of the reference conditions they're referring to, and is thus also subject to variability. So I think a more likely and reasonable interpretation of that bit is basically, "Hey, we know that both viewing environments and actual displays are variable, so you may need to compensate for that if you want accurate color reproduction."

So that just means that if you know the specifics of your actual display and actual viewing conditions, of course you should calibrate to that. (And notably this would include things like white point adaptation as well!) So sure, if you're viewing in a dark environment and your monitor is calibrated to 2.2 gamma, you should send your colors to it with a 2.2 gamma encoding. But that's because the conditions are deviating from the reference conditions, and in turn you are sending a non-sRGB signal to compensate for that deviation.

Having said all that, I acknowledge that the standard doesn't read super clearly on these points. And the video you linked to acknowledges that as well.

But it seems unlikely that the sRGB committee intended for there to be a separate encoding for files vs displays. The norm at the time was to just directly pipe the RGB values from an image or video file straight to the display. This was partly for efficiency, but also to avoid re-quantization artifacts. And it's hard to imagine them intending to upend that norm in an era where 8-bit-per-channel color was still competing with palettized color.

In fact, the technical secretary of the body that developed the sRGB standard spoke up on the topic:

The sRGB EOTF is not a simple gamma 2.2. The standard says the reference display is nominally gamma 2.2, but this is only an approximation. The normative relation between sRGB and CIE XYZ is specified in the standard using a two-part EOTF.
...
Applications that say they support sRGB must support it using the normative two-part EOTF to be conformant to the sRGB standard.
...
I have no objection to the circulation of a gamma 2.2 ODT intended for video mastering environments, but it will need to be different from the sRGB ODT and should not be called an sRGB ODT.

(Quote pulled from this overview, which is worth a read on its own, along with its comment section.)

Of course, as noted by Andrew Somers in the comment section, a statement from someone involved in creating the standard is not actually itself normative.

Nevertheless, I think it's a strained reading of the standard to say that the color data sent to the display is supposed to be gamma 2.2 encoded. That interpretation requires, among other things, ignoring the "Reference conditions" section as a holistic specification of viewing conditions.

Regardless, what should current practice be?

So, what the standard says is one thing, but how to achieve the best color reproduction is another. And the situation is complicated by that distinction. As far as I've been able to figure out, the current situation is as follows:

  1. With only a handful of exceptions, displays have generally followed the standard in terms of using a pure 2.2 gamma. With a viewing environment that also matches the standard, that implies sending piece-wise encoded sRGB color directly to the display to be standards compliant.
  2. However, the viewing environment often (usually?) doesn't match. Moreover, I think it's reasonable to doubt that the specified reference conditions are actually optimal for accurate color rendering via the specified XYZ -> sRGB -> reference conditions pipeline.
  3. People noticed less-than-ideal color reproduction due to point 2. And it turns out that just sending a 2.2 gamma-encoded signal to sRGB-calibrated displays (which, again, should—absent data about the viewing environment—be calibrated to 2.2 gamma according to the standard) often gives better results in practice.
  4. Some people decided that must mean that the standard intended for the sRGB signal to also be 2.2 gamma all along, and have been propagating that strained interpretation. Other people aren't pushing that strained interpretation, but rather recognize that following the standard isn't necessarily giving accurate results due to point 2. (I've watched the video you linked to a couple of times now, and I'm honestly still not sure which of these two categories they fall into.)

In short, as software developers we're now in a situation where we have to make a choice between either following the standard, or breaking from the standard but giving our users better color reproduction in many (most?) modern viewing conditions.

I'm honestly not sure what the right choice is here. At the very least I think we should be transparent if we don't follow the standard, and not use plain "sRGB" as the name of the display space if it doesn't use the piece-wise encoding. (And I recognize that you did originally use a modified name, @Eary, before being asked to change it.)

One hitch that @brecht pointed out is that Blender also uses the output display spaces for writing to files. So if we don't provide an sRGB output space with the piece-wise function, there would be no way for users to write proper sRGB image/video files from Blender.

It's also worth mentioning that Blender has a gamma setting for output already. So as long as we provide a linear sRGB/Rec.709 output, users who are in-the-know can use that and set the gamma to 2.2 if they wish.

> But we will go with piece-wise for this project, as confirmed by Sergey. Whether sRGB should be changed to 2.2 will be a discussion separated from this current one. Yeah, that's a good approach. I still want to provide counterpoints for future reference (including for my own reference, since I've taken the time to dive into this now) for when that discussion happens. But feel free to ignore for now. I've split this into two parts: "What does the standard specify?" and "Regardless, what should current practice be?" ### What does the standard specify? > The issue is, 2.2 is the actual standard for the display device So first off, it turns out you are absolutely right that the reference display from the standard has a plain 2.2 gamma, and I was mistaken in saying that a properly calibrated display would *necessarily* be calibrated to the piece-wise function. **However**, after diving into this I believe it is a significant misreading of the standard to also say that colors sent to the display should be encoded that way, rather than with the defined CIE XYZ -> sRGB transformation. The following is a (slightly long) summary of why I think that. The 2.2 gamma is specified in a subsection of the standard titled "Reference image display system characteristics". But that subsection is *part of a larger section*, "Reference conditions", that also specifies (among other things) the reference ambient lighting of the viewing environment, which effects dark values. So the "Reference conditions" section describes a *holistic viewing situation* which the standard believes will produce approximately the right perceptual experience when sRGB encoded colors (encoded with the piece-wise function) are sent to the display. The reference display subsection is *not supposed to be taken in isolation*. The introductory text of the standard supports that interpretation: > There are two parts to the methodology described in this standard: the encoding transformations and the reference conditions. The encoding transformations provide all of the necessary information to encode an image for optimum display in the reference conditions. In other words, the specified piece-wise encoding should be sent directly to the display for (they believe) accurate color rendering under the reference conditions. And I think this is where the confusion starts. Immediately after that, the standards document says: > If actual conditions differ from reference conditions, additional rendering transformations may be required. One interpretation of this is to say that as ambient lighting changes, the way the color is encoded should be changed as well. So, for example, in a darker viewing environment the encoding should converge on an actual gamma of 2.2 to match the reference display. However, this ignores that the reference display *is itself part of the reference conditions they're referring to*, and is thus also subject to variability. So I think a more likely and reasonable interpretation of that bit is basically, "Hey, we know that both viewing environments and actual displays are variable, so you may need to compensate for that if you want accurate color reproduction." So that just means that if you know the specifics of your actual display and actual viewing conditions, of course you should calibrate to that. (And notably this would include things like white point adaptation as well!) So sure, if you're viewing in a dark environment and your monitor is calibrated to 2.2 gamma, you should send your colors to it with a 2.2 gamma encoding. But that's because the conditions are *deviating* from the reference conditions, and in turn you are sending a *non-sRGB signal* to compensate for that deviation. Having said all that, I acknowledge that the standard doesn't read super clearly on these points. And the video you linked to acknowledges that as well. But it seems unlikely that the sRGB committee intended for there to be a separate encoding for files vs displays. The norm at the time was to just directly pipe the RGB values from an image or video file straight to the display. This was partly for efficiency, but also to avoid re-quantization artifacts. And it's hard to imagine them intending to upend that norm in an era where 8-bit-per-channel color was still competing with palettized color. In fact, the technical secretary of the body that developed the sRGB standard spoke up on the topic: > The sRGB EOTF is not a simple gamma 2.2. The standard says the reference display is nominally gamma 2.2, but this is only an approximation. The normative relation between sRGB and CIE XYZ is specified in the standard using a two-part EOTF. > ... > Applications that say they support sRGB must support it using the normative two-part EOTF to be conformant to the sRGB standard. > ... > I have no objection to the circulation of a gamma 2.2 ODT intended for video mastering environments, but it will need to be different from the sRGB ODT **and should not be called an sRGB ODT.** (Quote pulled from [this overview](https://www.colour-science.org/posts/srgb-eotf-pure-gamma-22-or-piece-wise-function/), which is worth a read on its own, along with its comment section.) Of course, as noted by Andrew Somers in the comment section, a statement from someone involved in creating the standard is not actually itself normative. Nevertheless, I think it's a strained reading of the standard to say that the color data sent to the display is supposed to be gamma 2.2 encoded. That interpretation requires, among other things, ignoring the "Reference conditions" section as a holistic specification of viewing conditions. ### Regardless, what should current practice be? So, what the standard says is one thing, but how to achieve the best color reproduction is another. And the situation is complicated by that distinction. As far as I've been able to figure out, the current situation is as follows: 1. With only a handful of exceptions, displays have generally followed the standard in terms of using a pure 2.2 gamma. With a viewing environment that also matches the standard, that implies sending *piece-wise* encoded sRGB color directly to the display to be standards compliant. 2. However, the viewing environment often (usually?) *doesn't* match. Moreover, I think it's reasonable to doubt that the specified reference conditions are *actually* optimal for accurate color rendering via the specified `XYZ -> sRGB -> reference conditions` pipeline. 3. People noticed less-than-ideal color reproduction due to point 2. And it turns out that just sending a 2.2 gamma-encoded signal to sRGB-calibrated displays (which, again, *should*&mdash;absent data about the viewing environment&mdash;be calibrated to 2.2 gamma according to the standard) often gives better results in practice. 4. Some people decided that must mean that the standard intended for the *sRGB signal* to also be 2.2 gamma all along, and have been propagating that strained interpretation. Other people aren't pushing that strained interpretation, but rather recognize that following the standard isn't necessarily giving accurate results due to point 2. (I've watched the video you linked to a couple of times now, and I'm honestly still not sure which of these two categories they fall into.) In short, as software developers we're now in a situation where we have to make a choice between either following the standard, or breaking from the standard but giving our users better color reproduction in many (most?) modern viewing conditions. I'm honestly not sure what the right choice is here. At the very least I think we should be *transparent* if we don't follow the standard, and not use plain "sRGB" as the name of the display space if it doesn't use the piece-wise encoding. (And I recognize that you did originally use a modified name, @Eary, before being asked to change it.) One hitch that @brecht pointed out is that Blender also uses the output display spaces for writing to files. So if we don't provide an sRGB output space with the piece-wise function, there would be no way for users to write proper sRGB image/video files from Blender. It's also worth mentioning that Blender has a gamma setting for output already. So as long as we provide a linear sRGB/Rec.709 output, users who are in-the-know can use that and set the gamma to 2.2 if they wish.
Author
Contributor

It's also worth mentioning that Blender has a gamma setting for output already. So as long as we provide a linear sRGB/Rec.709 output, users who are in-the-know can use that and set the gamma to 2.2 if they wish.

This is only true if we will never change the working space to BT.2020 or ACEScg in the future. The Raw or None view is not supposed to change primaries, it's supposed to be a straight output of working space values.

I'm honestly not sure what the right choice is here.

I agree this is a very complicated topic.

> It's also worth mentioning that Blender has a gamma setting for output already. So as long as we provide a linear sRGB/Rec.709 output, users who are in-the-know can use that and set the gamma to 2.2 if they wish. This is only true if we will never change the working space to BT.2020 or ACEScg in the future. The `Raw` or `None` view is not supposed to change primaries, it's supposed to be a straight output of working space values. > I'm honestly not sure what the right choice is here. I agree this is a very complicated topic.
Member

This is only true if we will never change the working space to BT.2020 or ACEScg in the future.

Or if we explicitly provide a linear sRGB/Rec.709 output display transform, which is the possibility I was suggesting. I don't necessarily think that's a good solution, but I wanted to point it out as an option just to cover our bases.

> This is only true if we will never change the working space to BT.2020 or ACEScg in the future. Or if we explicitly provide a linear sRGB/Rec.709 output display transform, which is the possibility I was suggesting. I don't necessarily think that's a *good* solution, but I wanted to point it out as an option just to cover our bases.
Author
Contributor

Step 2 PR has been posted #110712

Step 2 PR has been posted #110712
First-time contributor

In fact, the technical secretary of the body that developed the sRGB standard spoke up on the topic:

Let it be known that the history of sRGB is dark and riddled with more politics than Game of Thrones. I’d be extremely cautious reading any sort of anything into anything without discussion with the primary author. So political in fact, that one participant left all of colour because of it. No one around this era should be treated as authoritative beyond the primary author, should you manage to speak with them.

The specification is clear, and we have the paper to go by. The reference display is pure 2.2, and the encoding is the two part.

a statement from someone involved in creating the standard is not actually itself normative.

It is a tremendous leap to suggest that this individual was involved in the creation of the standard. Unless one has spoken with the primary authorship, it is fair to suggest all parties are hostile.

No amount of tagging the image will help here. The main issue is that there’s a sort of baked-in oddball chain on the two primary platforms that flips meaning if someone characterizes their display.

By default on macOS and Windows (although I can’t confirm more recent versions):

  1. The display is tagged with the sRGB two part OETF as an EOTF.
  2. Untagged files are assumed two part sRGB OETF encoded.
  3. The management library negotiates the difference, which in this case is a no operation, so passes, leaving the file encoded as two part sRGB OETF.
  4. The management library hands the two part sRGB OETF off to the display which is actually a pure 2.2 power function.

Canonized, by the book sRGB specification handling; a two part OETF passed through a pure 2.2 power function that yields a discrepancy between the OETF and the EOTF.

In the case of a characterized system, and assuming a managed loading of an untagged file:

  1. The display is tagged with the proper characterization EOTF, which is a pure 2.2 power function in the majority of cases.
  2. The untagged file is assumed sRGB two part OETF encoded.
  3. The management layer will decode the file to uniform colourimetry, and re-encode it to the displays inverse EOTF, which in this case would be a power function with an exponent of 1.0 / 2.2 broadly.
  4. The management library hands the inverse EOTF encoded buffer to the display, which decodes it using the 2.2 power function. This leads to a no operation between the re-encoding of stage 3., and the output display here at 4.

Phew.

> In fact, the technical secretary of the body that developed the sRGB standard spoke up on the topic: Let it be known that the history of sRGB is dark and riddled with more politics than Game of Thrones. I’d be extremely cautious reading any sort of anything into anything without discussion with the primary author. So political in fact, that one participant left all of colour because of it. No one around this era should be treated as authoritative beyond the primary author, should you manage to speak with them. The specification is clear, and we have the paper to go by. The reference display is pure 2.2, and the encoding is the two part. > a statement from someone involved in creating the standard is not actually itself normative. It is a tremendous leap to suggest that this individual was involved in the creation of the standard. Unless one has spoken with the primary authorship, it is fair to suggest all parties are hostile. — No amount of tagging the image will help here. The main issue is that there’s a sort of baked-in oddball chain on the two primary platforms that flips meaning if someone characterizes their display. By default on macOS and Windows (although I can’t confirm more recent versions): 1. The display is tagged with the sRGB two part OETF as *an EOTF*. 2. Untagged files are assumed two part sRGB OETF encoded. 3. The management library negotiates the difference, which in this case is a no operation, so passes, leaving the file encoded as two part sRGB OETF. 4. The management library hands the two part sRGB OETF off to the display which is *actually* a pure 2.2 power function. Canonized, by the book sRGB specification handling; a two part OETF passed through a pure 2.2 power function that yields a discrepancy between the OETF and the EOTF. In the case of a characterized system, and assuming a managed loading of an untagged file: 1. The display is tagged with the proper characterization EOTF, which is a pure 2.2 power function in the majority of cases. 2. The untagged file is assumed sRGB two part OETF encoded. 3. The management layer will decode the file to uniform colourimetry, and re-encode it to the displays inverse EOTF, which in this case would be a power function with an exponent of `1.0 / 2.2` broadly. 4. The management library hands the inverse EOTF encoded buffer to the display, which decodes it using the 2.2 power function. This leads to a no operation between the re-encoding of stage 3., and the output display here at 4. Phew.
Author
Contributor

Step 3 PR has been posted #110913

Step 3 PR has been posted #110913
Author
Contributor

Step 4 PR has been posted #110941

Step 4 PR has been posted #110941
First-time contributor

Flagging this commit as a problem.

Great patch to add in Apple EDR processing, but author appears to be conflating picture formation and encoding for HDR signals.

This will effectively be problematic as Apple’s encoding is expecting the macOS encoding which applies unique meaning to values beyond the closed domain encoded signal encapsulation of 0-100% for a given encoding.

This would require another unique transformation to encode to this specific encoding, from such encodings as BT.2100 via standard HLG or ST.2084 encodings.

https://projects.blender.org/blender/blender/commit/2367ed2ef24

Flagging [this commit](https://projects.blender.org/blender/blender/commit/2367ed2ef24) as a problem. Great patch to add in Apple EDR processing, but author appears to be conflating picture formation and encoding for HDR signals. This will effectively be problematic as Apple’s encoding is expecting the macOS encoding which applies unique meaning to values beyond the closed domain encoded signal encapsulation of 0-100% for a given encoding. This would require *another* unique transformation to encode to this specific encoding, from such encodings as BT.2100 via standard HLG or ST.2084 encodings. https://projects.blender.org/blender/blender/commit/2367ed2ef24
Author
Contributor

Step 5 PR has been posted #111099

Step 5 PR has been posted #111099

@troy_s This is a step towards the proper HDR. We are using an extended sRGB for it, and this is how we advertize the buffers to the OS compositor (which takes care of the actual display transform). I can see how this is not very ideal from the HDR content creation point of view, but this is just a first step in the project.

So to me it is not immediatelly obvious how the commit is wrong. If you have some concrete suggestions it will be good to know.

@troy_s This is a step towards the proper HDR. We are using an extended sRGB for it, and this is how we advertize the buffers to the OS compositor (which takes care of the actual display transform). I can see how this is not very ideal from the HDR content creation point of view, but this is just a first step in the project. So to me it is not immediatelly obvious how the commit is wrong. If you have some concrete suggestions it will be good to know.

@troy_s that commit is just one step towards full HDR support. It changes the output from sRGB to Extended sRGB, which works fine with the Standard view transform. Someone could design a film-like view transform for Extended sRGB, and I don't think there would be anything macOS specific about that. It would work fine on other operating systems too if we add HDR support.

But HDR displays and file formats typically come with wider gamut, so it would be better to have Blender support a Rec.2100 HLG and PQ display with a view transform designed for that. That would be the second step towards full HDR support.

@troy_s that commit is just one step towards full HDR support. It changes the output from sRGB to Extended sRGB, which works fine with the Standard view transform. Someone could design a film-like view transform for Extended sRGB, and I don't think there would be anything macOS specific about that. It would work fine on other operating systems too if we add HDR support. But HDR displays and file formats typically come with wider gamut, so it would be better to have Blender support a Rec.2100 HLG and PQ display with a view transform designed for that. That would be the second step towards full HDR support.
First-time contributor

For the record, I agree with both of you @brecht and @Sergey; it is a great step to getting the lower level pieces in place.

I am not entirely sure how to even encode for signals here though. I believe we can specify the transfer function of the encoding on macOS. The “system” mode is not terribly useful here, because it assigns unique meaning to negatives (via scRGB yuck) and greater than 100%, and it floats with system brightness changes, etc.

Given that the basics seem to be in place, the shortest path to offering HDR to Blender folks is probably a shorter path than many folks might assume; HLG.

I have tested AgX with HLG more or less “as is” with a slightly shifted “middle” point, and the output works rather remarkably well. From the macOS side, it would require changing the buffer type from the (nightmare fuel) scRGB to an HLG encoding via the CAEDRMetadata field I believe?

Perhaps this can be experimented with as it might be a really nice little feature to tuck in.

My concern with exposing any EDR in the current manner is that literally none of the picture formation techniques are geared toward the desktop implementation for macOS. A slight tweak could make for a pretty great addition.

For the record, I agree with both of you @brecht and @Sergey; it is a great step to getting the lower level pieces in place. I am not entirely sure how to even encode for signals here though. I *believe* we can specify the transfer function of the encoding on macOS. The “system” mode is not terribly useful here, because it assigns unique meaning to negatives (via scRGB yuck) and greater than 100%, and it floats with system brightness changes, etc. Given that the basics seem to be in place, the shortest path to offering HDR to Blender folks is probably a shorter path than many folks might assume; HLG. I have tested AgX with HLG more or less “as is” with a slightly shifted “middle” point, and the output works rather remarkably well. From the macOS side, it would require changing the buffer type from the (nightmare fuel) scRGB to an HLG encoding via the `CAEDRMetadata` field I believe? Perhaps this can be experimented with as it might be a really nice little feature to tuck in. My concern with exposing any EDR in the current manner is that literally none of the picture formation techniques are geared toward the desktop implementation for macOS. A slight tweak could make for a pretty great addition.

Changing the buffer type is unfortunately not a simple change. It requires significant changes to draw UI elements and renders into a single wide gamut buffer correctly.

Changing the buffer type is unfortunately not a simple change. It requires significant changes to draw UI elements and renders into a single wide gamut buffer correctly.
First-time contributor

Fair point. I was under the impression that the various buffers can be composited together, which would place the onus on the picture buffer only.

Even with all of the UI complexities, HLG still feels the most direct route as it is backwards compatible with standard output encodings, allowing for everything to remain “as is” and only require a matrix and the final tweak to get to HLG.

The HLG route would seem an order of a magnitude more manageable than ST.2084, as again, nothing really needs to change. With ST.2084, I could see that project taking years. HLG is likely vastly closer to a workable solution?

Fair point. I was under the impression that the various buffers can be composited together, which would place the onus on the picture buffer only. Even with all of the UI complexities, HLG still feels the most direct route as it is backwards compatible with standard output encodings, allowing for everything to remain “as is” and only require a matrix and the final tweak to get to HLG. The HLG route would seem an order of a magnitude more manageable than ST.2084, as again, nothing really needs to change. With ST.2084, I could see that project taking years. HLG is likely vastly closer to a workable solution?

I don't know why PQ (ST.2084) would be much more complicated than HLG. They both raise questions about how to scale the HDR content, in absolute terms and relative to the SDR UI elements. It seems a bit complicated and underspecified, though following conventions and interpreting metadata we can do something reasonable.

Regardless, HLG output would be the most important thing for Blender, and those targeting cinema with PQ will use some other software to grade and encode that anyway.

I don't know why PQ (ST.2084) would be much more complicated than HLG. They both raise questions about how to scale the HDR content, in absolute terms and relative to the SDR UI elements. It seems a bit [complicated and underspecified](https://bugs.chromium.org/p/chromium/issues/detail?id=1339333#c19), though following conventions and interpreting metadata we can do something reasonable. Regardless, HLG output would be the most important thing for Blender, and those targeting cinema with PQ will use some other software to grade and encode that anyway.
First-time contributor

I don't know why PQ (ST.2084) would be much more complicated than HLG.

It’s the rather elegant nature of the HLG signal being designed from the ground up to be “backwards compatible” in terms of the transfer function. That is, aside from the primaries, the transfer characteristic more or less “Just Works”.

Whereas ST.2084 requires a complete re-engineering.

I estimate out of my ass that Blender could be migrated to HDR 100% across the board without much tweaking using a sort of HLG alignment model. It is probably a rather limited effort of a few focused minds. Happy to help here if anyone feels the desire to make this a trial. The Apple patch notwithstanding, as that requires some serious thought due to the way the system level encoding works.

90% of the problem is dissolving the idea of “scene” and “display”, and thinking in terms of formed pictures versus unformed pictures. UI and such snaps together much more reasonably under such a mental model.

Anyways, I’m very optimistic that an HLG inspired approach could work well.

Regardless, HLG output would be the most important thing for Blender, and those targeting cinema with PQ will use some other software to grade and encode that anyway.

HLG would provide a nice “picture constancy” baseline for ST.2084 content, without much trim pass manipulation. I can say this reasonably confidently as I’ve done quite a bit of testing via the AgX mechanic on this very subject, and it passes. It is shockingly solid.

> I don't know why PQ (ST.2084) would be much more complicated than HLG. It’s the rather elegant nature of the HLG signal being designed from the ground up to be “backwards compatible” in terms of the transfer function. That is, aside from the primaries, the transfer characteristic more or less “Just Works”. Whereas ST.2084 requires a complete re-engineering. I *estimate* out of my ass that Blender could be migrated to HDR 100% across the board without much tweaking using a sort of HLG alignment model. It is probably a rather limited effort of a few focused minds. Happy to help here if anyone feels the desire to make this a trial. The Apple patch notwithstanding, as that requires some serious thought due to the way the system level encoding works. 90% of the problem is dissolving the idea of “scene” and “display”, and thinking in terms of formed pictures versus unformed pictures. UI and such snaps together much more reasonably under such a mental model. Anyways, I’m *very* optimistic that an HLG inspired approach could work well. > Regardless, HLG output would be the most important thing for Blender, and those targeting cinema with PQ will use some other software to grade and encode that anyway. HLG would provide a nice “picture constancy” baseline for ST.2084 content, without much trim pass manipulation. I can say this *reasonably* confidently as I’ve done quite a bit of testing via the AgX mechanic on this very subject, and it passes. It is shockingly solid.

My understanding is that with sufficient metadata, converting between HLG and PQ is a straightforward operation, no re-engineering required. But anyways, this is getting off topic too much.

My understanding is that with sufficient metadata, converting between HLG and PQ is a straightforward operation, no re-engineering required. But anyways, this is getting off topic too much.
Author
Contributor

The last PR has been posted: #111380

The last PR has been posted: #111380
First-time contributor

Thanks for the testings!

A lot of images are now rendering noticably brighter, even though they do not use any image textures and use Standard view transform.

I believe this is due to the fact that we switched to the pure power function sRGB in this patch, rather than the piece-wise sRGB we have been using. If we decide to change it back to piece-wise, I can do that quite easily but I also want to type out my reasonings here for the record.

FilmLight has a video on the topic: https://www.youtube.com/watch?v=NzhUzeNUBuM&ab_channel=FilmLight

The sRGB standard specified a pure power 2.2 display device, but a peice-wise linear+2.4 function for the file encoding, the reason is to implicitly include a flare compensation for CRT displays. It's been explained in the video I posted above:
image

The result, as I have writtem here before, would be:

  1. sRGB 2.2 values being displayed on piece-wise calibrated monitor, shadow gets a little tiny bit brighter
  2. sRGB 2.2 values being displayed 2.2 calibrated monitor, displayed as intended.

VS if we use piece-wise function:

  1. sRGB piece-wise value on being displayed on 2.2 calibrated monitor, resulting in shadows getting crushed. (was the ideal behavior in old-school CRT color management, but not anymore in modern color managment workflow)
  2. sRGB piece-wise value on being displayed on piece-wise calibrated monitor, properly displayed.

FilmLight also included a survey they did:
lALPM4AfHpjgvyrNBDjNB4A_1920_1080

From the survey, most people assume sRGB to be pure power 2.2. Therefore most people actually saw the shadows get crushed by default when using piece-wise sRGB.

image

That's why I believe moving to pure 2.2 is a good choice, I also made it explicit that I was using a 2.2 curve by naming the space sRGB 2.2, but Brecht requested to rename it back to sRGB, therefore I did.

I would like to confirm the decision, are we reverting back to piece-wise sRGB? If answer is yes, will commit

This is interesting because neither view nor look transform are supposed to be applied. Additionally, enabling View as Render and View Transform set to Standard does not change the look in the main branch, but changes the look by quite a lot with this patch.

I believe this is because the Guard Rail view transform has been set to the first one on the list, and that was an intentional choice as well. Again, if it's requested to put Standard back to the first on the list, it's an easy change. But I again would like to type out my reasonings for the record.

This one is simpler, because I would like users to see this by default when dragging their HDRI to the image editor:
image

Instead of this skewing to cyan sky:
image

Since Guard Rail means the fence on the edge of the cliff to prevent colors from falling into accidental skewings, it was designed to be the default. It also doesn't impact the texture preview functionality so I thought it should be fine.

But again, if you confirm we still want Standard to be the default, will commit.

Thing I am not sure about is the reference space change. I am not sure whether it is somehow required for the AgX transform to work, or whether it is more of a future-proofing for possible spectral story.

Partially for the spectral branch. But it's also more straight forward for the definition of the color spaces.

If we want to define the BT.2020 space in the config shipped with 3.6, we need to convert Linear BT.709 to Linear CIE-XYZ I-D65, and then apply the standard XYZ to RGB matrix for BT.2020. Practically you can of course combine the two matrix into one mathmatically, but in principle, CIE XYZ is just where all RGB spaces are defined down to the root. So it makes more sense to work from ground up, instead climbing down from the BT.709 tree branch to the XYZ root, and then climb up to another space branch every time. The use of I-E white point is also trying to provide the needed option for spectral branch. It's also more reasonable because the actual CIE standard XYZ has always been I-E (Resolve's CIE XYZ space is also I-E. If user exports EXR with CIE XYZ encoding and want to import into Resolve, they need to use the I-E one).

If we are requested to revert the reference space back to Linear BT.709 I-D65, it can be done, but a bit more troublesome than the first two items.

So summerize the decision we need to make here:

  1. sRGB, pure power function (what most people are using) or piece-wise (the old-school "standard")?
  2. The first view transform on the list, Guard Rail or Standard?
  3. Keep Linear CIE-XYZ I-E being the reference or Linear BT.709 I-D65 as reference?

Hello Zijun, the Guard Rail looks what I'm looking for, we are doing product design rendering with Blender, we had to say "filmic sucks" , and we saw many render artist in commuinty also don't like filmic , it make the final image lost color details and looks very "cheap" camparing other render engine. we want an improved version of "Standard".

So how can I download and test the Guard Rail config? please help.

> Thanks for the testings! > > > A lot of images are now rendering noticably brighter, even though they do not use any image textures and use Standard view transform. > > I believe this is due to the fact that we switched to the pure power function sRGB in this patch, rather than the piece-wise sRGB we have been using. If we decide to change it back to piece-wise, I can do that quite easily but I also want to type out my reasonings here for the record. > > FilmLight has a video on the topic: https://www.youtube.com/watch?v=NzhUzeNUBuM&ab_channel=FilmLight > > The sRGB standard specified a pure power 2.2 display device, but a peice-wise linear+2.4 function for the file encoding, the reason is to implicitly include a flare compensation for CRT displays. It's been explained in the video I posted above: > ![image](/attachments/d505124f-48a2-4375-9368-644b40d7dfa9) > > The result, as I have writtem here before, would be: > > > 1. sRGB 2.2 values being displayed on piece-wise calibrated monitor, shadow gets a little tiny bit brighter > > 2. sRGB 2.2 values being displayed 2.2 calibrated monitor, displayed as intended. > > > > VS if we use piece-wise function: > > > > 1. sRGB piece-wise value on being displayed on 2.2 calibrated monitor, resulting in shadows getting crushed. (was the ideal behavior in old-school CRT color management, but not anymore in modern color managment workflow) > > 2. sRGB piece-wise value on being displayed on piece-wise calibrated monitor, properly displayed. > > FilmLight also included a survey they did: > ![lALPM4AfHpjgvyrNBDjNB4A_1920_1080](/attachments/d8b1a90a-2971-4cc9-b4da-6c1f864516ab) > > From the survey, most people assume sRGB to be pure power 2.2. Therefore most people actually saw the shadows get crushed by default when using piece-wise sRGB. > > ![image](/attachments/5ec5cf54-b884-4f34-94a7-222736e6083c) > > That's why I believe moving to pure 2.2 is a good choice, I also made it explicit that I was using a 2.2 curve by naming the space `sRGB 2.2`, but [Brecht requested to rename it back to `sRGB`](https://projects.blender.org/blender/blender/pulls/106355#issuecomment-911981), therefore I did. > > I would like to confirm the decision, are we reverting back to piece-wise sRGB? If answer is yes, will commit > > > This is interesting because neither view nor look transform are supposed to be applied. Additionally, enabling View as Render and View Transform set to Standard does not change the look in the main branch, but changes the look by quite a lot with this patch. > > I believe this is because the `Guard Rail` view transform has been set to the first one on the list, and that was an intentional choice as well. Again, if it's requested to put `Standard` back to the first on the list, it's an easy change. But I again would like to type out my reasonings for the record. > > This one is simpler, because I would like users to see this by default when dragging their HDRI to the image editor: > ![image](/attachments/729dcdcb-9085-44da-a368-e345820ad867) > > Instead of this skewing to cyan sky: > ![image](/attachments/b625bc2b-6f17-43bc-9d31-941014c959f2) > > Since `Guard Rail` means the fence on the edge of the cliff to prevent colors from falling into accidental skewings, it was designed to be the default. It also doesn't impact the texture preview functionality so I thought it should be fine. > > But again, if you confirm we still want `Standard` to be the default, will commit. > > >Thing I am not sure about is the reference space change. I am not sure whether it is somehow required for the AgX transform to work, or whether it is more of a future-proofing for possible spectral story. > > Partially for the spectral branch. But it's also more straight forward for the definition of the color spaces. > > If we want to define the BT.2020 space in the config shipped with 3.6, we need to convert Linear BT.709 to Linear CIE-XYZ I-D65, and then apply the standard XYZ to RGB matrix for BT.2020. Practically you can of course combine the two matrix into one mathmatically, but in principle, CIE XYZ is just where all RGB spaces are defined down to the root. So it makes more sense to work from ground up, instead climbing down from the BT.709 tree branch to the XYZ root, and then climb up to another space branch every time. The use of I-E white point is also trying to provide the needed option for spectral branch. It's also more reasonable because the actual CIE standard XYZ has always been I-E (Resolve's CIE XYZ space is also I-E. If user exports EXR with CIE XYZ encoding and want to import into Resolve, they need to use the I-E one). > > If we are requested to revert the reference space back to Linear BT.709 I-D65, it can be done, but a bit more troublesome than the first two items. > > So summerize the decision we need to make here: > 1. sRGB, pure power function (what most people are using) or piece-wise (the old-school "standard")? > 2. The first view transform on the list, `Guard Rail` or `Standard`? > 3. Keep Linear CIE-XYZ I-E being the reference or Linear BT.709 I-D65 as reference? > Hello Zijun, the Guard Rail looks what I'm looking for, we are doing product design rendering with Blender, we had to say "filmic sucks" , and we saw many render artist in commuinty also don't like filmic , it make the final image lost color details and looks very "cheap" camparing other render engine. we want an improved version of "Standard". So how can I download and test the Guard Rail config? please help.
First-time contributor

I hope this approach would get perhaps 2 new operators which would set all the textures/images in a scene to either agx or filmic approach. It would be very useful on big scenes. Transition from one to the other will be a huge undertaking doing it manually. An operator can solve this in just seconds I believe

I hope this approach would get perhaps 2 new operators which would set all the textures/images in a scene to either agx or filmic approach. It would be very useful on big scenes. Transition from one to the other will be a huge undertaking doing it manually. An operator can solve this in just seconds I believe
Member

@RomboutVersluijs a python script using Blender's python interface is probably an easier way to do this.

But just for reference, textures being set to the Agx or Filmic colour space seem to have relatively limited use cases in the material creation pipeline (one of the most common places where textures are used). So if you need to change many textures between these two colour spaces, then it may be possible you're using the colour spaces incorrectly. But I could be wrong about it.

@RomboutVersluijs a python script using Blender's python interface is probably an easier way to do this. But just for reference, textures being set to the Agx or Filmic colour space seem to have relatively limited use cases in the material creation pipeline (one of the most common places where textures are used). So if you need to change many textures between these two colour spaces, then it may be possible you're using the colour spaces incorrectly. But I could be wrong about it.
Member

@RomboutVersluijs here are two python scripts for doing what I mentioned above. Attached to the bottom of this comment is a video showing how to use it.

Convert to AGX Base (Changes all "Filmic sRGB" texture nodes to "AGX Base sRGB". If the colour space of the texture node is not set to "Filmic sRGB", then it won't be converted.)

import bpy

bpy.context.scene.view_settings.view_transform = "AgX"

for image in bpy.data.images:
    if image.colorspace_settings.name == 'Filmic sRGB':
        image.colorspace_settings.name = 'AgX Base sRGB'

Convert to Filmic (Changes all "AGX Base" texture nodes to "Filmic sRGB". If the colour space of the texture node is not set to "AGX Base", then it won't be converted.)

import bpy

bpy.context.scene.view_settings.view_transform = "Filmic"

for image in bpy.data.images:
    if image.colorspace_settings.name == 'AgX Base sRGB':
        image.colorspace_settings.name = "Filmic sRGB"
@RomboutVersluijs here are two python scripts for doing what I mentioned above. Attached to the bottom of this comment is a video showing how to use it. Convert to AGX Base (Changes all "Filmic sRGB" texture nodes to "AGX Base sRGB". If the colour space of the texture node is not set to "Filmic sRGB", then it won't be converted.) ``` import bpy bpy.context.scene.view_settings.view_transform = "AgX" for image in bpy.data.images: if image.colorspace_settings.name == 'Filmic sRGB': image.colorspace_settings.name = 'AgX Base sRGB' ``` Convert to Filmic (Changes all "AGX Base" texture nodes to "Filmic sRGB". If the colour space of the texture node is not set to "AGX Base", then it won't be converted.) ``` import bpy bpy.context.scene.view_settings.view_transform = "Filmic" for image in bpy.data.images: if image.colorspace_settings.name == 'AgX Base sRGB': image.colorspace_settings.name = "Filmic sRGB" ```

Pull request closed

Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
15 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#106355
No description provided.