Author Topic: Linear Workflow with Substance  (Read 39626 times)

Hey Elowan, I was just watching the end of part 3 of the video series I posted above and he shows that (in this instance Maya) that when Physical Sky is enabled, it actually adds a 2.2 Gamma correction to the camera.  Perhaps this also happens with the likes of Skyshop/Toolbag2 and Unity 5.  This topic gets bigger the more I delve :)

Really enjoyed reading this informative conversation gents.  I thought I would post this really good video by zeth willie expalining Linear Color space

@Wes, for export to Alloy2 (Unity4) I pack four linear grayscale maps into a RGBA node for single output.  Will this RGBA output publish as sRGB or Linear?

Thanks.

Hi,

It will publish as sRGB, but Alloy has option to set the channels to be interpreted as linear as they are "unpacked."

Cheers,

Wes 
Integrations Product Manager / Training
wes.mcdermott@allegorithmic.com
Twitter: The3DNinja

This helps a lot, Wes, as always. Thank you!
Now I only have to check out how to work only sometimes in 16 bit, as you mentioned. ;)
Do you have a simple example for working in 16 bit and convert to 8 bit "at different areas"?
You said I could work in the graph faster when using 8 bit instead of 16. How does it affect the graph? Is the difference so much?

Hi,

It can make a difference is graph speed as many 16 bit nodes means more data to process. I posted an image that shows a noise with levels operations taking place in 16bpc. It is then blended with 8bpc. With the Blend node, the primary input will dictate the bpc. In the case of color (RGB) as shown in the image, blending with 8bpc uniform color results in an 8bpc result. If it is grayscale, the blend node result would still be 16bpc as the primary input is 16bpc. However, you would then just add a levels as a pass through to convert to 8bpc. In the base parameters of each node, you can change the output format (16 or 8bpc).

Cheers,

Wes
Integrations Product Manager / Training
wes.mcdermott@allegorithmic.com
Twitter: The3DNinja

You can export in 16 bit float in export dialog as well as set channels to be 16 bit float. If you export height, roughness, normal in 16 bit, it will be "assumed" linear. This means that these files will be flagged as linear in the shader. If you were to author a 16 bit base color, it would need to be sRGB. Base color, diffuse, specular color are never interpreted as linear no matter the bit depth.

The outputs for SD and SP are the same.

Cheers,

Wes

Hey Wes,

good read and very informative. But I do not understand the last part, that I quoted.
Who "assumes" 16bit or above images to be "linear"? Every shader/engine?

Normal maps, calculated in SD 4.6.1, are 24bit png (when you save them by hand in "png" format)

So maybe this could be the reason, why I should switch "sRGB" off in Toolbag2, when loading such a normal? (So it would be calculated as linear and displayed as sRGB)?
Like I wrot in e-mail yesterday, I get drastically different results when checking "Scale&Bias" in addition to "sRGB".

That brings me to the question, if it makes sense exporting normal maps and color maps higher than 8bit depth per channel? Sure, for heightmap/displacement you would set 16bit or even higher than that (as the are "greyscale maps" that "contains precise computation data")
But for albedo? Or even for a normal map?

Cheers!

Hi Elowan,

By "assumed" I meant that since these maps represent mathematical data such as roughness (microsurface), light vectors (normal) these maps are to be treated as linear. No maps are authored in linear space. The maps are only interpreted as linear. The shader and the engine need to be told these maps are linear in most cases, but is can be assumed that these map types should be linear.

The normal map exported from SD should be 16bit. There could be an situation where a node is overriding the output format and demoting the image to 8bpc. If you save the 16bpc from the viewport as PNG, is should be 16bpc. I wouldn't export albedo as 16bpc. Its probably not needed. However, 16bpc for normal will have more accurate light vector information.

Cheers,

Wes



 
Integrations Product Manager / Training
wes.mcdermott@allegorithmic.com
Twitter: The3DNinja

