linear color space issues (2.73 rc1) #43025

New Issue

Alessandro Padovani · 2014-12-26T14:41:47+01:00

2014-12-26 14:41:47 +01:00

there are some issues in the linear color space managament

The color input slot is not consistent.

The color weel and the HEX and HSV tabs show the color values in sRGB space, while the RGB tab shows the color vaues in linear space.

For example, if you set the color to mid-dark red, that is sRGB 0.5 0.5 0.5, you get HEX 80 00 00 HSV 0 1 0.5 and the color weel positioned to pure red in the disk and half bright in the side bar, that are all correct representations of the sRGB mid-dark red values. While the RGB tab shows 0.214 0 0, that is the linear space value.

It would be correct to have an option, perhaps in the user preferences panel, to let the user choose between linear or sRGB input. In general artists used to Painter or Photoshop will find themselves comfortable with sRGB input.

The material color values are changed when changing the display color space and/or when importing/exporting objects.

For example, if you set the color to dark red HEX 80 00 00, then switch the display device from sRGB to REC709, the dark red becomes HEX 73 00 00, if you switch the display device to none, the dark red becomes HEX 37 00 00.

Is seems that in blender the color space is not assigned to the material. So that when the user changes the display color space, then the color values change too. This doesn't make sense since if a color is defined in sRGB space, its definition (values) is the same and doesn't change whatever color space the material is displayed to. That is, changing the output device must not change the color values assigned to a material.

It would be correct to assign a color space to the material, so that the material color values don't change when changing the output color space. If the artist assign the dark red in sRGB space 0.5 0 0 value to a material, he/she expects that the value doesn't change when changing the output device.

Also there are issues when exporting objects. For example exporting the dark red HEX 0.5 0 0 to obj gets exported to 0.4 0 0 in the mtl file.

Also there are issues when importing objects. For exampe, if I have an obj with HEX 0.5 0 0 in the mtl, it gets imported as linear value instead of being imported as sRGB value. This again doesn't make sense since the mtl file defines sRGB values and not linear values.

This automatic linear space assumption is applied for every import/export format it is not limited to obj. And this doesn't work since almost every import/export format such as obj 3ds lwo etc have materials defined in sRGB space and not in linear space.

It would be nice to have an option, perhaps in the user preferences panel, to set the default color space used when importing objects.

It is a shame that even in 2.73 the color management system stills a mess. Please please fix it. It is time.

there are some issues in the linear color space managament 1) The color input slot is not consistent. The color weel and the HEX and HSV tabs show the color values in sRGB space, while the RGB tab shows the color vaues in linear space. For example, if you set the color to mid-dark red, that is sRGB 0.5 0.5 0.5, you get HEX 80 00 00 HSV 0 1 0.5 and the color weel positioned to pure red in the disk and half bright in the side bar, that are all correct representations of the sRGB mid-dark red values. While the RGB tab shows 0.214 0 0, that is the linear space value. It would be correct to have an option, perhaps in the user preferences panel, to let the user choose between linear or sRGB input. In general artists used to Painter or Photoshop will find themselves comfortable with sRGB input. 2) The material color values are changed when changing the display color space and/or when importing/exporting objects. For example, if you set the color to dark red HEX 80 00 00, then switch the display device from sRGB to REC709, the dark red becomes HEX 73 00 00, if you switch the display device to none, the dark red becomes HEX 37 00 00. Is seems that in blender the color space is not assigned to the material. So that when the user changes the display color space, then the color values change too. This doesn't make sense since if a color is defined in sRGB space, its definition (values) is the same and doesn't change whatever color space the material is displayed to. That is, changing the output device must not change the color values assigned to a material. It would be correct to assign a color space to the material, so that the material color values don't change when changing the output color space. If the artist assign the dark red in sRGB space 0.5 0 0 value to a material, he/she expects that the value doesn't change when changing the output device. Also there are issues when exporting objects. For example exporting the dark red HEX 0.5 0 0 to obj gets exported to 0.4 0 0 in the mtl file. Also there are issues when importing objects. For exampe, if I have an obj with HEX 0.5 0 0 in the mtl, it gets imported as linear value instead of being imported as sRGB value. This again doesn't make sense since the mtl file defines sRGB values and not linear values. This automatic linear space assumption is applied for every import/export format it is not limited to obj. And this doesn't work since almost every import/export format such as obj 3ds lwo etc have materials defined in sRGB space and not in linear space. It would be nice to have an option, perhaps in the user preferences panel, to set the default color space used when importing objects. It is a shame that even in 2.73 the color management system stills a mess. Please please fix it. It is time.

Alessandro Padovani commented

2014-12-26 14:41:47 +01:00

Changed status to: 'Open'

Alessandro Padovani commented

2014-12-26 14:41:47 +01:00

Added subscriber: @padone

Alessandro Padovani commented

2014-12-26 14:50:46 +01:00

there are obvious errors in the above post but the board doesn't seem to let me modify my own posts, so I'm reporting the fixes below

where I say mid-dark red sRGB 0.5 0.5 0.5 of course I mean sRGB 0.5 0 0
HEX 0.5 0 0 stands for HEX 80 00 00
also color weel is for color wheel ..

p.s. before anyone replies that "this is the intended way" blender works:

I understand that linear space is the way to go for better rendering. But, it doesn't make sense for user input.

Any graphic application around use sRGB space to define colors. Artists understand sRGB values. That is, any artist can tell you what color is 0.5 0 0 in sRGB space, but you won't find any artist that can tell you what color is 0.5 0 0 in linear space, apart being some tint of red.

This is because linear space is designed for computations, it is not designed for user input. Forcing an artist to input colors in linear space is the same as forcing someone to enter numbers in binary format. Binary is for computations and not for user input. The user understand sRGB colors and decimal numbers, the user doesn't understand linear colors and binary numbers.

A simple way to allow sRGB input would be to add a sRGB tab together with the HSV HEX and RGB tabs. Also renaming RGB to Linear RGB would greatly help to avoid confusion and/or frustration to the user.

As well the HSV HEX and color wheel should be defined in sRGB space and they should not change values when changing the output color space (display device).

Also imported materials (dae,fbx,obj,3ds etc) are sRGB and they should be stored as sRGB instead of being stored as linear values as Blender currently does.

Please undertand this is a very important issue for color managament and cross-platform color consistency so please don't just reply "this is the intended way". Since this way simply doesn't work.

there are obvious errors in the above post but the board doesn't seem to let me modify my own posts, so I'm reporting the fixes below where I say mid-dark red sRGB 0.5 0.5 0.5 of course I mean sRGB 0.5 0 0 HEX 0.5 0 0 stands for HEX 80 00 00 also color weel is for color wheel .. p.s. before anyone replies that "this is the intended way" blender works: I understand that linear space is the way to go for better rendering. But, it doesn't make sense for user input. Any graphic application around use sRGB space to define colors. Artists understand sRGB values. That is, any artist can tell you what color is 0.5 0 0 in sRGB space, but you won't find any artist that can tell you what color is 0.5 0 0 in linear space, apart being some tint of red. This is because linear space is designed for computations, it is not designed for user input. Forcing an artist to input colors in linear space is the same as forcing someone to enter numbers in binary format. Binary is for computations and not for user input. The user understand sRGB colors and decimal numbers, the user doesn't understand linear colors and binary numbers. A simple way to allow sRGB input would be to add a sRGB tab together with the HSV HEX and RGB tabs. Also renaming RGB to Linear RGB would greatly help to avoid confusion and/or frustration to the user. As well the HSV HEX and color wheel should be defined in sRGB space and they should not change values when changing the output color space (display device). Also imported materials (dae,fbx,obj,3ds etc) are sRGB and they should be stored as sRGB instead of being stored as linear values as Blender currently does. Please undertand this is a very important issue for color managament and cross-platform color consistency so please don't just reply "this is the intended way". Since this way simply doesn't work.

Sergey Sharybin was assigned by Bastien Montagne

2014-12-26 16:43:24 +01:00

Sergey Sharybin commented

2014-12-27 20:01:14 +01:00

First issue you're reporting is actually a duplicate of #41287.

Second issue you're reporting is not a bug at all. Changing display device would never affect render engine because render engines works in scene linear space. The behavior you've described is expected. More details about color pipeline you can find there http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management

I will merge the reports now.

First issue you're reporting is actually a duplicate of #41287. Second issue you're reporting is not a bug at all. Changing display device would never affect render engine because render engines works in scene linear space. The behavior you've described is expected. More details about color pipeline you can find there http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management I will merge the reports now.

Sergey Sharybin commented

2014-12-27 20:01:27 +01:00

Closed as duplicate of #41287

Sergey Sharybin closed this issue

2014-12-27 20:01:27 +01:00

Alessandro Padovani commented

2014-12-28 13:43:06 +01:00

Sergey thank you very much for your reply, but please read again my post. Either you didn't understand it or I wasn't able to explain.

In #41287 Mai Lavelle says that all values should be in linear space. This is obviously wrong and I'm saying exactly the opposite.
Unfortunately I know this is the expected behavior, and I'm trying to explain why this doesn't work.

Furthermore the link you point at explains the correct implementation of linear workflow and I agree with that, I already knew that document. Indeed what I'm trying to explain is why the actual implementation doesn't follow that guidelines and it is implemented wrong.

Please read below I'll really try to be as clear as possible this time. Again please read.

RENDERING MUST BE IN LINEAR SPACE for best rendering results. Actually Blender does a good job with this.

render engine (linear)

DISPLAY DEVICE CAN BE SRGB OR REC709 depending on the device used for output, PC monitor or TV. Of course rendering linear values must be converted back to display space to feed the 3d view. Actually Blender does a good job with this.

render engine (linear) -> 3d view (srgb,rec709)

EXTERNAL DATA SHOULD HAVE SRGB DEFAULT SPACE, unless a specific space is declared in the data format. This applies to textures and material colors of imported models.

Of course srgb must be converted to linear space to feed the rendering engine. It also must be converted to display space to feed the 3d view.

Actually Blender works well with textures but BLENDER FAILS WITH THE MATERIAL COLORS OF IMPORTED MODELS, since it assumes imported materials to be defined in linear space instead of srgb. This cause a gamma shift for imported models that use colors instead of textures. Models using only textures work well.

  CORRECT IMPLEMENTATION
  textures (srgb), imported materials (srgb) -> 3d view (srgb,rec709)
  textures (srgb), imported materials (srgb) -> render engine (linear)

  ACTUAL BLENDER IMPLEMENTATION (WRONG)
  textures (srgb), imported materials (linear) -> 3d view (srgb,rec709)
  textures (srgb), imported materials (linear) -> render engine (linear)

USER INPUT MUST BE IN SRGB SPACE such as color swatches, the color wheel and the color picker. You must think of the user input the very same as you think of imported textures. There is not any difference.

