Texture Information lost in Linear Workflow

[Dennis]

Hi,

I've got a problem concerning my linear workflow. Up to now I never really had a problem with applying a gamma of 0.4545 to my textures and saving them as png before using them in my renders. But now I have a texture thats supposed to be very dark and when I apply my gamma correction all channels go to 0 0 0 in the whole texture. Do I have to save my textures in a linear format to solve this or is there any other workaround, because I don't have that much disk space available?

Greetings,

Dennis

[Mario Marengo]

But now I have a texture thats supposed to be very dark and when I apply my gamma correction all channels go to 0 0 0 in the whole texture.

Sounds like your problem has more to do with bit depth than with whether the color space is linear.

If your image is 8-bit .png (or, god forbid, an indexed palette) and it is very dark to begin with, then it's not surprising that it may end up with zero values after a 1/2.2 gamma correction.

Try converting it to 32-bit float or half-float with the Convert COP, then do the gamma correction.

[Dennis]

Thanks Mario,

that's also what I thought and meant by linear format. So is my only choice saving it out as a floating point image?

Btw: Is it possible to do the conversion to float and the gamma correction inside of my shader so i can save on disk space? Or is this bad practice?

[SpencerL]

Thanks Mario,

that's also what I thought and meant by linear format. So is my only choice saving it out as a floating point image?

Btw: Is it possible to do the conversion to float and the gamma correction inside of my shader so i can save on disk space? Or is this bad practice?

you can do your gamma correction in your shader using a Power VOP, but as far as your bit depth is concerned, that is strictly a render setting as its how much information is stored in the rendered image. The higher your bit depth, the bigger your file size.

Edited May 26, 2009 by SpencerL

[Mario Marengo]

Btw: Is it possible to do the conversion to float and the gamma correction inside of my shader so i can save on disk space? Or is this bad practice?

Absolutely. Gamma is just a power function, and the image values are converted to floating point for shading -- that is, 8-bit images will have had their pixel values mapped from [0,255] to [0,1] before they arrive at the shader. These values are not, however, made automagically continuous for you; they will retain any intensity stepping present in the original image (just remapped to a nominal [0,1] range).

In any case, the shader can apply the inverse-display gamma (1/2.2) by raising each texture value to an exponent of 2.2 -- just make sure the input values are not outside [0,1] else you might inadvertently generate inf's or nan's.

Here's a vex snippet which applies a gamma correction to the values of a texture map:

surface testGamma (
	  string   map   = "default.rat";
	  float	gamma = 0.454545;
   )
{
   if(map!="") {
	  // Get RGB texture value (add params to taste)
	  Cf = texture(map,s,t);
	  // Apply gamma correction -- if you know the map is
	  // 8-bit, then you don't have to worry about Cf having
	  // values outside [0,1], else the following expression would
	  // have to be slightly more complicated.
	  if(gamma!=0) Cf = pow(Cf,1.0/gamma);
   }
}

[Dennis]

Good to know

That will save me a lot of time.

While we're at it, maybe you can answer another question concerning linear workflow.

I have Houdini configured to render with a quantization of 32bit and have therefore set MPlay to display my rendering with a gamma of 2.2. But I have the feeling, that my lighting behaves strangely. When I add a light to my scene with an intensity of 5 for example (this would be my sunlight) and then add another fill light it seems too bright. I just set it to 0.05 and it still brightens the image considerably. I know, that the gamma correction lifts my midtones up to be much brighter, but that seems to be a little too much. Is this the correct behaviour?

Edited May 26, 2009 by Dennis

[Mario Marengo]

But I have the feeling, that my lighting behaves strangely. When I add a light to my scene with an intensity of 5 for example (this would be my sunlight) and then add another fill light it seems too bright. I just set it to 0.05 and it still brightens the image considerably. I know, that the gamma correction lifts my midtones up to be much brighter, but that seems to be a little too much. Is this the correct behaviour?

Can't say I've come across a "bug" in this regard... maybe you're just not used to working this way yet. It's not just the midtones but (and to a much larger degree) the "blacks" that get most affected by gamma. Notice that an intensity of 0.05 will be perceived as having a value of 0.256226 when displayed at a gamma of 2.2 (and 0.2 is significant, as you say, but not "wrong").

If you haven't already, I recommend having a read through this paper by Larry Gritz on the subject. He does a good job of making the whole thing very accessible I think.

[Dennis]

That was actually a really interesting and educating read. I think you're right, I just have to get used to the linear workflow thing.

