False color look gives incorrect values #98405

New Issue

tempdevnova · 2022-05-26T16:08:36+02:00

tempdevnova commented

2022-05-26 16:08:36 +02:00

System Information
Operating system: Windows-10-10.0.19043-SP0 64 Bits
Graphics card: GeForce GTX 1080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 431.07

Blender Version
Broken: version: 3.3.0 Alpha, branch: master, commit date: 2022-05-02 10:21, hash: e07ac34b3f
Worked: (newest version of Blender that worked as expected)

Short description of error
The False color in Blender is indeed different from the Filmic master on GitHub:

Exact steps for others to reproduce the error
The testing EXR I used (background is 0.18 middle grey):

Load image in Image editor
Enable View as Render in side panel
Set False Color as View Transform in Color Management settings

**System Information** Operating system: Windows-10-10.0.19043-SP0 64 Bits Graphics card: GeForce GTX 1080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 431.07 **Blender Version** Broken: version: 3.3.0 Alpha, branch: master, commit date: 2022-05-02 10:21, hash: `e07ac34b3f` Worked: (newest version of Blender that worked as expected) **Short description of error** The False color in Blender is indeed different from the Filmic master on GitHub: ![image.png](https://archive.blender.org/developer/F13110187/image.png) **Exact steps for others to reproduce the error** The testing EXR I used (background is 0.18 middle grey): ![Sweep_sRGB_Linear_Full.exr](https://archive.blender.org/developer/F13110196/Sweep_sRGB_Linear_Full.exr) - Load image in Image editor - Enable View as Render in side panel - Set False Color as View Transform in Color Management settings

tempdevnova commented

2022-05-26 16:08:36 +02:00

Added subscriber: @tempdevnova

Riccardo Giovanetti commented

2022-05-26 16:51:42 +02:00

Added subscriber: @Harvester

Riccardo Giovanetti commented

2022-05-26 16:51:42 +02:00

Here on

System Information
Operating system: Windows-10-10.0.19043-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 512.96

Blender version: 3.3.0 Alpha, branch: master, commit date: 2022-05-25 21:21, hash: dc6fe73e70
Blender version: 3.2.0 Beta, branch: master, commit date: 2022-05-25 13:09, hash: 841a354412
Blender version: 3.1.2, branch: master, commit date: 2022-03-31 17:40, hash: cc66d1020c
Blender version: 2.93.9, branch: master, commit date: 2022-04-19 14:25, hash: 31712ce77a

The False Colour scheme, as per your test file, looks similar if not identical in all the above Blender versions, so the issue you're raising is compared to what "expected" False Colour results? The only difference I can notice is in Blender 2.83.20LTS (see the following screenshots):

Here on **System Information** Operating system: Windows-10-10.0.19043-SP0 64 Bits Graphics card: NVIDIA GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 512.96 Blender version: 3.3.0 Alpha, branch: master, commit date: 2022-05-25 21:21, hash: `dc6fe73e70` Blender version: 3.2.0 Beta, branch: master, commit date: 2022-05-25 13:09, hash: `841a354412` Blender version: 3.1.2, branch: master, commit date: 2022-03-31 17:40, hash: `cc66d1020c` Blender version: 2.93.9, branch: master, commit date: 2022-04-19 14:25, hash: `31712ce77a` The False Colour scheme, as per your test file, looks similar if not identical in all the above Blender versions, so the issue you're raising is compared to what "expected" False Colour results? The only difference I can notice is in Blender 2.83.20LTS (see the following screenshots): ![T98405_false_colour_Blender_versions.jpg](https://archive.blender.org/developer/F13109289/T98405_false_colour_Blender_versions.jpg) ![T98405_false_colour_Blender_283lts.jpg](https://archive.blender.org/developer/F13109292/T98405_false_colour_Blender_283lts.jpg)

tempdevnova commented

2022-05-26 17:08:45 +02:00

Added subscriber: @troy_s

tempdevnova commented

2022-05-26 17:08:45 +02:00

The False Colour scheme, as per your test file, looks similar if not identical in all the above Blender versions, so the issue you're raising is compared to what "expected" False Colour results?
As documented on @troy_s Github page for Filmic: https://github.com/sobotka/filmic-blender the gray value should represent 18% middle gray, which would be RGB values 0.18 ; 0.18 ; 0.18.
However as can be seen on the Blue stripe the if R=0 and G=0 then the gray value way overshoots to B=40.0
I am not sure if this is intended but I can't imagine how brightness values that high could still be considered middle gray.

`The False Colour scheme, as per your test file, looks similar if not identical in all the above Blender versions, so the issue you're raising is compared to what "expected" False Colour results?` As documented on @troy_s Github page for Filmic: https://github.com/sobotka/filmic-blender the gray value should represent 18% middle gray, which would be RGB values 0.18 ; 0.18 ; 0.18. However as can be seen on the Blue stripe the if R=0 and G=0 then the gray value way overshoots to B=40.0 I am not sure if this is intended but I can't imagine how brightness values that high could still be considered `middle gray`.

Troy Sobotka commented

2022-05-26 19:02:36 +02:00

Added subscribers: @Fastfinger, @Eary

Troy Sobotka commented

2022-05-26 19:02:36 +02:00

Adding the very capable @Eary and @Fastfinger to this. They may be able to confirm whether something is going off.

Also bear in mind that the absolute accuracy of the False Colour will be subject to some errors, due to the fact that it is a 65 cube 3D LUT and the domain where the luminance weighting transform is applied.

Adding the very capable @Eary and @Fastfinger to this. They may be able to confirm whether something is going off. Also bear in mind that the absolute accuracy of the False Colour will be subject to some errors, due to the fact that it is a 65 cube 3D LUT and the domain where the luminance weighting transform is applied.

Zijun Zhou commented

2022-05-26 20:01:05 +02:00

The False color in Blender is indeed different from the Filmic master on GitHub:

The testing EXR I used (background is 0.18 middle grey):

But AFAIK the false color in Blender has been redesigned, as you can see the orginal False Colour was supposed to be a Look, and yet the False Color in Blender is a View. I am not sure whether the difference is due to that, or whether the difference is by design, but I can comfirm there is indeed a difference between the original False Colour of Filmic vs False Color in Blender.

The False color in Blender is indeed different from the Filmic master on GitHub: ![image.png](https://archive.blender.org/developer/F13110187/image.png) The testing EXR I used (background is 0.18 middle grey): ![Sweep_sRGB_Linear_Full.exr](https://archive.blender.org/developer/F13110196/Sweep_sRGB_Linear_Full.exr) But AFAIK the false color in Blender has been redesigned, as you can see the orginal False Colour was supposed to be a Look, and yet the False Color in Blender is a View. I am not sure whether the difference is due to that, or whether the difference is by design, but I can comfirm there is indeed a difference between the original False Colour of Filmic vs False Color in Blender.

tempdevnova commented

2022-05-26 20:43:10 +02:00

Actually what was bothering me was that it returned gray for a Blue value of 40 which I think definetely is way to high to be middle gray.

Zijun Zhou commented

2022-05-26 23:04:37 +02:00

In #98405#1364943, @tempdevnova wrote:
it returned gray for a Blue value of 40 which I think definetely is way to high to be middle gray.

About this though, this is rather expected, as perceptually blue color with the same emission intensity would look darker than green, so the RGB to BW Transform takes that into account.

You can try it out yourself in the compositor:
False Colour From Filmic Master from GitHub:

False Color From Blender:

(You can see though they are different, the Grey for blue is indeed still 40ish for both versions.)
Filmic Base Contrast Look:

> In #98405#1364943, @tempdevnova wrote: > it returned gray for a Blue value of 40 which I think definetely is way to high to be middle gray. About this though, this is rather expected, as perceptually blue color with the same emission intensity would look darker than green, so the `RGB to BW` Transform takes that into account. You can try it out yourself in the compositor: False Colour From Filmic Master from GitHub: ![image.png](https://archive.blender.org/developer/F13110967/image.png) False Color From Blender: ![image.png](https://archive.blender.org/developer/F13111008/image.png) (You can see though they are different, the Grey for blue is indeed still 40ish for both versions.) Filmic Base Contrast Look: ![image.png](https://archive.blender.org/developer/F13110971/image.png)

Richard Antalik commented

2022-05-27 00:34:07 +02:00

Added subscriber: @iss

Richard Antalik commented

2022-05-27 00:34:07 +02:00

I think it would be best to edit report with sweep file and description by @Eary then. I am not sure if difference is intentional though.

Richard Antalik commented

2022-05-27 00:37:50 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Richard Antalik changed title from ~~False color look gives incorrect values for colored values~~ to False color look gives incorrect values

2022-05-27 00:38:34 +02:00

tempdevnova commented

2022-05-27 12:54:08 +02:00

About this though, this is rather expected, as perceptually blue color with the same emission intensity would look darker than green, so the RGB to BW Transform takes that into account
Yes I am aware of that however even when taking the perceptional differences into consideration the value is too high:

The luminous coefficient for sRGB blue is 0.0722 if we know convert the Blue value of 40 into the percieved brightness we get: 40*0.0722=2.888
So basically the RGb triple 0/0/40 is perceptionally as bright as 2.888/2.888/2.888, which is still way to bright to be considered middle gray.

`About this though, this is rather expected, as perceptually blue color with the same emission intensity would look darker than green, so the RGB to BW Transform takes that into account` Yes I am aware of that however even when taking the perceptional differences into consideration the value is too high: The luminous coefficient for sRGB blue is 0.0722 if we know convert the Blue value of 40 into the percieved brightness we get: 40*0.0722=2.888 So basically the RGb triple 0/0/40 is perceptionally as bright as 2.888/2.888/2.888, which is still way to bright to be considered middle gray.

tempdevnova commented

2022-05-27 12:58:45 +02:00

Somehow this bug report turned into something else than it was originally...

Riccardo Giovanetti commented

2022-05-27 15:25:58 +02:00

That's the reason why I did publish my tests here. Is this a real "bug", a "known issue" a "To Do" or what? I am not enough educated in this field to express a useful opinion, and thanks Troy, Zijun and Genco for having been invited to express their thoughts here. Everything can be done better and nothing is perfect in this world. If it's not a "bug" per se or a regression, this bug report should be closed, in my personal opinion. I do use extensively the False Colour to expose the shots in a production I'm currently working at, and hope I'm doing it right.

tempdevnova commented

2022-05-27 15:46:32 +02:00

I think you may have misunderstood me. What I meant to say was that originally my report was about the false color transform giving incorrect values for colored pixels, but in the course of discussion it somehow turned into a report about the Blender implementation having different values than the Github Filmic version, which I think is a completely seperate issue that should be addressed seperately.

I think you may have misunderstood me. What I meant to say was that originally my report was about the false color transform giving incorrect values for **colored pixels**, but in the course of discussion it somehow turned into a report about the Blender implementation having different values than the Github Filmic version, which I think is a completely seperate issue that should be addressed seperately.

Zijun Zhou commented

2022-05-27 18:11:59 +02:00

In #98405#1365439, @tempdevnova wrote:
Yes I am aware of that however even when taking the perceptional differences into consideration the value is too high:

The luminous coefficient for sRGB blue is 0.0722 if we know convert the Blue value of 40 into the percieved brightness we get: 40*0.0722=2.888
So basically the RGb triple 0/0/40 is perceptionally as bright as 2.888/2.888/2.888, which is still way to bright to be considered middle gray.

The RGB to BW is done in Filmic Log as the processing space. This means you need to convert to Filmic Log first before doing RGB to BW, and then convert back to Linear BT.709. Did you try my set up in my compositor screenshot? Try it please.

If your bug report is about this then unfortunately this is not a bug.

> In #98405#1365439, @tempdevnova wrote: > Yes I am aware of that however even when taking the perceptional differences into consideration the value is too high: > > The luminous coefficient for sRGB blue is 0.0722 if we know convert the Blue value of 40 into the percieved brightness we get: 40*0.0722=2.888 > So basically the RGb triple 0/0/40 is perceptionally as bright as 2.888/2.888/2.888, which is still way to bright to be considered middle gray. The `RGB to BW` is done in Filmic Log as the processing space. This means you need to convert to Filmic Log first before doing `RGB to BW`, and then convert back to Linear BT.709. Did you try my set up in my compositor screenshot? Try it please. ![image.png](https://archive.blender.org/developer/F13110971/image.png) If your bug report is about this then unfortunately this is not a bug.

Brecht Van Lommel commented

2022-05-27 18:16:52 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2022-05-27 18:16:52 +02:00

The Filmic Blender repo has a newer LUT file, I can update to that to make it match. However I agree there is something wrong in that config as well, so it's not a full solution.

It's multiplying with the luminance coefficients in log space, but they only make scene in linear space. Further, it's unclear why false color is a 3D LUT when the color is converted to grayscale right before, it might as well be a 1D LUT.

Probably we could convert to luminance in linear space and then use a simpler 1D LUT lookup.

The Filmic Blender repo has a newer LUT file, I can update to that to make it match. However I agree there is something wrong in that config as well, so it's not a full solution. It's multiplying with the luminance coefficients in log space, but they only make scene in linear space. Further, it's unclear why false color is a 3D LUT when the color is converted to grayscale right before, it might as well be a 1D LUT. Probably we could convert to luminance in linear space and then use a simpler 1D LUT lookup.

Zijun Zhou commented

2022-05-27 18:30:28 +02:00

In #98405#1365673, @brecht wrote:
It's multiplying with the luminance coefficients in log space, but they only make scene in linear space

My guess is maybe it's for higher dynamic range representation.

In #98405#1365673, @brecht wrote:
Further, it's unclear why false color is a 3D LUT when the color is converted to grayscale right before, it might as well be a 1D LUT.

I am not sure of the actually false color manipulation, my test here only suggest "if you convert to BW in Filmic log you will achieve the monochromatic render with same false color as the original render". For specific things the actual False color does I might still have to ask @troy_s

> In #98405#1365673, @brecht wrote: > It's multiplying with the luminance coefficients in log space, but they only make scene in linear space My guess is maybe it's for higher dynamic range representation. > In #98405#1365673, @brecht wrote: > Further, it's unclear why false color is a 3D LUT when the color is converted to grayscale right before, it might as well be a 1D LUT. I am not sure of the actually false color manipulation, my test here only suggest "if you convert to BW in Filmic log you will achieve the monochromatic render with same false color as the original render". For specific things the actual False color does I might still have to ask @troy_s

tempdevnova commented

2022-05-27 18:37:42 +02:00

"The RGB to BW is done in Filmic Log" Is that so in Blender? If that is the case it is a bug.

See Troy's github documentation for false color:
https://github.com/sobotka/filmic-blender

It specifically states e.g. for grey: "Scene Referred Linear value 0.18009142."

As Brecht said, the luminance coefficients only make sense in linear space.

"The RGB to BW is done in Filmic Log" Is that so in Blender? If that is the case it is a bug. See Troy's github documentation for false color: https://github.com/sobotka/filmic-blender It specifically states e.g. for grey: "**Scene Referred Linear** value 0.18009142." As Brecht said, the luminance coefficients only make sense in linear space.

Troy Sobotka commented

2022-05-27 20:19:52 +02:00

It was only intended as a guide given context constraints of the design of Looks etc., and as such, the False Colour will fall apart. Doubly so with a 3D LUT. There were a number of reasons to make concessions. I would expect it to fall to bits on chroma components!

Brecht Van Lommel commented

2022-05-30 10:41:05 +02:00

I would expect the transform to work like this. Independent of Filmic or any view transform like that, just visualizing the range of linear values.

# Compute luminance in linear space
- !<MatrixTransform> {matrix: [0.2126729, 0.7151521, 0.0721750, 0, 0.2126729, 0.7151521, 0.0721750, 0, 0.2126729, 0.7151521, 0.0721750, 0, 0, 0, 0, 1]}
# Transform to log space (range may need to be tweaked)
- !<AllocationTransform> {allocation: lg2, vars: [-10, 10]}
# False color ramp from log to linear space
- !<FileTransform> {src: false_color.spi3d, interpolation: best}
# Transform to display space, separate to prepare for adding more displace spaces
- !<ColorSpaceTransform> {src: Linear, dst: sRGB}

But we need an appropriate LUT with a color ramp that has gray at 0.18, and I don't immediately have time to create that.

I would expect the transform to work like this. Independent of Filmic or any view transform like that, just visualizing the range of linear values. ``` # Compute luminance in linear space - !<MatrixTransform> {matrix: [0.2126729, 0.7151521, 0.0721750, 0, 0.2126729, 0.7151521, 0.0721750, 0, 0.2126729, 0.7151521, 0.0721750, 0, 0, 0, 0, 1]} # Transform to log space (range may need to be tweaked) - !<AllocationTransform> {allocation: lg2, vars: [-10, 10]} # False color ramp from log to linear space - !<FileTransform> {src: false_color.spi3d, interpolation: best} # Transform to display space, separate to prepare for adding more displace spaces - !<ColorSpaceTransform> {src: Linear, dst: sRGB} ``` But we need an appropriate LUT with a color ramp that has gray at 0.18, and I don't immediately have time to create that.

Alexey Adamitsky commented

2022-06-06 14:08:27 +02:00

Added subscriber: @AlexeyAdamitsky

Zijun Zhou commented

2022-06-27 20:37:32 +02:00

If the goal is to compute iluminance in Linear state, I believe the easiest way for now is:

  - !<ColorSpace>
    name: False Color
    family: display
    equalitygroup:
    bitdepth: 32f
    description: |
      Filmic false color view transform
    isdata: false
    from_reference: !<GroupTransform>
        children:
            - !<CDLTransform> {sat: 0}
            - !<ColorSpaceTransform> {src: Linear, dst: Filmic Log}
            - !<MatrixTransform> {matrix: [0.2126729, 0.7151521, 0.0721750, 0, 0.2126729, 0.7151521, 0.0721750, 0, 0.2126729, 0.7151521, 0.0721750, 0, 0, 0, 0, 1]}
            - !<FileTransform> {src: filmic_false_color.spi3d, interpolation: best}

The CDL desaturation takes the luminance coefficients into account so we can just lean on that.

I know this is not the most elegant way compare with building another lut from scratch, but it is the simplest way to do the job for now:

Screenshot with synced lut from GitHub:

Before (compute iluminance in Filmic Log) (with synced lut from GitHub):

After (compute iluminance in Linear BT.709) (with synced lut from GitHub):

The above two sweeps are blurred to have smooth gradient to make it easier to see the grey.

If the goal is to compute iluminance in Linear state, I believe the easiest way for now is: ``` - !<ColorSpace> name: False Color family: display equalitygroup: bitdepth: 32f description: | Filmic false color view transform isdata: false from_reference: !<GroupTransform> children: - !<CDLTransform> {sat: 0} - !<ColorSpaceTransform> {src: Linear, dst: Filmic Log} - !<MatrixTransform> {matrix: [0.2126729, 0.7151521, 0.0721750, 0, 0.2126729, 0.7151521, 0.0721750, 0, 0.2126729, 0.7151521, 0.0721750, 0, 0, 0, 0, 1]} - !<FileTransform> {src: filmic_false_color.spi3d, interpolation: best} ``` The CDL desaturation takes the luminance coefficients into account so we can just lean on that. I know this is not the most elegant way compare with building another lut from scratch, but it is the simplest way to do the job for now: ![image.png](https://archive.blender.org/developer/F13233042/image.png) Screenshot with synced lut from GitHub: ![image.png](https://archive.blender.org/developer/F13233049/image.png) Before (compute iluminance in Filmic Log) (with synced lut from GitHub): ![image.png](https://archive.blender.org/developer/F13233055/image.png) After (compute iluminance in Linear BT.709) (with synced lut from GitHub): ![image.png](https://archive.blender.org/developer/F13233057/image.png) The above two sweeps are blurred to have smooth gradient to make it easier to see the grey.

Zijun Zhou commented

2022-06-27 21:55:07 +02:00

But honestly, when the "Brightness" and "Lightness" parts of colors are still not fully reseached, the luminance coefficients can only be seen as a guide as well, not "correct".

For example, here do you think the blue box in the middle is the same "Brightness" as the surrounding grey?

At least I don't think so.

But the luminance coefficients tell me they are the same "luminance".

This is the "greyness boundary condition" at play here.
https://twitter.com/troy_s/status/1484573870120005635

While the title of the report says "False color gives incorrect values", on this front I don't think we can have anything "correct" just yet.

But honestly, when the "Brightness" and "Lightness" parts of colors are still not fully reseached, the luminance coefficients can only be seen as a guide as well, not "correct". For example, here do you think the blue box in the middle is the same "Brightness" as the surrounding grey? ![image.png](https://archive.blender.org/developer/F13233133/image.png) At least I don't think so. But the luminance coefficients tell me they are the same "luminance". ![image.png](https://archive.blender.org/developer/F13233135/image.png) This is the "greyness boundary condition" at play here. https://twitter.com/troy_s/status/1484573870120005635 While the title of the report says "False color gives incorrect values", on this front I don't think we can have anything "correct" just yet.

tempdevnova commented

2022-06-28 12:24:38 +02:00

While the title of the report says "False color gives incorrect values", on this front I don't think we can have anything "correct" just yet. Given that color perception is such a complicated topic I agree. But I think we can work on it to be less "false".

`While the title of the report says "False color gives incorrect values", on this front I don't think we can have anything "correct" just yet.` Given that color perception is such a complicated topic I agree. But I think we can work on it to be less "false".

Troy Sobotka commented

2022-06-28 14:15:52 +02:00

All tristinulus is, by nature, uniform with respect to itself.

The question then becomes “Which luminance to represent?”

As best as I can tell, it should be in relation to the formed image, and that’s where the false colour becomes a tad more tricky when desiring accuracy given the general design.

All tristinulus is, by nature, uniform with respect to itself. The question then becomes “Which luminance to represent?” As best as I can tell, it should be in relation to the formed image, and that’s where the false colour becomes a tad more tricky when desiring accuracy given the general design.

tempdevnova commented

2022-06-28 15:54:19 +02:00

Short update to my original bug report:

Orginally I created this report because I thought that having a tristimulus value of 0;0;40 map to grey seemed to be incorrect.
But if you take Filmic into account it actually works out: 0;0;40 after going through Filmic view transform becomes 0.42;0.42;1.0. If we noe take the transfer function of an sRGB display into account what the screen ouputs is: 0.148;0.148;1.
When we now weight this with sRGB luminance coefficients it becomes: 0.1480.22+0.1480.71+0.0722=0.20984 (Slightly above 0.18 but take rounding error into consideration).

TLDR: My original bug report was faulty and I will remove that section.

Short update to my original bug report: Orginally I created this report because I thought that having a tristimulus value of 0;0;40 map to grey seemed to be incorrect. But if you take Filmic into account it actually works out: 0;0;40 after going through Filmic view transform becomes 0.42;0.42;1.0. If we noe take the transfer function of an sRGB display into account what the screen ouputs is: 0.148;0.148;1. When we now weight this with sRGB luminance coefficients it becomes: 0.148*0.22+0.148*0.71+0.0722=0.20984 (Slightly above 0.18 but take rounding error into consideration). TLDR: My original bug report was faulty and I will remove that section.

tempdevnova commented

2022-06-28 16:19:00 +02:00

I am not sure what the problem surrently is but I think the behavior as described in the current report is correct.
It states:

Short description of error
The False color in Blender is indeed different from the Filmic master on GitHub:

Troy just said:
"As best as I can tell, it should be in relation to the formed image, and that’s where the false colour becomes a tad more tricky when desiring accuracy given the general design."

So False color is dependend on how the Filmic view transform behaves.
This is what I think is the reason false color in standard Blender is different than in Filmic master from Github:
Filmic master from Github only has a view transform called "Filmic Log Encoding Base". Therefore false color is designed around the values "Filmic Log Encoding Base" gives after the transform. In standard Blender we have two view transforms called "Filmic" and "Filmix log".
AFAIK "Filmic Log" is the same as "Filmic Log Encoding Base" but "Filmic" is different.
After doing some testing it seems that false color in standard Blender is designed around the values "Filmic" gives after the transform not "Filmix log", which is why there is a difference to Filmic master from Github.

I am not sure what the problem surrently is but I think the behavior as described in the current report is correct. It states: **Short description of error** The False color in Blender is indeed different from the Filmic master on GitHub: Troy just said: "As best as I can tell, it should be in relation to the formed image, and that’s where the false colour becomes a tad more tricky when desiring accuracy given the general design." So False color is dependend on how the Filmic view transform behaves. This is what I think is the reason false color in standard Blender is different than in Filmic master from Github: Filmic master from Github only has a view transform called "Filmic Log Encoding Base". Therefore false color is designed around the values "Filmic Log Encoding Base" gives after the transform. In standard Blender we have two view transforms called "Filmic" and "Filmix log". AFAIK "Filmic Log" is the same as "Filmic Log Encoding Base" but "Filmic" is different. After doing some testing it seems that false color in standard Blender is designed around the values "Filmic" gives after the transform not "Filmix log", which is why there is a difference to Filmic master from Github.

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

False color look gives incorrect values #98405