How are you guys getting these linear values? I just put the equation into my calculator and the answer was wrong :(

How are you guys getting these linear values? I just put the equation into my calculator and the answer was wrong :(

Hi,

What equation did you use? What was the process?

Cheers,

Wes
Integrations Product Manager / Training
wes.mcdermott@allegorithmic.com
Twitter: The3DNinja

Hi,

It can make a difference is graph speed as many 16 bit nodes means more data to process. I posted an image that shows a noise with levels operations taking place in 16bpc. It is then blended with 8bpc. With the Blend node, the primary input will dictate the bpc. In the case of color (RGB) as shown in the image, blending with 8bpc uniform color results in an 8bpc result. If it is grayscale, the blend node result would still be 16bpc as the primary input is 16bpc. However, you would then just add a levels as a pass through to convert to 8bpc. In the base parameters of each node, you can change the output format (16 or 8bpc).

Cheers,

Wes

I don't really get what image you are referring to :/
I'll try that out in SD and see how to change the Bits Per Channel and trying to develop a workflow with that information. Thanks, Wes! ;)
Environment Artist - Twitter

Hi,

It can make a difference is graph speed as many 16 bit nodes means more data to process. I posted an image that shows a noise with levels operations taking place in 16bpc. It is then blended with 8bpc. With the Blend node, the primary input will dictate the bpc. In the case of color (RGB) as shown in the image, blending with 8bpc uniform color results in an 8bpc result. If it is grayscale, the blend node result would still be 16bpc as the primary input is 16bpc. However, you would then just add a levels as a pass through to convert to 8bpc. In the base parameters of each node, you can change the output format (16 or 8bpc).

Cheers,

Wes

I don't really get what image you are referring to :/
I'll try that out in SD and see how to change the Bits Per Channel and trying to develop a workflow with that information. Thanks, Wes! ;)

Oh, I'm sorry Fabian. I forgot to attach the screen shot : ) This will help.

Cheers,

Wes

Integrations Product Manager / Training
wes.mcdermott@allegorithmic.com
Twitter: The3DNinja

How are you guys getting these linear values? I just put the equation into my calculator and the answer was wrong :(

Hi,

What equation did you use? What was the process?

Cheers,

Wes

I used the equation in this post ((rgb value)/255)^2.2

My calculations with this equation were also wrong when I tried them out yesterday.
For example:
sRGB Red Channel Value: 20 (like in the example by Wes)
My calculation:
(20/255)^2.2. Answer: 0.0036...
0.0036...*255 = 0.9427...
Instead of 10, my equation doesn't even get to 1...

It seems I'm getting something wrong. Or: The equation is not correct.
Environment Artist - Twitter


The normal map exported from SD should be 16bit. There could be an situation where a node is overriding the output format and demoting the image to 8bpc. If you save the 16bpc from the viewport as PNG, is should be 16bpc. I wouldn't export albedo as 16bpc. Its probably not needed. However, 16bpc for normal will have more accurate light vector information.

Cheers,

Wes



The viewport stats "16bpc" but when saving (with little floppy icon) and open in PS, the PNG is just 8bit. When saving as .PSD, it is 16bit...

I set every node possible not relative to input, but "Absolute 16bpc".. does not help.
Seems, png will only save 8bit (tested 8bit png and 16bit psd in Toolbag - makes no difference, except one:)

the psd normal map is displayed the same (and correct) way, when "sRGB" is checked... the png normal does not - only correct, when sRGB is unchecked.


Cheers

The viewport stats "16bpc" but when saving (with little floppy icon) and open in PS, the PNG is just 8bit. When saving as .PSD, it is 16bit...

I set every node possible not relative to input, but "Absolute 16bpc".. does not help.
Seems, png will only save 8bit (tested 8bit png and 16bit psd in Toolbag - makes no difference, except one:)

the psd normal map is displayed the same (and correct) way, when "sRGB" is checked... the png normal does not - only correct, when sRGB is unchecked.


Cheers

Set your output Node to RGBA16 and it will export as 16bit.  I just tested this by exporting to .png and opened in Photoshop to verify.

 

My calculations with this equation were also wrong when I tried them out yesterday.
For example:
sRGB Red Channel Value: 20 (like in the example by Wes)
My calculation:
(20/255)^2.2. Answer: 0.0036...
0.0036...*255 = 0.9427...
Instead of 10, my equation doesn't even get to 1...

It seems I'm getting something wrong. Or: The equation is not correct.

Hi Fabian,

It looks like you are missing a the step for converting from linear float to sRGB from the previous post.  It should be as follows...

(20 / 255) ^ 2.2 (convert to linear)
0.00369723957 ^ 0.4545 = 0.07845133995 (linear float to sRGB float)
0.07845133995 * 255 = 20.0050916873 (20) (convert sRGB float to sRGB integer)

Cheers,

Wes
Integrations Product Manager / Training
wes.mcdermott@allegorithmic.com
Twitter: The3DNinja

How are you guys getting these linear values? I just put the equation into my calculator and the answer was wrong :(

Hi,

What equation did you use? What was the process?

Cheers,

Wes

I used the equation in this post ((rgb value)/255)^2.2

Hi,

You might be missing the other steps which are going from linear float -> sRGB float -> sRGB integer.

(20 / 255) ^ 2.2 (convert to linear)
0.00369723957 ^ 0.4545 = 0.07845133995 (linear float to sRGB float)
0.07845133995 * 255 = 20.0050916873 (20) (convert sRGB float to sRGB integer)

Cheers,

Wes
Integrations Product Manager / Training
wes.mcdermott@allegorithmic.com
Twitter: The3DNinja

How are you guys getting these linear values? I just put the equation into my calculator and the answer was wrong :(

Hi,

What equation did you use? What was the process?

Cheers,

Wes

I used the equation in this post ((rgb value)/255)^2.2

Hi,

You might be missing the other steps which are going from linear float -> sRGB float -> sRGB integer.

(20 / 255) ^ 2.2 (convert to linear)
0.00369723957 ^ 0.4545 = 0.07845133995 (linear float to sRGB float)
0.07845133995 * 255 = 20.0050916873 (20) (convert sRGB float to sRGB integer)

Cheers,

Wes

I need to set up this equation in a ti 83 or something... I really wish you guys would give us RGB values in the colour picker... would make my life easier