PBR > Linear Workflow Queries...
polycounter lvl 9
Hi guys,
so I'm tip-toeing more and more into PBR and reading the resources on the wiki (love the bible
) and I'm trying to get my head around gamma correction and a linear workflow.
I understand that when an image is shot via camera, what it actually shoots and what is on display is different due to the gamma adjustment on monitors/displays etc and so itll look more washed out and brighter.
I also understand that looking at the gamma curve, the midpoint of 0-255 would be a value of 187 not 128, despite a straight curve from 0-1 suggesting 128 as the position of 0.5 is 187.
So now I understand how gamma works, and that what I'm looking at is wrong; how do I go about correcting this? I applied SRGB and a gamma ratio of 2.2 within my photoshop colour settings (not sure if this is correct or not just something I read....) but I want to understand WHY I have to do this; and what doing this will actually be doing.
I also wanted to query on what this yellow line of the gamma graph is?
http://filmicgames.com/archives/299
Sorry if I'm not making too much sense, I just would like to fully understand why I have to do something a set way rather then just following steps blindly.
Cheers and its much appreciated!!
so I'm tip-toeing more and more into PBR and reading the resources on the wiki (love the bible
) and I'm trying to get my head around gamma correction and a linear workflow.I understand that when an image is shot via camera, what it actually shoots and what is on display is different due to the gamma adjustment on monitors/displays etc and so itll look more washed out and brighter.
I also understand that looking at the gamma curve, the midpoint of 0-255 would be a value of 187 not 128, despite a straight curve from 0-1 suggesting 128 as the position of 0.5 is 187.
So now I understand how gamma works, and that what I'm looking at is wrong; how do I go about correcting this? I applied SRGB and a gamma ratio of 2.2 within my photoshop colour settings (not sure if this is correct or not just something I read....) but I want to understand WHY I have to do this; and what doing this will actually be doing.
I also wanted to query on what this yellow line of the gamma graph is?
http://filmicgames.com/archives/299
Sorry if I'm not making too much sense, I just would like to fully understand why I have to do something a set way rather then just following steps blindly.
Cheers and its much appreciated!!
Replies
So if I'm choose SRGB as my colour values, and I understand that an image when viewed contains gamma and therefore is wrong; how do I make it right; how do I ensure its a linear workflow; using SRGB is one point but how do I "correct" my input image/texture.
I don't fully understand that but i'll be sure to take note and research more into it
keep em coming guys!
learnt that SRGB is identical to a standard 2.2 curve. So I'm guessing the reasoning for its use is simply a wider range of colour values.
If a texture im using is downloaded, its got gamma on and I need to correct to for PBR. How and why is this done. Is it simply converting it to a standard 16bit-SRGB within photoshop? What is the reasoning for using SRGB other then more colour values?
I thought aslong as the colour values being input were gamma corrected and the output was SRGB it would be linear.
Working in sRGB is ok when you are dealing with visual colors...because you need to be able to visually comprehend the colors, to choose colors that make sense for your eyeballs.
This isn't true when working with DATA. Data needs to be linear. What is data? Measured specular color is data, Roughness maps or metalness maps are data, normal maps are data, opacity maps are data, etc. These maps represent a value used for math, NOT a visual color.
Many engines now assume you are authoring textures in sRGB, and allow you to individually mark textures as Linear or sRGB for this reason (so they can correct one way or the other).
DATA needs to be stored and read in linear space. You can't feed sRGB data to a source that expects it to be linear, because it will be interpreted WRONG. If you are in photoshop working in sRGB, you make your roughness map 50% grey, and you store the texture in your engine as sRGB - then you feed that into a shader expecting your roughness to be linear, it will be WRONG - it won't be giving you 50% roughness.
Now roughness in particular is an artist-driven map, so you are meant to eyeball it. However, try applying this analogy to opacity, or self-illumination. If you make something 50% grey you are usually expecting to be a 50% value, not a 20% or something. There's a big difference. If you are working with soft gradients, those gradients could be getting crushed and skewed badly.
I don't claim to be an expert here, but this is more or less my understanding. Make sure all your maps that represent data are being stored/read in linear space, and authored appropriately, but if it's color you should be authoring in sRGB and letting the engine know that as well.
So realistically an albedo would never be considered Linear? only its data maps (i.e pretty much everything else). So it would be physically correct to produce in Photoshop using an SRGB 16 bit file and just work on it before plugging into engine as an SRGB.. So pretty much ensure SRGB, 16 bit is on and i can paint whatever i want?!
The rest of the maps on the other hand would have to be linear; the issue I'm finding now is how would I make these linear? What gamma corrections or some sort of voodoo would I do to my normal map; or gloss or spec map to make it physically accurate and linear?
textures sRBG+2.2 gamma greys--->hard drive-linear data--->engine--->monitor--->gamma correct
Here's a good quote from that resource:
Normal maps are all linear, they always have been, you don't need to worry about conversion. You just need to make sure they are stored linearly. Seems Cryengine does this by default, and many engines probably try and guess/flag normal maps as linear by default.
In my example above - we want to author a roughness map that is a value of 50%. This is at least partially a perception problem - Our eyeballs can't perceive linear values. In linear, 50% grey is 187. That looks all jacked up to us.
However, you can't work in sRGB, make a value that is 128, then feed it into some math that expects linear values. That math is expecting that middle grey = 187, not 128.
So, you either need to author that data in linear space (which can be done in photoshop, but it gets a bit hairy) - or you can author in sRGB and correct for linear before saving (e.g. raise to Power of 2.2 with Levels). Or even better you can author that data in an app that supports linear (e.g. substance designer) and create the data in the right range in the first place. Then you flag it in your engine as Linear data, because you know it's made right. Any of these would work.
Now Cryengine (I assume UE4 is the same) says - hey don't worry about any of that, I can convert sRGB to Linear for you! Just check this sRGB flag! That's cool and all, but keep in mind this only works for RGB channels. Alpha channels are assumed to be linear and stay linear, always. If you are storing Linear data in a Linear alpha channel, you absolutely must find a way to author that data in Linear when you create it. No engine flags that I know of are gonna fix it for you.
But, yeah, you could create your DATA in sRGB and depend on flags to convert it for you on the fly, if you wanted. DON'T EVER FORGET TO FLAG IT THOUGH.
I don't have all the answers. What I know is that when it comes to working with Linear data you gotta stop trusting your eyeballs, and start trusting numbers. If you can find a way to work in linear, it makes it a lot easier.
SRGB is for colour textures only; e.g albedo; Aslong as I produce these in photoshop using SRGB- but I must remember to FLAG this as SRGB within engine - so that it can convert this to linear and be accurate.
DATA maps must be linear; and so there are a few ways to go about this.
I can work in photoshop using SRGB and remember to use linear values - 187 is and always will work as half the range of 256. Working out all this on the the fly whilst working will get incredibly confusing, or I can work in standard SRGB values, forget about linear conversion until the maps finished in which I would then adjust the levels equiv to 2.2 to modify all the colours within for an accurate gamma adjustment and better visual. This must then be FLAGGED as linear within engine - we known we've made it accurate and need it to be processed without an additional gamma changed being calculated for us.
There is a method in which you can rely on the engines to convert a SRGB data map to a linear value via flagging it, but this works for RGB channels only and without knowing how linear works properly may give you undesired results? I.e. we might not realise how much this could change our original texture.
Substance painter and bitmaptomaterial already understand the difference between the two and take into account SRGB to linear values and so using these within SRGB before then flagging as SRGB within engine will convert it to linear.
Aslong as what I've just said is correct I think I got it
all I have to do to any texture I create or download is use SRGB and at the end apply a levels equivalent to 2.2 to counteract the gamma added by devices? (for albedo)
You simply download an albedo texture, open it in Photoshop, adjust it to your liking, export it with sRGB color profile (in the save dialog) and import it into your game engine. In the engine you will find option to tag your texture as either linear or sRGB. There is no need to apply a 2.2 levels adjustment layer in Photoshop.
I wrote a couple of more lines in your other thread.