blender/blender

ACES - Diffuse weight double #125883

New Issue

Open

opened 2024-08-05 08:56:50 +02:00 by William-Asperti · 4 comments

William-Asperti commented

2024-08-05 08:56:50 +02:00

System Information
Operating system: Windows-10-10.0.22631-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3090/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 556.12

Blender Version
Broken: version: 4.2.0, branch: blender-v4.2-release, commit date: 2024-07-16 06:20, hash: a51f293548ad
Worked: (newest version of Blender that worked as expected)

Short description of error
Hello everyone...
I downloaded their OCIO package from the official ACES website, replacing it in the Blender colormap.
The colors work in every phase (texture, render, compositing), everything is ok in terms of rendering.
But there is a problem with reading the textures loaded with the sRGB color space, such as the diffuse map.
As per the attached files, if I create a 4K 8-bit texture, this for reasons unknown to me, is converted to 16bit, taking up double the space in the memory (128mb, instead of 64mb, as the normal map or others do...)
I have already written to the official ACES channel, which however asked me to report the error to you too... I don't know, can something be done?
Given the problem of Blender with Full vram, this error would be a hard blow

https://community.acescentral.com/t/aces-set-up-for-blender-using-ocio/2106/42?page=2

**System Information** Operating system: Windows-10-10.0.22631-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 3090/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 556.12 **Blender Version** Broken: version: 4.2.0, branch: blender-v4.2-release, commit date: 2024-07-16 06:20, hash: `a51f293548ad` Worked: (newest version of Blender that worked as expected) **Short description of error** Hello everyone... I downloaded their OCIO package from the official ACES website, replacing it in the Blender colormap. The colors work in every phase (texture, render, compositing), everything is ok in terms of rendering. But there is a problem with reading the textures loaded with the sRGB color space, such as the diffuse map. As per the attached files, if I create a 4K 8-bit texture, this for reasons unknown to me, is converted to 16bit, taking up double the space in the memory (128mb, instead of 64mb, as the normal map or others do...) I have already written to the official ACES channel, which however asked me to report the error to you too... I don't know, can something be done? Given the problem of Blender with Full vram, this error would be a hard blow https://community.acescentral.com/t/aces-set-up-for-blender-using-ocio/2106/42?page=2

studio-config-v2.0.0_aces-v1.3_ocio-v2.2.ocio

67 KiB

Test_ACES_Weight.blend

686 KiB

Texture_4K_8Bit_DIF.png

6.3 MiB

William-Asperti added the

labels 2024-08-05 08:56:50 +02:00

Iliya Katushenock added the

Render & Cycles

labels 2024-08-05 12:24:16 +02:00

milan.m commented

2024-08-05 13:32:09 +02:00

Hi, I was going to reply on aces central but now that I find this report, it's better that I write here.

I was able to reproduce this issue.

I find that this is not related to ACES. The issue happens every time a color space is used with different primaries than the default scene linear role (defined as scene_linear role in the config), in any OCIO config.

So, using Blender 4.2 LTS with the default config, I was able to reproduce this issue by using acescg or Rec.2020 color space in the image texture node and an 8 bit texture in any format.

Using the aces config you linked, by choosing ACEScg color space instead of sRGB - Texture (since the scene_linear role is set to ACEScg in that config), I find that textures do not increase in size.

I also tested a modified aces studio config that is using Linear sRGB instead of ACEScg for a scene_linear role, and then (8bit) textures using sRGB - Texture or Linear Rec.709 (sRGB) color space did not increase in size, but of course, using any other color space like ACEScg or S-Log3 S-Gamut3 did cause the issue.

I tested versions: 3.6.0 LTS, 4.0.0, 4.2 LTS on Linux and they are all affected.

I hope this helps.

Regards
Milan

Hi, I was going to reply on aces central but now that I find this report, it's better that I write here. I was able to reproduce this issue. I find that this is not related to ACES. The issue happens every time a color space is used with _different primaries_ than the default scene linear role (defined as `scene_linear` role in the config), _in any OCIO config_. So, using Blender 4.2 LTS with the default config, I was able to reproduce this issue by using `acescg` or `Rec.2020` color space in the image texture node and an 8 bit texture in any format. Using the aces config you linked, by choosing `ACEScg` color space instead of `sRGB - Texture` (since the `scene_linear` role is set to `ACEScg` in that config), I find that textures do not increase in size. I also tested a modified aces studio config that is using `Linear sRGB` instead of `ACEScg` for a `scene_linear` role, and then (8bit) textures using `sRGB - Texture` or `Linear Rec.709 (sRGB)` color space did not increase in size, but of course, using any other color space like `ACEScg` or `S-Log3 S-Gamut3` did cause the issue. I tested versions: 3.6.0 LTS, 4.0.0, 4.2 LTS on Linux and they are all affected. I hope this helps. Regards Milan

William-Asperti commented

2024-08-05 14:57:28 +02:00

Author

Unfortunately, however, everything changes if I set the color space in that way

Maybe I was wrong to send you that file before.. with the rainbow.

I send you these materials.. as you can see if you work in substance in ACES it gets a base color with this shade. Shade that must then be maintained in substance to have continuity. If I set it in srgb - texture, the color is the same, if I set it in ACEScg everything becomes whiter

With sRGB Texture - 128mb but color correct:

With ACEScg - 64mb but color wrong:

So yes, it weighs less, but the color is not the same
I don't know if you have substance with ACES and can do a test...

Unfortunately, however, everything changes if I set the color space in that way Maybe I was wrong to send you that file before.. with the rainbow. I send you these materials.. as you can see if you work in substance in ACES it gets a base color with this shade. Shade that must then be maintained in substance to have continuity. If I set it in srgb - texture, the color is the same, if I set it in ACEScg everything becomes whiter With sRGB Texture - 128mb but color correct: <img width="3792" alt="image" src="attachments/93f2931d-3bce-4799-bbdf-b965127ea1d8"> With ACEScg - 64mb but color wrong: <img width="3792" alt="image" src="attachments/6913f93e-8f6c-4f8f-a443-e4f1e44e3121"> So yes, it weighs less, but the color is not the same I don't know if you have substance with ACES and can do a test...

44 MiB

Test02.blend

3.1 MiB

6.2 MiB

6.1 MiB

6.1 MiB

milan.m commented

2024-08-05 15:30:47 +02:00

Yes, of course the colors would change. I was not proposing that as a solution or a workaround. Just pointing out what (I guess) is causing the issue.

Yes, of course the colors would change. I was not proposing that as a solution or a workaround. Just pointing out what (I guess) is causing the issue.

milan.m commented

2024-08-06 21:40:05 +02:00

Well, I did some "detective work" and I'm afraid I have some bad news.

I found out that the oldest version of Blender that has this issue is 3.3.0. Release notes pointed me to the following two commits:
33f5e8f
9d8fb80f21

"For non-raw, non-sRGB color spaces, always use half float even if that uses more memory."

So, I guess this is a feature, not a bug... A bit heavy-handed for my taste.

As a workaround, you could try exporting your 8 bit texture maps as sRGB Encoded AP1 - Texture. That would work with the config you linked in your first post. I don't use Substance so I don't know if that's even possible...

EDIT: I guess you could set that in the project configuration window under Export color spaces, next to 8 bit images. And make sure that same color space is selected in the image texture node in Blender.

Regards
Milan

Well, I did some "detective work" and I'm afraid I have some bad news. I found out that the oldest version of Blender that has this issue is 3.3.0. Release notes pointed me to the following two commits: [33f5e8f](https://projects.blender.org/blender/blender/commit/33f5e8f) [9d8fb80f21](https://projects.blender.org/blender/blender/commit/9d8fb80f21) "For non-raw, non-sRGB color spaces, always use half float even if that uses more memory." So, I guess this is a feature, not a bug... A bit heavy-handed for my taste. As a workaround, you could try exporting your 8 bit texture maps as `sRGB Encoded AP1 - Texture`. That would work with the config you linked in your first post. I don't use Substance so I don't know if that's even possible... EDIT: I guess you could set that in the project configuration window under `Export color spaces`, next to `8 bit images`. And make sure that same color space is selected in the image texture node in Blender. Regards Milan

Bart van der Braak added

and removed

labels 2024-08-14 12:53:41 +02:00

Sign in to join this conversation.

No Label

Animation & Rigging

Automated Testing

Blender Asset Bundle

Code Documentation

Dependency Graph

Development Management

Images & Movies

Motion Tracking

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Render Pipeline

Sculpt, Paint & Texture

Video Sequencer

Viewport & EEVEE

Virtual Reality

Asset Browser Project

Blender 2.8 Project

Milestone 1: Basic, Local Asset Browser

Good First Issue

Animation & Rigging

Development Management

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Sculpt, Paint & Texture

Viewport & EEVEE

Needs Info from Developers

Needs Information from User

No Milestone

No project

No Assignees

2 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#125883

No description provided.