2
$\begingroup$

I'm trying to render surface normals for my scene, and I've gotten it to work in Blender 2.78. One of the important steps was to eliminate the gamma correction which was whitening the image. I did this in 2.78 by doing

scene.view_settings.view_transform = 'Raw'

Unfortunately I also need this to work in Blender 2.69, but I can't find the appropriate setting as the 'Raw' enum was introduced after 2.69.

I've tried setting it to 'NONE' (which the Blender 2.69 API lists as an option) but this throws an error saying that the only option is 'Default'. I've also tried directly setting

scene.view_settings.gamma = 0.0

But this has no effect.


Update: Thanks for your answer, Troy. Ultimately I'm trying to create a png image with the surface normals that I'll use for another task. This other task needs me to remap the colors of the surface normals (to look like this: https://arxiv.org/pdf/1411.4958v1.pdf).

I'm definitely open to using another path to producing normals, but I need to use only Python scripting. Non-color Data sounds promising. Would I be able to render something using nodes, and then save that render (from an output node, not from the RenderLayer) as Non-color Data? Please let me know if I'm not being clear!


Update 2: Thanks, Sambler. When I set scene.display_settings.display_device = 'XYX' I get TypeError: bpy_struct: item.attr = val: enum "XYZ" not found in ('sRGB').

Trying to change

scene.display_settings.display_device = 'sRGB'
scene.view_settings.view_transform = 'Raw'

yields TypeError: bpy_struct: item.attr = val: enum "Raw" not found in ('Default')

This question seems pertinent. In this question the solution was to reinstall Blender. As I'm working on a shared cluster, to ask the admin to reinstall Blender in order to help me debug is, ideally, a last resort.

$\endgroup$
  • $\begingroup$ PNG is a less that sub optimal format. If you render to EXR and flag as Non-Color Data you should be absolutely fine. This can also be done via Python of course. Never use PNG, it is a truly worthless format. $\endgroup$ – troy_s Nov 8 '16 at 14:32
  • $\begingroup$ Rather than asking to reinstall - consider asking to update to something less than 3 years old. On the remote blender what do you get for bpy.app.ocio.supported $\endgroup$ – sambler Nov 9 '16 at 8:40
4
$\begingroup$

Wrong approach.

Simply render or load an image and tag it as Non-color Data in the UV Image editors properties panel. Being a good imager, you are already using the EXR format exclusively, as it is a linearized, high precision encoding format for both colour and data.

The Non-color Data tag keeps the buffer entirely out of the colour transform pipeline.

I'm definitely open to using another path to producing normals, but I need to use only Python scripting. Non-color Data sounds promising. Would I be able to render something using nodes, and then save that render (from an output node, not from the RenderLayer) as Non-color Data? Please let me know if I'm not being clear!

The colour transform tag on an image buffer is only metadata, and as such, if you save that buffer as an EXR, there is nothing more that you need to do. Simply load the EXR, then use Python to set the buffer's tag to Non-Color Data and you are done. Those values will not be put through any view transform.

It should be noted that when viewing Non-Color Data in the viewport, it might seem that the view is identical to when it is set to linear. The difference is that linear is defined as a colour transform and will get passed through various transforms, where, as stated above, Non-Color Data always will pass through untransformed.

$\endgroup$
  • $\begingroup$ Hey that's a good tip, I didn't know this ;-) $\endgroup$ – 3pointedit Nov 8 '16 at 3:13
-1
$\begingroup$

scene.view_settings.view_transform is part of the colour management settings, the values accepted vary based on the display device setting. I see the same values available in 2.68 and 2.78

When scene.display_settings.display_device == 'None' view_transform can only be set to 'Default'

When display_device == 'Rec709' view_transform can be set to 'Default' or 'RRT'

When display_device == 'XYZ' view_transform can be set to 'Default', 'RRT', 'DCI', 'Raw' or 'Log'

When display_device == 'sRGB' view_transform can be set to 'Default', 'RRT', 'Film', 'Raw' or 'Log'

$\endgroup$
  • $\begingroup$ That is the view transform. Views have nothing to do with internal representation of data, nor the issue of data based buffers such as the OP's question, which setting data to Non-Color Data keeps the buffer out of the transformation chain. $\endgroup$ – troy_s Nov 8 '16 at 19:30
  • $\begingroup$ It is the setting being changed in 2.78 that produced the desired result but fails in 2.69. It may not be the best solution but it is what is failing. $\endgroup$ – sambler Nov 9 '16 at 8:32
  • $\begingroup$ Sorry, no. It is completely misunderstanding colour management. You do not disable a view. Views are for colour data. You tag data that isn't colour as such. It isn't terribly complex. $\endgroup$ – troy_s Nov 9 '16 at 8:37
  • $\begingroup$ But he is trying to disable colour management so that a rendered image isn't adjusted by the colour management. I would expect only one render from the scene is desired this way so disabling colour management for one render could be easier than changing each image setting based on the render being done. But that's just an assumption. $\endgroup$ – sambler Nov 9 '16 at 8:54
  • $\begingroup$ "But he is trying to disable colour management so that a rendered image isn't adjusted by colour management." This is precisely what is addressed via EXR. Non-Color Data should also work on some display referred image formats. $\endgroup$ – troy_s Nov 9 '16 at 14:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.