Hi,
my lucky guess is that maybe the buffer will be kept at 8-bit in AgX but will be converted to float when using the IDT sRGB-Texture?
Maybe you can post this as a “bug” in the blender developer forum, because I think people there are better suited to answer this question?
Regards
Daniel
Hey, I was curious about the problem and tried to reproduce it on my side.
I can reproduce the probleme exclusively on 8bit png textures, 16bit png are not affected.
The problem appear on CPU and GPU rendering with cycles.
This looks to be a Blender issue if we trust my comparison against oiiotool which is not affected.
software used:
cg-config-v1.0.0_aces-v1.3_ocio-v2.0.ocioBlender-4.1.1-windows-x64
cyclesCUDAImage statistics:
Textures:
Total memory: 132.00M (138,412,032)
checker.float32.exr 64.00M (67,108,864)
checker.uint8.png 32.00M (33,554,432)
checker.uint16.png 32.00M (33,554,432)
checker-gray.uint8.png 4.00M (4,194,304)
Image statistics:
Textures:
Total memory: 116.00M (121,634,816)
checker.float32.exr 64.00M (67,108,864)
checker.uint16.png 32.00M (33,554,432)
checker.uint8.png 16.00M (16,777,216)
checker-gray.uint8.png 4.00M (4,194,304)
Reading G:\temp\bl-ocio-mem-issue\work\\textures\checker.uint8.png
Performing 'colorconvert' with args: "--colorconvert", "sRGB - Texture", "scene_linear"
colorconvert took 0.02s (total time 0.08s, mem 127.0 MB)
Threads: 8
oiiotool runtime statistics:
Total time: 0.09s
-i : 0.00
colorconvert : 0.02
unaccounted : 0.06
Peak memory: 127.0 MB
Current memory: 78.9 MB
OpenImageIO ImageCache statistics (shared) ver 2.3.10
Options: max_memory_MB=4096.0 max_open_files=100 autotile=0
autoscanline=0 automip=0 forcefloat=1 accept_untiled=1
accept_unmipped=1 deduplicate=1 unassociatedalpha=0
failure_retries=0
Images : 1 unique
ImageInputs : 1 created, 0 current, 1 peak
Total pixel data size of all images referenced : 12.0 MB
Total actual file size of all images referenced : 30 KB
Pixel data read : 0 B
Peak cache memory : 0 B
Image file statistics:
opens tiles MB read --redundant-- I/O time res File
1 1 0 0.0 0.0s 2048x2048x3.u8 G:\temp\bl-ocio-mem-issue\work\\textures\checker.uint8.png UNTILED
Reading G:\temp\bl-ocio-mem-issue\work\\textures\checker.uint8.png
Performing 'colorconvert' with args: "--colorconvert", "sRGB", "scene_linear"
colorconvert took 0.03s (total time 0.10s, mem 127.6 MB)
Threads: 8
oiiotool runtime statistics:
Total time: 0.10s
-i : 0.00
colorconvert : 0.03
unaccounted : 0.07
Peak memory: 127.6 MB
Current memory: 79.5 MB
OpenImageIO ImageCache statistics (shared) ver 2.3.10
Options: max_memory_MB=4096.0 max_open_files=100 autotile=0
autoscanline=0 automip=0 forcefloat=1 accept_untiled=1
accept_unmipped=1 deduplicate=1 unassociatedalpha=0
failure_retries=0
Images : 1 unique
ImageInputs : 1 created, 0 current, 1 peak
Total pixel data size of all images referenced : 12.0 MB
Total actual file size of all images referenced : 30 KB
Pixel data read : 0 B
Peak cache memory : 0 B
Image file statistics:
opens tiles MB read --redundant-- I/O time res File
1 1 0 0.0 0.0s 2048x2048x3.u8 G:\temp\bl-ocio-mem-issue\work\\textures\checker.uint8.png UNTILED
I upload a minimal test scene for reproduction here (for Windows system):
Feel free to use it for reporting a bug to Blender developers (if its one).
Probably doesn’t help much as I don’t provide explanations neither solutions, but I thought it could be interesting to share.
Cheers,
Liam
The only thing guys… is that this happens with the OCIO package downloaded from this site… For some reason the 8 Bit spread converts it to 16 making it weigh twice as much.
Now I’ll try, but if I identify it as a bug in blender, they will tell me that it is not their problem since they did not create the OCIO package
Isn’t there some trick to avoid this?
Hi everyone!
I want to create a scene in Blender for testing DRTs. The scene should be rendered using Cycles as Linear DaVinci Wide Gamut EXR.
I’m trying to set up Blender to render in DaVinci Wide Gamut space. I guess I read everything here and on @TooDee website, but I still don’t get it. By default, whatever I set in the texture color space setting, is converted to sRGB gamut. Then the values go to Cycles for rendering.
If I switch Blender to using ACES OCIO config, then whatever I set in the texture color space setting, is converted to ACEScg gamut. And then these values go to Cycles for rendering.
I have 2 questions here:
How hard it would be to make blender render in DaVinci Wide Gamut?
Can I just use Blender default config.ocio, load Linear DaVinci Wide gamut textures, set texture color space as Linear sRGB in shader settings, then render it as Linear sRGB and later, in Resolve, treat it like Linear DaVinci Wide gamut EXR? Or, again, Cycles doesn’t just render some values, but needs to know the correct gamut to render correctly?
Thanks!
Hey, on my phone now can’t quickly reference but I belive the role called rendering is what determines the rendering space in OCIO managed DCC apps. So in both ACES or Blender’s default config it would be possible to make DWG/Linear possible as rendering space if it’s added as a color space.
[edit]
At my machine now, just referencing the ACES 1.3 config and Blender’s config it looks like rendering and scene_linear roles are used? Blender probably falls back to scene_linear if rendering is not defined since it doesn’t exist in ACES 1.3 config. Try both and it probably gets you what you’re looking for.
Thank you! I tried both and looks like Blender uses scene_linear role for everything and rendering role for nothing. But most likely I just didn’t find yet, what is affected by rendering role in Blender.
Hi @meleshkevich ,
I was thinking about your post for a while and now I finally found some time to answer.
Frist, Blender and the RCM2 view transforms:
Unless you bake a SDR LUT with the RCM SDR look I am not sure how you want to see the RCM2 image rendering pipeline in Blender. It is not available in a OCIOv2 config, right?
This begs the question, how can you judge your test rendering before loading them into Resolve? Also the primaries of DaVinci WideGamut are placed far outside the spectral locus, so without the right viewing pipeline I wonder how to make sense of them inside Blender.
Question 1: I would say - it depends.
Take the default Blender scene, set the cube’s base color of the shader to 0.9 / 0.1 / 0.1 and render out an EXR file with different OCIO configs (e.g.Blender default, ACES 1.3, T-CAM).
Check the values of the faces of the cube and they will show identical RGB values.
No matter which OCIO config you use, the shader will always reflect 90% in the red channel, and 10% in the green and blue channel.
The moment you interpret the EXR as a linear - sRGB, ACEScg or E-Gamut and use the appropriate view transform/DRT, the results will look different.
The same applies when you use a texture/HDRI in your scene. The numbers in the texture/HDRI files will have an assigned meaning, therefore using an ACEScg colorchecker texture in a default OCIO blender scene and view it through Standard/AgX will look wrong.
Question 2:
I have no answer to your question.
I assume the terms ACEScg, ACEScct and ACES 2065-1 have a connection to the right matrix inside of the OCIO backend. So when you select ACES 2065-1 as input and the working space is set to ACEScg, the appropriate matrix will be applied automatically.
To your last point, I think you are exactly right.
Once you transform all your textures and shader values to DWG linear values and plug them into Blender with any OCIO config and the the conversion to none (RAW) the EXR render result should be viewable in Resolve when you assign the EXR as a linear DWG file.
Best regards
Daniel
Thank you for the detailed response!
I don’t need to view it using DaVinci DRT in Blender. I just need to use DWG as a rendering gamut. For me, as a colorist, it is a widely used gamut, so it makes sense for me.
Basically I’m just going to lit a test scene with some values, that I color picked earlier. So it should be a scene, that is difficult to render (in terms of picture formation) without artifacts. Specifically gradients smoothness. And to be honest, it turned out to be harder than I thought, to make this scene.
For this case I guess I’m ok with any DRT for quick monitoring of what is happening in the scene. Not perfect, but I’m trying to not overcomplicate this to avoid mental burnout (I’m an artist, coding is unavoidable for me, not fun), this is just a temporary monitoring, not for the final judging.
So, this means, that Cycles (or maybe any non-spectral rendering engine) is not color space aware? I mean, for example IOR is somewhat close to the real world behavior. So I thought, maybe there is something that also relies on the real nanometer values or something like that. But I hope (and based on your explanation) it is not.
Thank you!