SRGB is the only color space artists understand and this is why/because every graphics app around use it for color input. Artists don't understand linear or rec709 values, they only understand srgb values. When an artist talks about RGB values the artist is meaning values in the SRGB space. Forcing an artist to enter linear values instead of srgb is the same as forcing someone to enter binary numbers instead of decimals. It does not make sense for the user.

Of course the color srgb values must be converted to linear space to feed the rendering engine, the same as it is done for textures.

Also of course the color srgb values must be converted to display space to feed the 3d view. This is also true for the color wheel as well. For the color picker it is true the opposite, the display space (3d view) must be converted to srgb to show to the artist the color values in srgb space.

ACTUALLY BLENDER DOES A MESS WITH THIS. That is, it doesn't convert anything at all. What is most odd is that the correct implementation is reported in the Blender docs, but the actual code doesn't implement it.

  CORRECT IMPLEMENTATION
  color swatches (srgb) -> render engine (linear)
  color wheel (srgb) -> 3d view (srgb,rec709)

3d view (srgb,rec709) -> color picker (srgb)

as reported in
Blender 2.56 Color Management

The above official Blender doc reports very clearly that the color swatch must be srgb and then converted to linear. This is the right implementation. The actual implementation is different and wrong since it doesn't convert anything.

  ACTUAL BLENDER IMPLEMENTATION (WRONG)
  color swatches (linear in RGB, display space in HSV HEX) -> render engine (linear)
  color wheel (display space srgb,rec709) -> 3d view (srgb,rec709)

3d view (srgb,rec709) -> color picker (display space srgb,rec709)

Sergey thank you very much for your reply, but please read again my post. Either you didn't understand it or I wasn't able to explain. 1) In #41287 Mai Lavelle says that all values should be in linear space. This is obviously wrong and I'm saying exactly the opposite. 2) Unfortunately I know this is the expected behavior, and I'm trying to explain why this doesn't work. Furthermore the link you point at explains the correct implementation of linear workflow and I agree with that, I already knew that document. Indeed what I'm trying to explain is why the actual implementation doesn't follow that guidelines and it is implemented wrong. Please read below I'll really try to be as clear as possible this time. Again please read. 1) **RENDERING MUST BE IN LINEAR SPACE** for best rendering results. Actually Blender does a good job with this. ` render engine (linear)` 2) **DISPLAY DEVICE CAN BE SRGB OR REC709** depending on the device used for output, PC monitor or TV. Of course rendering linear values must be converted back to display space to feed the 3d view. Actually Blender does a good job with this. ` render engine (linear) -> 3d view (srgb,rec709)` 3) **EXTERNAL DATA SHOULD HAVE SRGB DEFAULT SPACE**, unless a specific space is declared in the data format. This applies to textures and material colors of imported models. Of course srgb must be converted to linear space to feed the rendering engine. It also must be converted to display space to feed the 3d view. Actually Blender works well with textures but BLENDER FAILS WITH THE MATERIAL COLORS OF IMPORTED MODELS, since it assumes imported materials to be defined in linear space instead of srgb. This cause a gamma shift for imported models that use colors instead of textures. Models using only textures work well. ``` CORRECT IMPLEMENTATION textures (srgb), imported materials (srgb) -> 3d view (srgb,rec709) textures (srgb), imported materials (srgb) -> render engine (linear) ``` ``` ACTUAL BLENDER IMPLEMENTATION (WRONG) textures (srgb), imported materials (linear) -> 3d view (srgb,rec709) textures (srgb), imported materials (linear) -> render engine (linear) ``` 4) **USER INPUT MUST BE IN SRGB SPACE** such as color swatches, the color wheel and the color picker. You must think of the user input the very same as you think of imported textures. There is not any difference. SRGB is the only color space artists understand and this is why/because every graphics app around use it for color input. Artists don't understand linear or rec709 values, they only understand srgb values. When an artist talks about RGB values the artist is meaning values in the SRGB space. Forcing an artist to enter linear values instead of srgb is the same as forcing someone to enter binary numbers instead of decimals. It does not make sense for the user. Of course the color srgb values must be converted to linear space to feed the rendering engine, the same as it is done for textures. Also of course the color srgb values must be converted to display space to feed the 3d view. This is also true for the color wheel as well. For the color picker it is true the opposite, the display space (3d view) must be converted to srgb to show to the artist the color values in srgb space. ACTUALLY BLENDER DOES A MESS WITH THIS. That is, it doesn't convert anything at all. What is most odd is that the correct implementation is reported in the Blender docs, but the actual code doesn't implement it. ``` CORRECT IMPLEMENTATION color swatches (srgb) -> render engine (linear) color wheel (srgb) -> 3d view (srgb,rec709) ``` 3d view (srgb,rec709) -> color picker (srgb) as reported in [Blender 2.56 Color Management ](http:*web.archive.org/web/20130823123021/http:*www.blender.org/development/release-logs/blender-256-beta/color-management/) The above official Blender doc reports very clearly that the color swatch must be srgb and then converted to linear. This is the right implementation. The actual implementation is different and wrong since it doesn't convert anything. ``` ACTUAL BLENDER IMPLEMENTATION (WRONG) color swatches (linear in RGB, display space in HSV HEX) -> render engine (linear) color wheel (display space srgb,rec709) -> 3d view (srgb,rec709) ``` 3d view (srgb,rec709) -> color picker (display space srgb,rec709)

Antonis Ryakiotakis commented

2014-12-29 15:26:09 +01:00

Changed status from 'Duplicate' to: 'Open'

Antonis Ryakiotakis reopened this issue

2014-12-29 15:26:09 +01:00