Thanks.

[edward]

Here's a vex snippet which applies a gamma correction to the values of a texture map:

If the user supplies a .rat file to testGamma () that is in non-linear space, then isn't that wrong already? Doesn't the Larry Gritz link you posted above says to stick with linear texture files and never mipmap non-linear textures?

I can't find the link anymore, but I once read this article by someone at PDI discussing gamma correction and their image pipeline. I think this was in the day where disk space mattered and they were storing all their images as 8-bit on disk. But since 8-bits per component wasn't enough precision in linear space, they would store them as 8-bit non-linear instead. Then all their image processing tools would read the non-linear 8-bit images, convert to linear floating point, process, and then outputting back to disk as 8-bit non-linear. I thought it was kinda interesting at the time. However, these days, I really don't see any reason for not using 16-bit floating point linear textures for everything.

PS. I think Photoshop always saves out 16-bit floating point .tiff's as linear. It also always assumes that a 16-bit floating point .tiff is in linear. I found this out when someone complained that their rendered out 16-bit floating point .tiffs looked brighter in Photoshop than in mplay (with gamma value of 1 .

[Dennis]

Am I right, when I assume, that a 16bit float can hold the same dynamic range as a 32bit except for a coarser "stepping" (I hope this is comprehensible, I don't know the exact terms in english). Or do I compromise on the dynamic range when saving to a 16bit float image?

Which image formats do you prefer for your files? For textures I assume it is RAT, but what do you use for your rendered images? EXR or PIC?

I already saw the benefits of using RAT for my textures, but I don't like, that I'm not able to save them out directly from Photoshop, or is there any other image editing/compositing program that can handle RAT files natively or via plugin that I can paint textures with?

[Mario Marengo]

If the user supplies a .rat file to testGamma () that is in non-linear space, then isn't that wrong already? Doesn't the Larry Gritz link you posted above says to stick with linear texture files and never mipmap non-linear textures?

Yes. Errors would be introduced when filtering the different levels of the mipmap pyramid, and the whole thing further compromised when the renderer interpolates between mipmap levels during lookup. So yes, it's best to create RAT files from pre-linearized images, instead of trying to linearize mipmaps (like .rat files) during shading, since these problems would have been "burnt into the image" and by then it would be too late to correct them.

However.... for Dennis' specific case of an 8-bit PNG image, I thought it would be perfectly safe to do the linearization in the shader, since it's not a mipmap. BUT! as soon as I read your post I remembered that now Mantra auto-mipmaps non-rat images at run time. So you'll get hit by this problem even when *not* using rat images.

So Dennis... forget the shader-side linearization. Do it instead as a prepass on your source images. And you might as well save them as 16-bit float RATs or EXRs; that way you can go back and forth without loosing information, and you can get rid of the originals to save disk space if you need to.

I can't find the link anymore, but I once read this article by someone at PDI discussing gamma correction and their image pipeline. I think this was in the day where disk space mattered and they were storing all their images as 8-bit on disk. But since 8-bits per component wasn't enough precision in linear space, they would store them as 8-bit non-linear instead. Then all their image processing tools would read the non-linear 8-bit images, convert to linear floating point, process, and then outputting back to disk as 8-bit non-linear. I thought it was kinda interesting at the time. However, these days, I really don't see any reason for not using 16-bit floating point linear textures for everything.

Agreed. 16-bit float should be plenty good enough for just about any application -- unless the dynamic range is in the millions, I suppose, but I haven't come across a need for those yet

PS. I think Photoshop always saves out 16-bit floating point .tiff's as linear. It also always assumes that a 16-bit floating point .tiff is in linear. I found this out when someone complained that their rendered out 16-bit floating point .tiffs looked brighter in Photoshop than in mplay (with gamma value of 1 .

All kinds of gottcha's out there, yup. We went through a nasty "WTF!?!" moment a while back regarding quicktime movies and how some apps/platforms decide to be "smart" for you and screw with the color space behind your back... and not give you a way to tell it not to do so. Good times.

Thanks for pointing out the mipmap issue, Edward.

Cheers!

[Mario Marengo]

Am I right, when I assume, that a 16bit float can hold the same dynamic range as a 32bit except for a coarser "stepping" (I hope this is comprehensible, I don't know the exact terms in english). Or do I compromise on the dynamic range when saving to a 16bit float image?

There's no "coarser stepping" with 16bit float images -- they're like 32bit floating point images, except their dynamic range is not as big (but big enough for any VFX application that I've come across, with room to spare, so I think you're safe). The EXR format also supports 32bit float images so you can go either way (so do RATs). The advantage with 16bit float images is that they are much smaller than 32bit floats and still retain a large dynamic range -- bigger than anything the non floating point formats can achieve. (also, 16bit float is now being supported by graphic cards at the hardware level).

Which image formats do you prefer for your files? For textures I assume it is RAT, but what do you use for your rendered images? EXR or PIC?

I already saw the benefits of using RAT for my textures, but I don't like, that I'm not able to save them out directly from Photoshop, or is there any other image editing/compositing program that can handle RAT files natively or via plugin that I can paint textures with?

I would suggest using 16bit float EXRs if possible (does Photoshop support EXRs?). Saves on space and gives you a large dynamic range -- that's the whole idea behind the format. RATs are a proprietary format, I believe, so I don't think it would be supported by Photoshop or any other paint program (it *is* supported in COPs and throughout the Houdini tools though). Then, if you want to save space by not creating duplicate RATs to use for textures, Mantra will build a mipmapped version of your EXRs at runtime so they can still be filtered correctly during shading.... this comes at a cost though: 1) The runtime delay of creating these mipmaps, obviously, and 2) I believe Mantra has to load the entire image into RAM in these cases, because, unlike RATs, they are not tiled.

HTH.

[Dennis]

That's a lot of great information you're giving me here. Thanks Mario and edward.

I will go for the following workflow:

1. paint or edit 8bit textures in Photoshop

2. bring them into COPs to do final color corrections and linearization

3. save them out as 16bit float RAT for rendering

4. render my images to 16bit float EXR

5. do tonemapping and color correction in comp

Does that sound like a good workflow or is there anything I can improve?

I would suggest using 16bit float EXRs if possible (does Photoshop support EXRs?).

Yes it does. And fortunately with 16bit float you can use most of the editing features, which isn't possible with 32bit float (at least in CS3, which I have).

Edited May 27, 2009 by Dennis

[Mario Marengo]

I will go for the following workflow:

1. paint or edit 8bit textures in Photoshop

2. bring them into COPs to do final color corrections and linearization

3. save them out as 16bit float RAT for rendering

4. render my images to 16bit float EXR

5. do tonemapping and color correction in comp

Sounds good.

Just be aware of any potential linearization that Photoshop may be adding on its own, as per Edward's post. I find a lot of Mac/Quicktime/Adobe apps tend to be really bad when it comes to just leaving your pixels alone.

[Dennis]

Sounds good.

Just be aware of any potential linearization that Photoshop may be adding on its own, as per Edward's post. I find a lot of Mac/Quicktime/Adobe apps tend to be really bad when it comes to just leaving your pixels alone.

Yes, that's true. Do you have a recommendation which apps to use instead? Do you use Gimp or something else? Which codecs or formats can you recommend for video encoding, because Quicktime and H.264 always mess up my Gamma.

I've also noticed a possible bug when using IPR in Houdini 10. When I use something else than 32bit float and try to do any gamma correction in the IPR window my image turns completely black. In MPlay everything works fine though. Has anybody had the same experience. I'm on a Mac, maybe it's only a bug on that OS.

Edited May 27, 2009 by Dennis

[edward]

I don't see a problem with just doing your textures in Photoshop as 16-bit floating point. Then when you save it out as 16-bit floating point .tiff's, they will already be linear. So in theory, once you save out the 16-bit floating point .tiff from Photoshop, you should be able to convert it into .rat right away.

PS. This assuming you have Photoshop properly calibrated.

[DaJuice]

I've also noticed a possible bug when using IPR in Houdini 10. When I use something else than 32bit float and try to do any gamma correction in the IPR window my image turns completely black. In MPlay everything works fine though. Has anybody had the same experience. I'm on a Mac, maybe it's only a bug on that OS.

Bring up the display options for the IPR window (d), and try either of these two video card options: Use Fragment Shaders or Display All Images at 8bit Pixel Depth.

[Dennis]

Hey DaJuice, thanks for the tip. I never looked into the video card options. "Use Hardware accelerated LUT" did the trick. Thank you.

[Jason]

Hey DaJuice, thanks for the tip. I never looked into the video card options. "Use Hardware accelerated LUT" did the trick. Thank you.

Otherwise known as the "Ok, I give up; YOU try to deal with these damned graphics card drivers!" option.