PBR > Linear Workflow Queries...

Dave Jr

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!!

Dave Jr

Ok, so I've learnt that SRGB has a much larger ranger of colour and contrast values in comparison to standard RGB. Not only that but SRGB is used... pretty much everywhere allowing it to be much more consistent...

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.

JedTheKrampus

I don't exactly have the time to answer your question in full (sorry!), but I'd just like to say that if you're working in a linear color space in Photoshop, you should make sure that you're also using 16-bit color, otherwise you'll likely get nasty banding artifacts. Those show up less in 8-bit SRGB space because the detail in the color space is skewed more toward the low end, which is usually where you would texture, so you get enough precision to avoid artifacts.

JedTheKrampus

Also SRGB is non-linear, it's a gamma-2.2 space like you're used to working in.

Dave Jr

Ok, much appreciated;

I don't fully understand that but i'll be sure to take note and research more into it

keep em coming guys!

Dave Jr

Thanks,

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.

Dave Jr

I think the issues I'm struggling to comprehend is HOW the gamma becomes corrected...

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.

cman2k

Typing quickly - Here's how I've been thinking about it.

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.

Dave Jr

Wow thanks. Learnt a lot from that

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?

WaYWO

My understanding of this holly bible is that when create textures you want to make it as sRGB i think so assuming you are working with sRGB (the rights colors), it is linear on your hard drive then it comes in a game engine and your monitor fix it automatically or either make it sRGB on top of sRGB wich is not good so:

textures sRBG+2.2 gamma greys--->hard drive-linear data--->engine--->monitor--->gamma correct

cman2k

Here's a good resource: http://docs.cryengine.com/pages/viewpage.action?pageId=1605651

Here's a good quote from that resource:

Input Gamma
As mentioned above, most color images (photos and images painted in an image editing tool) are stored in sRGB space to make best use of the limited 8 bits of precision and reduce visible banding artifacts. However, there is a big caveat when using sRGB input images for rendering. Most of the rendering equations assume linear input values and as stated before, sRGB is exponential and hence not linear. Light accumulation for example should be done in linear space.

Modern GPU's support doing the sRGB to linear conversion on the fly when sampling a texture. It is only required to flag textures as sRGB. IN CryENGINE, the corresponding parameter can be set individually for each texture with the texture presets and settings.
sRGB should only be used for color textures, that is photos or textures that are painted in Photoshop. Other textures that contain computed data like normal maps should be stored with linear encoding, hence not as sRGB. Note as well that sRGB is only required for textures with 8 bits per channel. Texture formats with more bits have enough precision to store linear color values without banding artifacts.

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.

Dave Jr

Ok, so I think I get it:) i very much appreciate all your input! If you could confirm what I'm saying is correct it'd be great

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 please correct me if I'm wrong!!

Dave Jr

So just to clarify one last thing;

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)

Dave Jr

By levels, does this relate to luminosity values found on the marmoset website? i.e. adjust the levels to accurately match up (or make similar of) the luminosity values given within the material swatches provided using my own texture

BigSwopa

Dave Jr wrote: »

So just to clarify one last thing;

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.