Would one benefit from using a 16-bit shader over an 8-bit. Now that Photoshop CS has full 16-bit compatibility, I've been working a lot more in it with my textures. I realize the 16-bit is helping me in PS as far as editing and manipulating goes, but I was wondering how much it was affecting a flattened image being projected as a shader.

I've done a few tests and from my own subjective reasoning, I can find no difference visually between using an 8-bit and 16-bit shader (this is in tif format) unless i am zoomed in far enough to see pixel by pixel (and even at that point I can just tell that they are very slightly different). I also did some testing on tga formats as well (8 bit saved as 16, 24, and 32 bit ‘per pixel’ formats) and these were the results after being applied to a 4x3 grid in Houdini and rendered out at 1280x1024.
_______________________________________________
TGA - 8,8,8 2560x1920 uncompressed

16 bits per pixel - 9,601 KB - terrible banding issues.
24 bits per pixel - 14,401 KB - great image quality
32 bits per pixel - 19,201 KB - great image quality

TIF - 8,8,8 2560x1920 uncompressed

14,414 KB - great image quality

TIF - 16,16,16 2560x1920 uncompressed

28,814 KB - great image quality
_______________________________________________

From what I could see, there seemed to be no difference visually between the last 4 tests (tga 8-24 and 8-32 & tif 8 and tif 16). Now it came between two choices based on file size since they were all practically indistinguishable. Those were the 8-bit TGA saved as 24 bits per pixel and the 8 bit TIF. They were both almost exactly the same size and quality.


So back to my original question…Is it useful at all to use 16-bit shaders over 8-bit? If there are benefits, are they worth double the file size? And if not, do people prefer the TGA format over TIF or vice versa since they are outputting the same quality at the same file size? I was personally leaning towards TIF mainly for its ability to have EXIF info and RAW conversion metadata attached to it while TGA did not.

Any input would be great.

Thanks,
Dave Quirus

P.S. Since I'm on the subject, can Houdini output 16-bit images so I can use that in my compositor while making adjustments?

I would tend to think that the difference between the higher bit depths would come in at compositing time when you need to do lots of math operations with them?

You can output a Cf plane as a different format. In the Deep Raster page, choose Cf as the VEX Variable. Righ underneath Vector Type, there's a menu that lets you choose the format. When you save your image as a .pic it will still make the C plane as 8 bit but you'll also have a Cf plane that is a copy of the image with your desired format.

I would tend to think that the difference between the higher bit depths would come in at compositing time when you need to do lots of math operations with them?

that's what I would think as well..

thanks for that deep raster stuff. i also found that if you are rendering out as either TIFF or RLA, you have bit depth options in the standard page. right next to the file format there is a down arrow to get more options. haven't seen that before. RLA can do up to 16. TIFF can handle up to 32.

Just to clarify a couple of terms - you're not really talking about the bit depth of shaders, you're talking texture maps - shaders don't really have any inherent bit depth - you can determine the result at render time as Edward mentions. The difference is important because there are more ways to make a surface colour than using a tmap.

The whole issue of using higher than 8 bit depends on various needs. If you're outputting to TV(or for that matter, just to an 8 bit terminal), of course you won't see any difference of a straight render of a floating point image because your display device can't even go as high as the source. However, what it *does* give you is a greater dynamic range to use in your renders. For instance, if you use a floating point image as a reflection map(an hdr image, for example), you'll get some really sweet “hits” in your reflection. Render the same thing with an 8bit envmap and you'll get drowsy. Download some of those classic hdr images on the web and try them in a reflection - zing it up, then compare to a converted version over to 8 bit. You will be astounded and will never look back.

Also, if you're going to film, it's a much higher-response medium and you need the extra bit depth “room”. And yup - when compositing, it's good to have.

I'm not entirely clear on the tga vs tif results you've posted. Both tif and tga use non-lossy compression(unless you're using a module of one of those that I'm unfamiliar with). Both will look the same given the same parameters - they respect the image quality and only use algoritmic tricks to shrink the file size, as opposed to jpeg, which is lossy.

You can use either one - it's really more about your pipeline and what reads what. Recently I've started using tga more because it let's you look at a partial image while rendering and there's been increasing number of legal issues coming up with the compression patents in tif. Grrrr.

In the end, there's no inherent advantages between these outside of the params mentioned above…

Cheers,

J.C.

Thanks for all that info J.C.

Sorry about the bad description in my original post. I guess i just used the term shader as a more general wording (referring to both bitmaped textures and procedural) and assumed it would make sense after i started talking about resolutions and bit depths.

But you brought up some good points about the whole output display that i needed to take into account (it will be on a tv). I was just trying to figure out if i should use 16-bit textures and render out 16-bit image sequences if i plan on compositing in 16-bit (which i do so i can make better adjustments). The final output after comp will be in 8 bit since the output is tv. But I didn't know how i should approach the texturing and rendering part if i plan on comping in 16-bit.

As far as the tga and tif output goes, that was from photoshop. I was taking pictures of textures with a digital camera and capturing them in a raw format. Then brought them in to PS, tweaked, and saved as all the different options for tga and tiff. Why the one format of tga came out so bad, i don't know. And i was leaning towards tiff for metadata reasons (so i could keep information of my camera settings, dates, and times). But I wasn't aware of and upcoming legal issues. So I should keep that in mind.

Thanks for all that great info. I need to try out some of that HDR stuff. It sounds like so much fun.

Dave

theres a link (which i cant find doh) on SESI site that shows examples of textures using TIFF and RAT, the results suggest that converting textures to RAT gives a noticeable difference in quality… it looks like this was for an old version of houdini im not sure if this would still be the same…

something worth mentioning is that much of the difference may be invisible unless you are explicitly telling mantra to output 16-bit or floating-point images in the mantra command options. ( mantra -b 16 or -b float )

now mantra will render to a 16-bit or fp .pic file, .tiff file, .rat file or a fp buffer in mplay. try it and then really push around the contrast of the image and you should see a huge improvement, especially in soft grades of lighting or texture. IMHO, rendering to floating point still using 8-bit textures is far more bang-for-your-buck then trying to edit images in 16bit. of course, once photoshop and similar paint software allow fp color depth just as easily as 8bit then go right ahead, but right now photoshop doesn't allow much image manipulation in any other bit depth. the ideal situation image-quality-wise is to have fp textures with shaders rendering to fp output images.

take note too that once you set mantra to render to floating point images, you can turn off Dither, especially if you're going to be compositing and screwing with the images a lot. the dither can really damage image quality if you're going to film and are boosting the image on a film LUT. look at the difference with an image rendered 8-bit/dithered to floating-point/non-dithered at a gamma of 2.2

just some more babble for ya,
j.

thanks jason. all of that really helped a lot. i wasn't even aware of the bit depth mantra commands. a few questions if you don't mind…

1. If i use the -b (16) mantra command, do i still need to specify the bit depth in the image options next to the chosen format? And where/how can i turn off the dithering?

2. Can you explain the whole integer vs floating point and how it applies to the image quality/bit depths. I understand how bit depths work and how that relates to image quality and the amount of colors available to manipulate. But I don't completely get how FP relates to bit depth and image quality. The only past understanding i have of FP vs. integer is performance and speed related issues with processing. So i'm a little confused when you said that the ideal situation was to have fp textures rendered to fp output images. Didn't know how to apply that to my understanding of only bitdepths. Does FP refer to 32 bit only?

but right now photoshop doesn't allow much image manipulation in any other bit depth.

3. Since my understanding of the whole FP isn't very good, this question might be useless, but doesn't Photoshop 8 (CS) now have a lot more 16-bit support with layers and tools and such? Don't know if thats what you meant because, once again, im confused about the whole fp aspect.

Thanks guys, I really appreciate all the help…

Dave

Floating point is sort of what it sounds like: instead of integer values of 0-255 for each of RGB, it stores a float(which obviously can contain more variation of numbers than 0-255). There's actually some savings, programming-wise, to using FP as opposed to just zooming up the integer values you have to play with. The upshot is the same thing as the difference between 4 bit and 8 bit - more depth of colour, richer images. Houdini's RAT is a floating point format, and tif images can also be too.

Cheers,

J.C.

