|
|
16/32bit images Just wondering what the potential pitfalls of using 16/32bit images instead of 8bit. I've hit a situation where 8bit just isn't cutting it, so it's time to find out i guess. One thing I've noticed is that with 32bit, if I use a shaded image patch it outputs a very low-res result (like 32x32 pixels, but the image is actually 256x256). 16bit seems to work ok, and I think 16bit is enough. Are there likely to be more catches like this along the way? And how about hardware support for 16/32bit images - will it work with anything ps2.0 capable? |
Intel chipsets explode when you try to make them do anything other than 8bpp. 16bpp is fairly well-supported all around from what I've seen, but 32bpp not so much (it's a shame though, since HDR with 32bpp can look So Good)
There will be a performance penalty for using larger values, and you'll use more vram for intermediate results.
16bit is enough, and there's not a chance in hell what I'm working on will work on intel chips (I'm using plenty of vertex shaders, a lot of CI filters, and I'm seriously considering raytracing everything in pixel shaders :)
Quick screenshot of the type of thing I've been up to lately as encouragement - that landscape is a kineme ridge texture with your distortion texture =)
Weird note: On Snow Leopard, GMA950s support 16 Bit (like ATI), and the textures actually have higher dynamic range. Selecting 32 bit causes it to fall back to 8bit (not 16).
I wonder how other cards hand this in 10.6... (I'm assuming X3100 does the same thing, but ATI and NV chips might have changed -- the "16 only works on ATI" bit of wisdom no longer holds, it seems...).
If 16 bit works on nvidia now, this is a HUGE bonus for me. I absolutely need high range for my recent work, but I'm also seriously vram limited. Can anyone test it?
HDR_nVidia Test - external link.
32bit doesn't work for me, and I'm on ATI. I suspect it's a problem with the source image or something? I get an image for 8/16 bit, but a grey rectangle for 32.
Here's a modified version that works on ATI and doesn't use any images. If it works, you should see a white circle for 8 bit (all colour definition lost! I had to decrease the colour accuracy by 10x to show anything at all..) 16 bit should show a circular gradient, but using very few colours (so you see circles of different shades of grey). 32 bit should appear smooth.
That's an interesting compare & contrast both in itself and with standard HDR [8,16 & 32 bit]. I do get the predicted result, & also obtain no 32 bit HDR via .psd.
FYI, actually 16 and 8 bit work for me & 32 bit doesn't and I'm on an nVidia 9400 iMac.
:-)
Argh, so it's still not fixed! ;(
I do the comparison like this because it makes what's happening really clear. If anything doesn't work, you get a missing image, if anything drops back to 16/8bit you know about it because the shading changes. With a standard image, you just can't tell at all if it drops back.
Odd that 32bit .psd doesn't work. Give it a go with this 32bit tiff, see what happens: http://www.interealtime.com/32bit.tif
As you no doubt expected, the 32 bit TIFF retained its colour values, whereas the 32 bit HDR .psd does not retain its appropriate colour values in QC, as the HDR .psd 8 & 16 bit manage to do .
I didn't know would happen actually, but it's good that it works. That means that 32bit psd support is broken, but at least QC is handling 32bit image loading ok.
32bit images are still extremely rare though - I made that one myself to test support in a bunch of apps. Almost nothing would load it outside of apps using the OSX frameworks (quicktime, preview, etc). All the apps I wanted to use it with (that would really benefit from 32bit!) failed to load anything higher than 16 bit.