[Sidefx-houdini-list] Linear Workflow

John Coldrick jc at axyzfx.com
Thu Aug 26 11:16:48 EDT 2010


On Thursday 26 August 2010 08:27:06 am François Duchesneau wrote:
> This subject confuses me.
> 
> I thought Houdini already worked in linear space?

	It does, inasmuch as it doesn't assume anything other than linear.  It won't 
*add* to any existing LUT/sRGB issues, unless you ask it to.

> 
> I thought Photoshop only generated sRGB texture so we have to apply a
> lut (or a gamma correction to approximate it) when we read those
> textures in our shaders?

	Well, you should, assuming you want to work in linear.  When you look at your 
PS image on your computer, it looks "right", that's precisely what Microsoft 
invented sRGB for, so that would happen. Pop it over to mplay, by 
default(gamma 1), it looks the same.  Thing is, that's incorrect, it's not 
linear.  It *should* look "dark" at gamma 1 in order to be linear.  The 
confusion comes about because you're looking at the image through the filter 
of a monitor that isn't linear, you want to pull that out of the pipeline.  If 
you set mplay gamma to 2.2, that's a decent approximation of what a linear 
image looks like, and by default your PS export will look washed out.  You 
want to convert it to linear first(as Gene correctly points out, running it 
through Nuke and using a Colourspace node to do it is more accurate than 
simply inverse 2.2, but it's close).

> 
> When I read a Houdini image in Nuke. I set the read to linear and my
> viewer color space to "none" and my image is exactly how I see it in
> Mantra. Nuke works in linear so the gamma correction should be at the
> end of it?

	To clarify, Nuke makes assumptions about the colourspace of your image based 
purely on the file format(this can be tweaked in prefs).  By default, a tiff 
image is assumed to be sRGB and an exr is linear.  If you rendered a constant 
shader of that tiff image in mantra and rendered out an exr, then read both in 
Nuke, they will look different(assuming default prefs).  You should be looking 
at *everything* in houdini with gamma 2.2, the viewport, mplay, IPR(which you 
can do now in H11!).  You convert your incoming sRGB images to linear first, 
they will look correct in all those contexts.

	The above example, you want your Nuke viewer(as a rule, mind you) to be sRGB, 
not none, because just like with mplay set to 2.2 gamma, you want to strip out 
all srGB references, then at the tail end you pop your 2.2 gamma or similar 
LUT in there have it look 'correct'.

	All of this assumes you want to be working linear, of course.  There's lots 
of people out there that never do film that live in an sRGB world and they can 
happily go about working as if sRGB is an invisible filter laid over top of 
every last thing they're working on, since in the end it gets displays on an 
sRGB buffer(or close).  The one downside I would point out, though, is that 
light behaviour with PBR won't be the same, really I would argue this is a 
good reason to consider linear workflow even outside of film.

> 
> Why do we have to set the gamma correction to "Gamma 2.2" to match XSI
> linear space????

	If you're referring to the setting in the ROP that Mario suggested, all that 
does is pour more sampling into the dark areas, it doesn't change colourspace 
per se.  It's a handy trick especially if your final product ends up on TV.  I 
suspect even in film it's handy for certain shots.

	Nuke's assumption about colourspace based on format drove me mad when I first 
encountered it.  Now the Foundry has added the ability to tweak those 
assumptions and I understand the pipeline, it's actually rather handy for 
detecting things you're missed.  I went through plenty of hair pulling on this 
topic, believe me.  I understand your pain.  ;)

	Cheers,

	J.C.

---
John Coldrick
416-504-0425
jc at axyzfx.com
-----------------------------------------------------------------------
Life does not cease to be funny when people die any more than it ceases
to be serious when people laugh.
  - George Bernard Shaw




More information about the Sidefx-houdini-list mailing list