In my experience higher range images are particularly useful for displacements or height maps. I worked on a game where we had to create 64 square mile natural land scapes with patched together tiles of 20 foot x 20 foot poly grids. The grids were placed into a world as tiles (thousands upon thousands of them), and each point of each grid corresponded to a pixel in a gigantic height map. Obviously with 255 levels of an 8 bit image, it was impossible to generate landscapes with nice gradual elevation changes. Even if you decided 1 unit in RGB == 1 foot in world space you'd only get 255 feet of elevation. 16 bit images offer 64K plus levels, giving you a MUCH nicer displacement. We could have 1 unit in RGB == 1 inch in world space, and have thousands of feet of elevation change throghout the world with nice precise transitions and gradations. Not just useful for landscapes though. If you're going a creature like a crocodile or something that has radical changes in it's skin and you want to be able to get the camera in close, higher range images may be handy for displacements.

ahh ok.. that makes sense now for the floating point images. is there a limit with floating point then? Obviously, there are with bit depths.. but with fp, couldn't a channel value be be 6.1 or 6.15 or 6.153 etc etc and get more infinitely detailed?

and great info michaelC. very handy stuff to know.

thanks you guys.

Well, not really. Floating point numbers also have a size and often come in two different precisions: single-precision (32-bits), or double-precision (64-bits). In laymen terms, double-precision will give you more significant digits than single-precision.

A good write up on the topic with all the gory details can be found here:
http://docs.sun.com/source/806-3568/ncg_goldberg.html [docs.sun.com]

cool.. thanks edward..

For me, 16bit integer files means extended range in to the blacks and whites, way beyond the 0 and 1 (0 and 255) limits associated with 8 bit images.

One example really hit home with me when dealing with 16 bit and cineon images was a cineon (12bit log) image of a very bright 200 watt light bulb. When the image was converted to an 8 bit file with the appropriate white and black points, the light bulb was white 255 for almost the entire bulb.

Now viewing the image as a 16 bit linear image (converted from 12 bit cineon), then adjusted the black point to, say 0.8 and the white point to 3 or higher, you could read the writing on the light bulb! Not only that, but the bulb had a nice gradient in the whites from the edges toward the centre. You could even see the filament glowing inside the glass. The values for the whites were way above 1 and would get clipped normally, either by converting to 8 bits or viewing a 16 bit image on your monitor as monitors can't see the extended range. By the way, anyone see the flat panel display at Siggraph last yera, the one with the LED's to boost the colors for display of values way above 1? Awesome. Still didn't do the same for the blacks though… How can an LED suck light or how matte can you make the screen and still see through it to the image?

This is why HDR images are amazing as John C. said. It is the extended info in the blacks and whites that add the magic, not the color information between 0 and 1 (although mach banding is eliminated by moving to 16 bits). That is why in your test, looking at average colors won't show much difference, even if rendered at 16 bits. Just more precision. Now with HDR images, by the time the color is reflected in your object in the cg scene, the intensity of the color is diminished based on the surface color and a host of other factors (lights, shader treatments, etc.). This means that the writing on a light bulb using an HDR projected environment image may or may not show up in your final 8bit image. If you rendered to 16 bit with extended whites, then you should be able to see the writing on the lightbulb by adjusting the white and black points up in mplay. Same goes for the blacks.

Mplay is capable of viewing images with different black and white points. Check it out. It is the only way to deal with extended color information.

Another thing to explore, as an exercise, is to do everything in 8 bits and render layers at varying white points and put the color emphasis where it belongs. Let me explain. Let's say you have a cg lightbulb object in your scene that has a very bright surface color, say a value of 3 with a texture map multiplied in with text on it and you point the camera right at it and render. You get a real white lightbulb and no text visible. But now in the mantra output driver's Specific folder, you adjust the white point up in value, then render, you should start to see the writing on the lightbulb. You can also render out the darker parts of your scene, say shadows and pick up more details by shifting the white point down then rendering these elements to composite in later with more control.

Now when it comes time to composit the various bits of your scene in 8-bit, you can use the brightness and contrast values to adjust things out the way you want, all in 8-bit.

It may be worth the effort to to do your work in 8bit playing these games, but then again, hard drives are very cheap these days.