[Sidefx-houdini-list] OT: sRGB to linear question

Andy Walker Andy.Walker at framestore.com
Tue Jul 8 13:00:46 EDT 2008


There's a few simple problems with sRGB: 

- If you use an sRGB as a displacement map, unless your displacment shader accounts for the 2.2 in gamma, then a linear gradient will be displaced as a round gamma'd hill shape... 

- With values above 1, if you gamma them, they are going to be crazy (Photoshop spits out linear exrs, if you gamma them up to an sRGB pipeline your bright values are all being compressed down), so an sRGB HDR map soen't make much sense. 

- ermmm... lunch time... 



----- Original Message ----- 
From: "Sean Lewkiw" <Sean.Lewkiw at CIS-London.com> 
To: sidefx-houdini-list at sidefx.com 
Sent: Tuesday, 8 July, 2008 12:32:01 PM GMT -05:00 US/Canada Eastern 
Subject: Re: [Sidefx-houdini-list] OT: sRGB to linear question 

Sorry to hog the list, but I'm still struggling a bit.... 
> It seems obvious, but where it gets tricky is that when you render that sRGB 
> texture in mantra, what you're doing is rendering a texture map that has a 
> gamma burned into it(sRGB) that is different than what the renderer is 
> using(probably linear assuming you've changed nothing). 
I don't understand this. How is the texture that mantra is using to 
render different from the texture from the original (sRGB) texture? 
Isn't is the same, gamma-burnt-in image I've been happily viewing? That 
is, if I multiply Cf by my gamma encoded image's zero value, I get zero, 
and similarly again for values between zero and a bajillion? 

(I should mention that we have a mplay LUT that closely mimics the look 
of the Truelight film LUT which our compositors use, into which we 
render our images, and this is how we judge colour.) 

In a nutshell, my point is that when I think of what my shaders are 
doing mathematically to the texture map anyway, (power functions, 
clamps, remaps, etc), whether it's linear or sRGB seems to be the least 
of my worries! ;-) 

Is the thinking that the need for truly linear images as textures so 
that physically accurate materials and lights perform the way they 
should, (EX: HDR lighting)? 

As an aside, even one of the articles that Andy posted implies that 
"colour space of texture maps isn't that important": 

/"In Part I we looked at the (now trendy) notion that the pictures we 
work with are encoded with a gamma curve to compensate for how the 
monitor works. However 3D renderers and compositing software calculate 
things in linear space, or to put it simply they just do the math and 
produce exact results in the simplest and most obvious way. They do not 
try to correct for the technological problem of monitor construction. / 

/Some people will tell you should convert all of your images to linear 
before doing anything, and use a look up table to see the result. That 
statement should come with a big warning about Dealing With Absolutes 
(only the Sith do!) / 

/.... [edit]..... 
/ 

/In 3D rendering software, the various shaders are designed to make the 
result look good, not necessary mathematically correct. The whole 
solution was designed to give good-looking results in the environment 
that it was used." 
/ 

Sean 




> Now, you don't see 
> any problem because the monitor you're screening mplay on *is* sRGB(most 
> likely, unless you're using a calibration program). If you're sending that 
> image, like we frequently do here, to an inferno suite that's also working 
> with tiff plates that have sRGB burned into it, you can merrily carry on and 
> not worry about things. Because mantra is linear by default, it's 
> essentially passing things through it without changing anything. 
> 
> Strictly speaking, though, this is 'wrong'(and is where you get much finger 
> wagging and tsk-tsk'ing). You should be converting the tmap to linear, and 
> rendering it, then viewing it through a calibration program that expects the 
> incoming imagery to be linear, and will convert it to sRGB or whatever gamma 
> your display device is using(or you burn it back in for final should that be 
> the pipeline). Again, if you're all video all the time, you never do film, 
> you never get sources from cineon format, etc...then this all seems like a 
> lot of worry over nothing, and in fact it is, as long as your pipeline works 
> like that. It's more work to convert it, render it, comp it, then re-convert 
> it again. You can probably safely do without it(although some people will 
> still finger wag you regarding the colourspace you're compositing in). The 
> instant you add other variables to the pipeline, though, you need to be aware 
> of it. 
> 
> 
>> I'm not trying to be provocative, just trying to get an understanding of 
>> this whole thing. 
>> 
> 
> Believe me, I hear you. :) It's a complicated topic and non-obvious, with 
> lots of misinformation out there. 
> 
> Andy got to that link before me, it's very useful. Hopefully this post is 
> somewhat complentary as a 'why' explanation as opposed to 'how'. I found 
> the 'why's to be poorly explained much of the time, based on a film 
> assumption. 
> 
> Cheers, 
> 
> J.C. 
> 
> 

-- 
Sean Lewkiw 
-- 
CIS London 
130 Shaftesbury Avenue 
London W1D 5EU 
-- 
+44 (0) 207.031.1138 (P) (Direct) 
+44 (0) 207.031.1136 (F) 
+44 (0) 795.606.7245 (M) 
-- 
Composite Image Systems London Ltd 
Registered Office: Denham Media Park, North Orbital Road, Denham, Uxbridge, Middlesex UB9 5HQ 
Company Registration No. 5577229 England 


_______________________________________________ 
Sidefx-houdini-list mailing list 
Sidefx-houdini-list at sidefx.com 
https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list 



More information about the Sidefx-houdini-list mailing list