THen what is the difference between linear, noncolor and raw? if the output is the same
Linear is linear color space. So this means that it is treated as such if color space conversions are needed. Non-color will never be touched by color management. I do not really know a lot of use cases for these, but they make sense to me, I am sure there are cases where this might get important, however RAW and Non-Color differs only in meaning: RAW should be treated as color, but then should not be color managed, which is ridiculous, because Non-Color is exactly the same. It would not be a big deal if it did not confuse people. It does. There is no need for it to exist. The name could be changed to Not Color Managed and that would mean both things.
Yes true.
eg. Normalmaps or Heightmaps
It’s quite hard to get this discussion any further, you know that all colorspace choices have different semantic meanings, some include additional processing some dont.
You say when they don’t get further processed they may not have a different meaning or at least no different description to say what has been put into the image.
Yes, obviously. Sorry, I meant to say I don’t know many use cases for having them separated. One can(even though it might be argued that one shouldn’t only because of the semantics) use Linear and RAW for normal or height maps as well. It works, because the important thing is for them not to be treated as sRGB and therefore converted to linear before rendering. During rendering normal or height maps are not seen as color in any way, they just influence the shading or geometry so there is no chance for them to go through any color transforms. I think Non-Color and Linear separated might make sense if one is specifically working with some color conversions or something, but RAW and Non-Color should be the same to make it simple to understand and use. My question was if I am missing anything here. There is no need for discussion if I am not missing anything in this. I am just hoping some developer might see this feedback and decide fix this, if it makes sense. I think it would improve user experience related to color management that can sometimes get quite miserable when you encounter it for the first time…
Ok. No, if we are just talking of raw and non-color these could theoretically be set to one and the same type, I am quite sure no problems would arise from that. We just disagree on if it’s a thing that makes it more complicated and if it’s helpful to have a differentiation or not.
You disagree? Could you explain the reasoning? What is that distinction of these two color space options practically useful for or could theoretically be in the future?
First, that’s just my opinion. If you want some official statement you have to wait if a dev sees it and replies.
So for me, it is a description of what is stored in the image. And so it’s a just an information for you when you read nodegraphs ( especially if you didn’t design them).
If I would change something here, I’d say give every option a tooltip, with a good description, then everybody who uses it the first time will be able to get it. And I’d rename XYZ to CIEXYZ, XYZ is heavily misleading.
I find the benefit of having one entry less quite minimal.
Sorry I know you see it differently and I can see why, it’s just that I think different about it.
The question of a practical future use is a bit open ended, perhaps some automatic checks that tell me that I’m using a image wrong, if a non-color data image is connected to an color-image data socket. Many different things might be possible with that and supporting the user might be the most obvious possibility.
I honestly did not see any use for it so it is interesting for me to know this perspective. Personally I think there are a lot better tools to make node trees easier to read and understand like for example labeling the nodes, making node groups and using node frames and reroute nodes. But if you find use for these color space settings, that’s great. I couldn’t agree more about CIE XYZ and tooltips. I think logical naming and tooltips as well as documentation could solve the problem I see with all this equally well as removing the RAW option if it is after all useful for something.
If you wonder what is exactly the difference between the colorspace settings, you can inspect the config.ocio file where everything is defined.
You will see that Non-Color and Raw are identical and will behave the same in any situation:
- !<ColorSpace>
name: Non-Color
family: raw
equalitygroup:
bitdepth: 32f
isdata: true
allocation: uniform
allocationvars: [0, 1]
- !<ColorSpace>
name: Raw
family: raw
equalitygroup:
bitdepth: 32f
isdata: true
allocation: uniform
allocationvars: [0, 1]
2 Likes