Antonis Ryakiotakis commented

2014-12-29 15:26:09 +01:00

Added subscriber: @Psy-Fi

Antonis Ryakiotakis commented

2014-12-29 15:26:09 +01:00

Hi, there are workflows that are relevant in linear space and workflows that are relevant in display space. For instance, material definition (the actual number, not the color picked in the wheel) makes sense in linear space, since we are interested in the material interaction with the light and final color can depend on other factors. That said, color wheel display of colors should of course map to the display device.

Apart from that, the importer issue is indeed problematic and different so reopening.

Hi, there are workflows that are relevant in linear space and workflows that are relevant in display space. For instance, material definition (the actual number, not the color picked in the wheel) makes sense in linear space, since we are interested in the material interaction with the light and final color can depend on other factors. That said, color wheel display of colors should of course map to the display device. Apart from that, the importer issue is indeed problematic and different so reopening.

Brecht Van Lommel commented

2014-12-29 16:45:51 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2014-12-29 16:45:51 +01:00

In #43025#277568, @padone wrote:
Blender 2.56 Color Management

The above official Blender doc reports very clearly that the color swatch must be srgb and then converted to linear. This is the right implementation. The actual implementation is different and wrong since it doesn't convert anything.

To be clear, that document says that the design is to display the linear numeric values, see the screenshot with tooltip "Value in Linear RGB Color Space". In the terminology of that document, color swatch equals color wheel, it does not refer to the numeric values.

> In #43025#277568, @padone wrote: > [Blender 2.56 Color Management ](http:*web.archive.org/web/20130823123021/http:*www.blender.org/development/release-logs/blender-256-beta/color-management/) > > The above official Blender doc reports very clearly that the color swatch must be srgb and then converted to linear. This is the right implementation. The actual implementation is different and wrong since it doesn't convert anything. To be clear, that document says that the design is to display the linear numeric values, see the screenshot with tooltip "Value in Linear RGB Color Space". In the terminology of that document, color swatch equals color wheel, it does not refer to the numeric values.

Brecht Van Lommel commented

2014-12-29 17:22:55 +01:00

Are we sure that sRGB really is the default color space that is written to FBX, OBJ, .. files exported from modern versions of other 3D software? And is displaying sRGB numeric values in color pickers really the standard behavior in other 3D software?

As far as I know the following software matches Blender behavior:

Maya when using color management (since latest 2015 extension version)
Houdini 13
Nuke (I think the Blender 2.56 implementation matched this, so presumably still does)

It depends on the software I guess, so it would be good if some different software could be checked. But I don't think it's obviously true that we must assume external data is in sRGB colors. My guess is older software with no proper color management support will generally write sRGB values, and newer software will write linear values.

Are we sure that sRGB really is the default color space that is written to FBX, OBJ, .. files exported from modern versions of other 3D software? And is displaying sRGB numeric values in color pickers really the standard behavior in other 3D software? As far as I know the following software matches Blender behavior: * Maya when using color management (since latest 2015 extension version) * Houdini 13 * Nuke (I think the Blender 2.56 implementation matched this, so presumably still does) It depends on the software I guess, so it would be good if some different software could be checked. But I don't think it's obviously true that we must assume external data is in sRGB colors. My guess is older software with no proper color management support will generally write sRGB values, and newer software will write linear values.

Antonis Ryakiotakis commented

2014-12-29 17:32:13 +01:00

Hmmm...then it looks we can't assume srgb like I thought we could. Probably an import operator option can't be avoided in that case.

Sergey Sharybin commented

2014-12-29 17:59:42 +01:00

We can not assume sRGB that's for sure. If we want to support non-colormanaged output then we'll need to convert colors to display space (applying RGB curves, exposure/gamme, view and look).

Now, about that "if" statement. I'm not sure why would want to export data from color-managed pipeline and expect it to be the same in non-colormanaged pipeline. IMO we should just make sure when display space set to None (which disabled color management in blender) all the data is being properly exported and treated in non-colormanaged pipeline.

Trying to mix this two pipelines is weird and trying to support it just makes things unnecessarily complicated.

P.S. For that working correct we might need to make it so render engines could work with different chromatiques, but that we need to support anyway.

We can not assume sRGB that's for sure. *If* we want to support non-colormanaged output then we'll need to convert colors to display space (applying RGB curves, exposure/gamme, view and look). Now, about that "if" statement. I'm not sure why would want to export data from color-managed pipeline and expect it to be the same in non-colormanaged pipeline. IMO we should just make sure when display space set to None (which disabled color management in blender) all the data is being properly exported and treated in non-colormanaged pipeline. Trying to mix this two pipelines is weird and trying to support it just makes things unnecessarily complicated. P.S. For that working correct we might need to make it so render engines could work with different chromatiques, but that we need to support anyway.

Troy Sobotka commented

2014-12-29 18:08:33 +01:00

Added subscriber: @troy_s

Troy Sobotka commented

2014-12-29 18:08:33 +01:00

padone, assuming any single color space for the color wheel is simply incorrect, as outlined in the other report.

psy-fi is spot on when he suggests there are needs for both LDR curved input and linearized, as the other report sergey linked to illustrates. Even then, this doesn't deal with the complexities of chromaticity which also must be handled via the color management system.

Anecdotal and inaccurate statements are not required to highlight issues in the wheel and importers. It is useful to avoid invoking “all artists”, as many capable artists are well aware of color space complexities.

There are lingering color space issues in the wheel picker for certain and importer issues, but an imaging application must never force nor assume color spaces in a picker, and instead base the picker transforms off of the reference space, which can be variable based on rendering needs.

padone, assuming any single color space for the color wheel is simply incorrect, as outlined in the other report. psy-fi is spot on when he suggests there are needs for both LDR curved input and linearized, as the other report sergey linked to illustrates. Even then, this doesn't deal with the complexities of chromaticity which also must be handled via the color management system. Anecdotal and inaccurate statements are not required to highlight issues in the wheel and importers. It is useful to avoid invoking “all artists”, as many capable artists are well aware of color space complexities. There are lingering color space issues in the wheel picker for certain and importer issues, but an imaging application *must never* force nor assume color spaces in a picker, and instead base the picker transforms off of the reference space, which can be variable based on rendering needs.

Alessandro Padovani commented

2014-12-29 21:38:46 +01:00

Added subscriber: @Sergey

Alessandro Padovani commented

2014-12-29 21:38:46 +01:00

Thank you very much indeed for your reply to all of you, really. I see I have the Blender's best here so I hope to solve something.

@Psy-Fi
Traditional artists used to Photoshop or Painter don't understand linear values, they are used to define colors in the srgb space. Basically this is why a method to enter srgb values is needed.

Of course an artist can learn to work with linear values, or just use the HSV or HEX tabs to enter srgb values (having the display device in srgb space). But this is just uncomfortable at least. As I said it is as forcing someone to enter numbers in binary format instead of using decimals. At the end allowing srgb input is just a way to be kind with the user, and at the end this is what an interface is for.

I'm not saying that linear input is not needed, of course it is. I'm just saying that adding srgb input is needed to let traditional artists work their way.

@Sergey @brecht
srgb is for sure, it is the same as you handle srgb for png and jpg textures. The same applies to dae fbx obj and 3ds color materials.

For the old obj and 3ds formats this is of course true since linear workflow didn't exist at the time. But I'm pretty sure it is true even for dae and fbx. May be we could ask to khronos, but any forum around on dae or fbx or game design in general assumes srgb values for colors since games don't use a linear workflow for rendering.

Also, I can't see why we cannot import srgb materials in a color managed pipeline the same as we do for textures. It is not mixing two pipelines, it is just correctly importing srgb values for materials.

Also, I know Maya use srgb color swatches, then they convert them to linear using gamma nodes. See [Maya Linear Workflow Overview ]] and [ http:*knowledge.autodesk.com/support/maya/learn-explore/caas/CloudHelp/cloudhelp/2015/ENU/Maya/files/GUID-F7A7FC66-4D36-4544-9DBD-24FA35C66C2C-htm.html | Maya Color managed linear workflow

@troy_s
yes I agree, for "all artists" I mean traditional artists (Photoshop and Painter), I apologize. Anyway working with srgb colors in a in a 3D application (even with linear workflow) is advised by Eizo. For example Max works with srgb colors. Even Maya use srgb color swatches and then convert them to linear by using gamma nodes (see above).

Color Management with 3D CG by Eizo

Thank you very much indeed for your reply to all of you, really. I see I have the Blender's best here so I hope to solve something. @Psy-Fi Traditional artists used to Photoshop or Painter don't understand linear values, they are used to define colors in the srgb space. Basically this is why a method to enter srgb values is needed. Of course an artist can learn to work with linear values, or just use the HSV or HEX tabs to enter srgb values (having the display device in srgb space). But this is just uncomfortable at least. As I said it is as forcing someone to enter numbers in binary format instead of using decimals. At the end allowing srgb input is just a way to be kind with the user, and at the end this is what an interface is for. I'm not saying that linear input is not needed, of course it is. I'm just saying that adding srgb input is needed to let traditional artists work their way. @Sergey @brecht srgb is for sure, it is the same as you handle srgb for png and jpg textures. The same applies to dae fbx obj and 3ds color materials. For the old obj and 3ds formats this is of course true since linear workflow didn't exist at the time. But I'm pretty sure it is true even for dae and fbx. May be we could ask to khronos, but any forum around on dae or fbx or game design in general assumes srgb values for colors since games don't use a linear workflow for rendering. Also, I can't see why we cannot import srgb materials in a color managed pipeline the same as we do for textures. It is not mixing two pipelines, it is just correctly importing srgb values for materials. Also, I know Maya use srgb color swatches, then they convert them to linear using gamma nodes. See [Maya Linear Workflow Overview ]] and [[ http:*knowledge.autodesk.com/support/maya/learn-explore/caas/CloudHelp/cloudhelp/2015/ENU/Maya/files/GUID-F7A7FC66-4D36-4544-9DBD-24FA35C66C2C-htm.html | Maya Color managed linear workflow ](https:*www.youtube.com/watch?v=WZzmdKSYj7M) @troy_s yes I agree, for "all artists" I mean traditional artists (Photoshop and Painter), I apologize. Anyway working with srgb colors in a in a 3D application (even with linear workflow) is advised by Eizo. For example Max works with srgb colors. Even Maya use srgb color swatches and then convert them to linear by using gamma nodes (see above). [Color Management with 3D CG by Eizo ](http://www.eizoglobal.com/support/db/files/catalogs/ce/Color_Management_with_3D_CG.pdf)

Brecht Van Lommel commented

2014-12-29 23:45:03 +01:00

In #43025#277847, @padone wrote:
@Sergey @brecht
For the old obj and 3ds formats this is of course true since linear workflow didn't exist at the time. But I'm pretty sure it is true even for dae and fbx. May be we could ask to khronos, but any forum around on dae or fbx or game design in general assumes srgb values for colors since games don't use a linear workflow for rendering.

Also, I can't see why we cannot import srgb materials in a color managed pipeline the same as we do for textures. It is not mixing two pipelines, it is just correctly importing srgb values for materials.

FBX does not specify any color space, and I imagine the other file formats you mention do not either. I don't think we can assume that because it was not specified, that these files have sRGB colors. Is any modern 3D software with color management support actually converting linear to sRGB colors when writing these file formats? As far as I know they aren't doing that, so it doesn't make sense for us to assume that they do.

And even if we do the conversion, the lighting will not look the same anyway because in Blender it will have been computed in linear space, and in the other application it will have been computed in sRGB space. The only way to get the result the same is to not do any conversion on the values and disable color management in Blender.

Also, I know Maya use srgb color swatches, then they convert them to linear using gamma nodes. See [Maya Linear Workflow Overview ]] and [ http:*knowledge.autodesk.com/support/maya/learn-explore/caas/CloudHelp/cloudhelp/2015/ENU/Maya/files/GUID-F7A7FC66-4D36-4544-9DBD-24FA35C66C2C-htm.html | Maya Color managed linear workflow

Maya did not have a real color management system before, but they just added one this year, and as far as I can tell it works the same as Blender. You edit linear numeric values and it does conversion to sRGB for display.

> In #43025#277847, @padone wrote: > @Sergey @brecht > For the old obj and 3ds formats this is of course true since linear workflow didn't exist at the time. But I'm pretty sure it is true even for dae and fbx. May be we could ask to khronos, but any forum around on dae or fbx or game design in general assumes srgb values for colors since games don't use a linear workflow for rendering. > > Also, I can't see why we cannot import srgb materials in a color managed pipeline the same as we do for textures. It is not mixing two pipelines, it is just correctly importing srgb values for materials. FBX does not specify any color space, and I imagine the other file formats you mention do not either. I don't think we can assume that because it was not specified, that these files have sRGB colors. Is any modern 3D software with color management support actually converting linear to sRGB colors when writing these file formats? As far as I know they aren't doing that, so it doesn't make sense for us to assume that they do. And even if we do the conversion, the lighting will not look the same anyway because in Blender it will have been computed in linear space, and in the other application it will have been computed in sRGB space. The only way to get the result the same is to not do any conversion on the values and disable color management in Blender. > Also, I know Maya use srgb color swatches, then they convert them to linear using gamma nodes. See [Maya Linear Workflow Overview ]] and [[ http:*knowledge.autodesk.com/support/maya/learn-explore/caas/CloudHelp/cloudhelp/2015/ENU/Maya/files/GUID-F7A7FC66-4D36-4544-9DBD-24FA35C66C2C-htm.html | Maya Color managed linear workflow ](https:*www.youtube.com/watch?v=WZzmdKSYj7M) Maya did not have a real color management system before, but [they just added one this year](http://knowledge.autodesk.com/support/maya/learn-explore/caas/CloudHelp/cloudhelp/2015/ENU/Maya/files/GUID-90B0C582-C321-452B-B1CC-D00F41D36C3B-htm.html), and as far as I can tell it works the same as Blender. You edit linear numeric values and it does conversion to sRGB for display.

Antonis Ryakiotakis commented

2014-12-30 00:15:01 +01:00

@padone one extra note that blender artists are in fact used to tweaking linear values (the other bug report is about changing HSV to srgb and people didn't like that). But this bug report is quickly turning into a preference debate and this is not what the tracker is about.

The problem is to allow users to specify if material color values in assets are to be converted into linear. As @brecht said and @Sergey explained this will not fix lighting, but at least some artists should be able to get something close to the original color.

I will also try to improve the color pickers so users can choose the space where things are displayed.

@padone one extra note that blender artists are in fact used to tweaking linear values (the other bug report is about changing HSV to srgb and people didn't like that). But this bug report is quickly turning into a preference debate and this is not what the tracker is about. The problem is to allow users to specify if material color values in assets are to be converted into linear. As @brecht said and @Sergey explained this will not fix lighting, but at least some artists should be able to get something close to the original color. I will also try to improve the color pickers so users can choose the space where things are displayed.

Sergey Sharybin removed their assignment 2014-12-30 15:44:22 +01:00

Sergey Sharybin commented

2014-12-30 15:44:22 +01:00

not sure why it is assigned to me and not sure if it's a bug here or a discussion of a changes to the color pipeline. If it is the later one then this is not best place for this actually..

Alessandro Padovani commented

2014-12-30 17:10:15 +01:00

@brecht
fbx doesn't specify any color space because it is meant for game engines, that are not color managed. Assuming srgb for a game engine seems a good (and the only) choice to me.

In my opinion if a "modern" application writes linear values in a fbx file (or dae obj 3ds etc) then it is a mistake. At the very least the application should allow the user to choose the color space when exporting. And not forcing linear values.

I agree the lighting will not be the same, linear space gives better lighting to any material this is its purpose. But this doesn't mean that we can always import/export values as linear to any file format as Blender currently does.

@Psy-Fi
I agree this is a personal workflow choice and at the very end this is what I'm pointing out.

About the color pickers actually the "confusion" is to have the RGB tab linear, and the HSV HEX tabs in display space. Providing the two options to all tabs would allow Blender to meet any workflow.

Also allowing the artist to choose the color space for import/export would allow Blender to exchange models between traditional non color managed pipelines, and modern color managed pipelines. A great added value to push all those old srgb models into linear rendering :)

@Sergey
I believe the actual Blender color management is more than amazing. This topic is more a request for two options to allow Blender meet different workflows and pipelines. Absolutely it's not a request to change the color management system. I really apologize if I'm explaining bad, sorry.

Also, I'm sure we can agree that not any format is meant to support linear vaues, so forcing linear values to any import/export format as Blender actually does may be considered a bug or at least an improper behaviour.

I apologize again if I was misleading or out of topic sometime, absolutely it wasn't my purpose, sorry :)

@brecht fbx doesn't specify any color space because it is meant for game engines, that are not color managed. Assuming srgb for a game engine seems a good (and the only) choice to me. In my opinion if a "modern" application writes linear values in a fbx file (or dae obj 3ds etc) then it is a mistake. At the very least the application should allow the user to choose the color space when exporting. And not forcing linear values. I agree the lighting will not be the same, linear space gives better lighting to any material this is its purpose. But this doesn't mean that we can always import/export values as linear to any file format as Blender currently does. @Psy-Fi I agree this is a personal workflow choice and at the very end this is what I'm pointing out. About the color pickers actually the "confusion" is to have the RGB tab linear, and the HSV HEX tabs in display space. Providing the two options to all tabs would allow Blender to meet any workflow. Also allowing the artist to choose the color space for import/export would allow Blender to exchange models between traditional non color managed pipelines, and modern color managed pipelines. A great added value to push all those old srgb models into linear rendering :) @Sergey I believe the actual Blender color management is more than amazing. This topic is more a request for two options to allow Blender meet different workflows and pipelines. Absolutely it's not a request to change the color management system. I really apologize if I'm explaining bad, sorry. Also, I'm sure we can agree that not any format is meant to support linear vaues, so forcing linear values to any import/export format as Blender actually does may be considered a bug or at least an improper behaviour. I apologize again if I was misleading or out of topic sometime, absolutely it wasn't my purpose, sorry :)

Sergey Sharybin commented

2015-01-02 12:15:19 +01:00

@padone, i'm not really sure exporting stuff from color-managed to non-colormanaged pipeline is really best solution here. It will cause changes in lighting and compo as was rescribed earlier. Using non-colormanaged pipeline in blender would make it easier to preserve look and feel of the scenes.

In any case, i don't really see how blender fails here, just it's CM pipeline not actually matches your expectations. Improvements are possible, but they're handled outside of the bug tracker.

@padone, i'm not really sure exporting stuff from color-managed to non-colormanaged pipeline is really best solution here. It will cause changes in lighting and compo as was rescribed earlier. Using non-colormanaged pipeline in blender would make it easier to preserve look and feel of the scenes. In any case, i don't really see how blender fails here, just it's CM pipeline not actually matches your expectations. Improvements are possible, but they're handled outside of the bug tracker.

Alessandro Padovani commented

2015-01-03 07:48:23 +01:00

@Sergey
Thank you very much for your reply.

I just wanted to point out a problem that many users seem to have with the Blender CM. Just do a quick search on any blender forum and you'll see artists blaming washed out colors, colors not matching etc. But they can't seem to be able to understand why this happens. I just wanted to point out why this happens and a possible solution to this problem.

To be honest I still don't understand why you say this is not a bug. We can import/export srgb textures in the CM, but we can't import/export srgb materials. So if a model has srgb materials it must be handled outside of the CM. This seems just odd to me. srgb is just a color space as any other and I don't see any reason why the CM shouldn't handle this.

Anyway, if you say so, I don't want to interfere with your planning. I'm sure you have a good reason to do so. Also I see you marked a todo so there's hope to see something in the future.

As a todo, may be just two scripts, convert srgb to linear, and convert linear to srgb, could help artists solve their CM issues. As a workflow example:

To import a srgb model into a CM scene (dae,fbx,obj,3ds etc)

turn off CM by setting display device to none
import your model in Blender
run the convert srgb to linear script
turn on CM by setting display device to srgb

To export a CM scene to a srgb format (dae,fbx,obj,3ds etc)

turn off CM
run the convert linear to srgb script
export your scene

Finally, thank you very much indeed for the amazing work you guys do on Blender. I do really appreciate and respect your efforts. Blender is a wonderful piece of software and a great tool for any artist in the world. I strongly believe so. Of course it has issues we have to work around but this is true for every software, even very expensive ones.

very very best regards, Alessandro :)

@Sergey Thank you very much for your reply. I just wanted to point out a problem that many users seem to have with the Blender CM. Just do a quick search on any blender forum and you'll see artists blaming washed out colors, colors not matching etc. But they can't seem to be able to understand why this happens. I just wanted to point out why this happens and a possible solution to this problem. To be honest I still don't understand why you say this is not a bug. We can import/export srgb textures in the CM, but we can't import/export srgb materials. So if a model has srgb materials it must be handled outside of the CM. This seems just odd to me. srgb is just a color space as any other and I don't see any reason why the CM shouldn't handle this. Anyway, if you say so, I don't want to interfere with your planning. I'm sure you have a good reason to do so. Also I see you marked a todo so there's hope to see something in the future. As a todo, may be just two scripts, convert srgb to linear, and convert linear to srgb, could help artists solve their CM issues. As a workflow example: To import a srgb model into a CM scene (dae,fbx,obj,3ds etc) - turn off CM by setting display device to none - import your model in Blender - run the convert srgb to linear script - turn on CM by setting display device to srgb To export a CM scene to a srgb format (dae,fbx,obj,3ds etc) - turn off CM - run the convert linear to srgb script - export your scene Finally, thank you very much indeed for the amazing work you guys do on Blender. I do really appreciate and respect your efforts. Blender is a wonderful piece of software and a great tool for any artist in the world. I strongly believe so. Of course it has issues we have to work around but this is true for every software, even very expensive ones. very very best regards, Alessandro :)

Sergey Sharybin commented

2015-01-03 22:17:32 +01:00

If artists are confused with washed colors it totally worth making sure documentation of color pipeline is clear for them.

Materials import/export is:

Not limited to sRGB (since color management in blender is not limited to sRGB display space since 2.64).
You might be able to import/export materials, but render results wouldn't match which will also confuse artists.

The plan here i think would be to add some utility function in bpy so importers/exporters might do color conversion if they want. But such conversion on io shouldn't be something what belongs to core (meaning individual io scripts will deal with this).

If artists are confused with washed colors it totally worth making sure documentation of color pipeline is clear for them. Materials import/export is: 1. Not limited to sRGB (since color management in blender is not limited to sRGB display space since 2.64). 2. You might be able to import/export materials, but render results wouldn't match which will also confuse artists. The plan here i think would be to add some utility function in bpy so importers/exporters might do color conversion if they want. But such conversion on io shouldn't be something what belongs to core (meaning individual io scripts will deal with this).

Alessandro Padovani commented

2015-01-04 10:17:59 +01:00

Understood and agreed.

At the very end the "issue" here is that actual I/O scripts (including dae) are not CM aware so that they don't do any color conversion on import/export. And this is the "bug" I was pointing out.

My suggestion for two general purpose srgb conversion scripts was to have a fast workaround that artists could use to fix things when needed. Without having to wait for every I/O script to be rewritten. But enhancing individual I/O scripts with color conversion capabilities will work just fine once it is done.

It would be nice to have some of those new I/O scripts out in the 2.7x release, at least for dae, fbx, and obj that are the most used formats for I/O.

Thank you very much again for your reply and for the efforts you guys do in making Blender always better :)

Understood and agreed. At the very end the "issue" here is that actual I/O scripts (including dae) are not CM aware so that they don't do any color conversion on import/export. And this is the "bug" I was pointing out. My suggestion for two general purpose srgb conversion scripts was to have a fast workaround that artists could use to fix things when needed. Without having to wait for every I/O script to be rewritten. But enhancing individual I/O scripts with color conversion capabilities will work just fine once it is done. It would be nice to have some of those new I/O scripts out in the 2.7x release, at least for dae, fbx, and obj that are the most used formats for I/O. Thank you very much again for your reply and for the efforts you guys do in making Blender always better :)

Alessandro Padovani commented

2015-01-18 06:11:13 +01:00

one last point here ..

I just came across some old 2.49 models that I needed for some of my scenes. When appending those objects to the scene (file > append object) there's the same problem we have with external formats. The color values are assumed to be linear and are not converted from srgb to linear (2.49 color space is srgb). This way old Blender models get imported with washed out colors too.

So it seems Blender CM doesn't even handle the Blender format. It would be very useful to have a way to import those old models with correct colors in an actual scene. Or at least to have a tool to convert srgb values to linear when needed.

Please let me know what you think. Also please let me know if there's a fast way to convert srgb to linear that you know of. Actually I can't find any, I have to correct every single color by hand and this is a real PITA.

very best regards, Alessandro.

p.s. just found a link for srgb-linear conversion math, don't know if this could be useful to write a script http://entropymine.com/imageworsener/srgbformula/

Actually I just copy and paste the HEX values between none and srgb display device and this works fine, but as I said I have to do it by hand for every color and it's a PITA.

one last point here .. I just came across some old 2.49 models that I needed for some of my scenes. When appending those objects to the scene (file > append object) there's the same problem we have with external formats. The color values are assumed to be linear and are not converted from srgb to linear (2.49 color space is srgb). This way old Blender models get imported with washed out colors too. So it seems Blender CM doesn't even handle the Blender format. It would be very useful to have a way to import those old models with correct colors in an actual scene. Or at least to have a tool to convert srgb values to linear when needed. Please let me know what you think. Also please let me know if there's a fast way to convert srgb to linear that you know of. Actually I can't find any, I have to correct every single color by hand and this is a real PITA. very best regards, Alessandro. p.s. just found a link for srgb-linear conversion math, don't know if this could be useful to write a script http://entropymine.com/imageworsener/srgbformula/ Actually I just copy and paste the HEX values between none and srgb display device and this works fine, but as I said I have to do it by hand for every color and it's a PITA.

Alessandro Padovani commented

2015-01-25 01:54:37 +01:00

This is just to let you know that RickyBlender, of the Blender Artists forum, just released a script to convert srgb to linear and back. It is a prototype and some code cleanup is needed. But it works perfect.

sRGB Tools by RickyBlender

Thank you again for your useful answers and for making Blender always better :)

This is just to let you know that RickyBlender, of the Blender Artists forum, just released a script to convert srgb to linear and back. It is a prototype and some code cleanup is needed. But it works perfect. [sRGB Tools by RickyBlender ](http://blenderartists.org/forum/showthread.php?360140) Thank you again for your useful answers and for making Blender always better :)

Brecht Van Lommel commented

2023-03-21 19:09:29 +01:00

Archiving old report, there have been many changes to the color picker since. The current issue tracking potential improvements is #68926.

Brecht Van Lommel closed this issue

2023-03-21 19:09:30 +01:00

Blender Bot added

and removed

labels 2023-03-21 19:09:31 +01:00