Inconsistent ORM Texture Atlas Automatic Baking Results in Blender ( 3.3.1 LTS)

Question

I've encountered an issue where the output Occlusion Roughness Metallic (ORM) atlas appears too bright, specifically the roughness channel. Interestingly, this problem only occurs in my script, not when I bake textures manually.

The key difference in my script is that the roughness is baked in "Roughness" mode, while metallic and ambient occlusion (AO) are baked in "Emit" mode. To address this, I applied a gamma correction of 2.2 to the output ORM, which resolved the brightness issue. However, I'm keen to understand why my script produces this result in the first place.

Can someone shed light on what might be causing this inconsistency between manual and automatic baking, particularly with respect to the roughness channel?

Thanks in advance!

EDIT : I tried fiddling with the colorspaces, I'm on "Standard" rather than Filmic, I tried turning on the 'None' option on Display Device, and the original ORM texture to be baked is in Non color mode...

EDIT2: I'm using the save_render function, I'm wondering whether the problem doesn't come from there, but when trying to use 'Image.save', the filepath argument I put in is not recognized...

---

After a bit more tests and research, it's possible that the reason I have a colorspace problem with the automatic process comes from the fact that I am using image.save_render (see this post)

Here's the part of my code that takes care of the bake:

set_scene_parameters(context, bake_margin, cycles_samples, bake_lighting, bake_color)

image = create_image(resolution, bake_alpha)


baked_uv_name = prepare_uvs(context)
bake_node = []

    for ob in context.selected_objects:
        for material in ob.data.materials:
            bake_node = set_shader_graph(ob, material, baked_uv_name, image)
 
    textures_dictionary = {}
    if bake_diffuse :
        bpy.ops.object.bake(type='DIFFUSE')

        if bake_alpha :
            context.scene.render.image_settings.color_mode = 'RGBA'
            filepath = os.path.join(output_directory, 'D_baked.png')
        
        else:
            filepath = os.path.join(output_directory, f'D_baked {texture_format}')

       
        image.save_render(filepath=filepath)
        textures_dictionary['diffuse']=filepath


    context.scene.render.image_settings.color_mode = 'RGB'
 
    if bake_roughness:
        bpy.ops.object.bake(type='ROUGHNESS')
        image.filepath = os.path.join(output_directory, f'R_baked.{texture_format}')
        filepath = os.path.join(output_directory, f'R_baked.{texture_format}')
        image.save_render(filepath=filepath)
        textures_dictionary['roughness']=filepath

I have currently three possible solutions:

• Write the image with PIL
• Use the Image.save() function = this renders a black image
• Post process the ORM with the gamma correction after GLB output

---

UPDATE

After even more tests, I found out that my problem probably came from the fact that the image used for baking the roughness must be put in Non-Color before the baking. Weirdly enough, I don't remember doing that in the manual process, but that might also be because at the time, my scene was in Filmic Color Management.

I've rewritten my script to make sure the roughness bake image is Non Color, and it seems to work for now.

I'm leaving this thread open anyway, because that might not be the end of it, and it could still be useful to a fellow programmer having the same kind of issues.

Thanks all,

Answer 1

"Gamma correction" is not a thing. This term is a symptom of someone not understanding what is going on with color management. "Incorrect gamma" most likely means it's a color space mismatch. If gamma of 2.2 sort of fixes stuff, I suspect it is likely, linear values are exported, but sRGB are for some reason expected. Converting linear RGB to sRGB is more than raising values to the power of 2.2. See some formulas here:

So however you are using the maps, it seems sRGB might be expected instead of linear colors that you seem to bake, however, if you bake stuff that is supposed to be linear to 8bit format in sRGB, you might be loosing detail, because sRGB will compress the range of values to match human vision that is not linear, so this might not be the desirable situation. You might need to adjust how shaders work in the software you are viewing the exported maps in. You might want to consider using higher bit depth and/or linear values instead of sRGB for some maps. For example normal or displacement maps could benefit from 16 or even 32 bits per channel and formats such as TIFF or EXR. EXR can only store linear color from Blender so that might make things easier because you don't need to find out how to set things up correctly and you can always expect linear values from EXR format.