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 :

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


    context.scene.render.image_settings.color_mode = 'RGB'
    if bake_roughness:
        image.filepath = os.path.join(output_directory, f'R_baked.{texture_format}')
        filepath = os.path.join(output_directory, f'R_baked.{texture_format}')

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


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,

  • $\begingroup$ By the way, what is ORM? If it's Ambient Occlusion/Roughness/Metallic, you should clearly define it before using the abbreviation. This is a common source of completely unnecessary confusion. $\endgroup$ Commented Sep 18, 2023 at 8:44
  • $\begingroup$ Sorry, you're absolutely right :) I'll edit my post $\endgroup$
    – Popi
    Commented Sep 18, 2023 at 8:59

1 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:

enter image description 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.

  • $\begingroup$ Thank you for your quick answer. When I was talking about gamma correction, that was probably a shortcut to talk about global linear workflow, which I understand is a way to counterbalance the fact that the computer monitor doesn't display colors correctly ( a least in my memory). Your explanation is very thorough but in this case the first problem I would like to understand is why the colorspace is perfectly outputted when I'm doing the process manually, but not automatically. Also, because of the final goal of the GLB, I can't use EXR's...I have to find another way to fix it. But thank you! $\endgroup$
    – Popi
    Commented Sep 18, 2023 at 9:12
  • $\begingroup$ It might be helpful if you could share the code you are using to bake and define the context the textures are going to be used in a bit better so it would be possible to reproduce and test the problem somehow. $\endgroup$ Commented Sep 18, 2023 at 10:23
  • $\begingroup$ The more I test the more I think it comes from the function image.save_render(). I saw another post on Stack Overflow saying that the manual process of saving as render creates colorspace problems.I'm going to answer with a new post to put the part of my code that I think is concerned $\endgroup$
    – Popi
    Commented Sep 18, 2023 at 12:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .