PDA

View Full Version : 8 bit, 16 bit - LW to film



stefanj
03-18-2009, 03:16 AM
We are currently producing a short film using a combination of PhotoShop, After Effects, and LightWave. Since we are doing this in HD resolution, and eventually blowing this up to a 35mm print, we've tried to figure out a 16 bit pr. channel pipeline to try to get the most out of gradients and color variation in the images before going analogue. But I'm missing a couple of pieces of the puzzle. First off, I'm not sure how you conveniantly save out 16bpc images from LW. I thought we had covered our bases with rendering out frames using the TIFF 32 format, but it turns out that was just 8+8+8+8 (=32). The HDR-format would give us 128 bit images (32 bpc), but that's more than we need, and also introduces gamma issues we'd rather not have to deal with. I guess Deluxe RLA does 16 bit, but that's not compatible with PhotoShop CS4.

Our last project was done in an 8 bit pipeline, and that looked fine. I guess 16 bit will look better, although it most likely will not look twice as good. But I'm wondering how to effectively save out from LW, edit them in PhotoShop, and do 16 bit editing in Final Cut. Thoughts?

-StefanJ

flakester
03-18-2009, 03:48 AM
We find that the 64bit SGI format from LW gives us exactly what we need.
You may need to find a different version of the import plugin for PS (unless they've updated the native one in the CS4 evolution) to handle it correctly; though strangely, we find the After Effects absolutely loves them. We would recommend rendering out from LW with an unpremultiplied alpha if you plan on doing any comping.

They can take up a lot of room, especially at HD res, but when it comes to working with those in a high bit-depth comp, you'll get those lovely filmic burn-throughs and the like.

They also RAR extremely well. :thumbsup:

Hope that helps.

--
flakester.

::edit:: Just remembered that unpremultiplied images and PhotoShop do not play that nicely together...

biliousfrog
03-18-2009, 04:00 AM
You might be a little confused by how 16/32bit images can help and what they actually are.

Personally, I export everything to OpenEXR whch is a 32bit format. You can also export to 'half' EXR (16bit) but there's no real benefit. The gamma issues that you mention are probably down to the increased dynamic range, something which is easily adjusted with the exposure control in either Photoshop or After Effects.

The main advantage of increased channel information is that 'hotspots' remain 'hot' allowing for realistic depth of field, motion blur etc. It isn't a question of quality although effects applied to 32bit images will look far better than those applied to 8bit images...it's all down to how you use the images.

As an example, if you have a rocket with the exhaust jet coloured red and the luminosity at 300%, both the 8bit and 32bit images will show the colour as white. If you add a blur to them in post the 8bit image will remain white whilst the 32bit image will remain white near the centre but change to red as it gets further away...because it knows that the colour is red but the increased exposure information is making it look white. You could also take the exposure down so that you can see the red colour but with the 8bit image you'd just make everything darker.

If nothing else, 32bit images allow for increased flexibility during colour correction because you have more information than is being displayed. You can increase/decrease exposure and contrast without degrading the image quality and losing detail, something which isn't possible with 8bit.

Sensei
03-18-2009, 04:14 AM
8 bit, 16 bit - LW to film

If quality is concern go for any file format using 32 bit floats like OpenEXR. After rendering and saving in such format you can always make 8 bit (32 bit RGBA) from it, but reverse, no. LightWave and other 3rd party renderers work in 32 bit float/64 bit double precision internally anyway.

stefanj
03-18-2009, 04:31 AM
flakester: I ran a little test using the 64 bit .RGB files, but there are two drawbacks; PS CS4 does not natively handle them, and Final Cut Pro apparently does not support more than 10 bit images (and effects processing is limited to 8 bit). In that respect, Adobe Premiere CS4, with support for both 10 bit and 16 bit images seems to be the better choice right now.

biliousfrog: Ok, so what you're saying is that higher bit depth is usually just necessary if you're planning to do some heavy post work on the images. In this project, we render out 3d backgrounds from LW, and animate over that in After Effects. I was under the impression that a 16 bit pipeline would give us twise the color details (in theory) over our usual 8 bit pipeline, something that would be a plus if this is printed to 35mm in the end, most noticable in areas of subtle color change, like in gradients. Is this not correct?

-StefanJ

Sensei
03-18-2009, 04:58 AM
No. 16 bit integer pixel has 256 times higher quality than 8 bit integer, not twice..

Floats 16/32/64 are completely different story..

stefanj
03-18-2009, 05:12 AM
Sensei: You're right, off course. Question remains, though. Is it worth it for us, doing this 3d/cartoonish film in 16 bpc int? It would involve re-rendering a lot of backgrounds, so I guess I'm asking if it seems sensible to spend time upping it from 8 to 16. When you compare these things in PhotoShop, you get the sense that 16 bit is better, but it's not day and night. So if you have some experience with this, particularily when going to 35mm print/HD/BluRay, please chime in.

Netvudu
03-18-2009, 05:36 AM
I canīt speak inteligently about an animated film, but our pipeline for a live action feature film is whatīs suggested above.
We render to OpenEXR and then export DPX from Fusion. (the lab asks us for DPX files when going to 35 mm print). Obviously DPX will end up as 10 bits, so thereīs some clamping of info there, but I think thatīs better than coming from 8 bits per channel.

Mike_RB
03-18-2009, 06:57 AM
agreed.

We render everything from beauty passes to depth to mattes as openEXR. It's the only real format. Crush it to 8btis in post if you need to.

stefanj
03-18-2009, 07:35 AM
Mike_RB: What's the difference between those four EXR alternatives in LW? And how is it more real than e.g. SGI32 .RGB format? Keep in mind we are not going to need the images to contain any meta data, depth info, or what have you. Only 16-bit color. So my only concern is pipeline compatibility.

Lightwolf
03-18-2009, 07:49 AM
Mike_RB: What's the difference between those four EXR alternatives in LW? And how is it more real than e.g. SGI32 .RGB format? Keep in mind we are not going to need the images to contain any meta data, depth info, or what have you. Only 16-bit color. So my only concern is pipeline compatibility.
They're basically the same.
HALF uses 16 bit floating point data, FP 32bit floating point.
Then there's the RGB and the RGBA option (the only difference being the
inclusion of an alpha channel).
The main difference is that SGI32 uses 8bits per channel, for a total of 32bits (RGBA).
You probably mean SGI48 or 64bit (which is 16bits per channel, either RGB or RGBA).
The SGI format saves integer values only, giving you 65536 values per component (as opposed to 256 when using 8bits per channel). Still, the value is clipped at 100% white, nothing beyond that is saved. If highlights are clipped then they're gone for good.

This is where the float (FP/Half) formats come in, they're HDR and allow you to bring back values higher than 100% in post (if your compositing app has a float pipeline).

One more thing: Gamma issues with EXR only arise in apps that by default apply some gamma to them, such as AE or PS. You can just apply an inverse gamma ( 1 / gamma_value) to get it back as saved... or apply an inverse gamma prior to exporting in LW.
EXR, by definition, stores linear data only.

Having said that, in 99% of all cases float 16-bit (Half) OpenEXR images are plenty for all cases (and also preserves 10bit DPX perfectly). The only exception would be depth channels which I'd save as 32-bit float.

Cheers,
Mike

The Dommo
03-18-2009, 09:57 AM
To top up what Flakester said, our usual minimum file for final output for comping is 16bpc 64bit SGI files. Photoshop doesn't open them natively though sometimes they include the File I/O plugin on the Photoshop discs. Have a look, otherwise we can email you a free file. Other apps like AFX do open SGI files.

SGI files can be big as they are uncompressed. I have found that HDR and EXR images take about the same file size or less than SGIs, but with 32bpc colour.

This is awesome amount of data, and AFX is a bit slow to work with it, but it gives you loads more space to colour correct, crunch and grade.

The EXR gamma issues is because the light data is stored Linearly. You need to convert it, which in After Effects is easy. Simply apply the 'Exposure' filter to the clip (or an adjustment layer) and set the gamma to 0.454545 and you will have the equivalent of what you see directly from LW renders on screen. then you can start your tweaking and crunching etc, but with 32bpc.

We are moving to 32bpc as more standard, though if not necessary we still use 16bpc SGI files which are much faster to work with and still have very smooth gradients.

Hope this helps.

stefanj
03-18-2009, 10:21 AM
Thanks for all the comments! I feel much wiser now. Now all that could go wrong is if the 35mm printer guy say: "It's cool that you got such color range in your images, but our printer only handles animated gifs so please do crush your images before sending the sequence..."

Lightwolf: Yes, I meant SGI 64-bit! Thanks.

Good afternoon, lords and ladies.

-StefanJ

The Dommo
03-18-2009, 10:25 AM
awwwww bless, he called me "lady".. !

Lightwolf
03-18-2009, 10:46 AM
awwwww bless, he called me "lady".. !
Are you sure he meant you? ;) :p

Cheers,
Mike

The Dommo
03-18-2009, 04:03 PM
hey LightWolf - I have to say I've been looking at your exrTrader with dreamy eyes. If we get a half decent project in needing 32bpc we'll probably get a couple of copies. If memory serves it's not too expensive, right? :)

Lightwolf
03-18-2009, 04:06 PM
If memory serves it's not too expensive, right? :)
It was never meant to be expensive, and we think 39€ per copy is fair.

Cheers,
Mike

biliousfrog
03-19-2009, 03:04 AM
I'm still a little confused about what makes exrTrader so great...how does it differ to rendering out image buffers from the included 'buffer export' image filter for example?...and what benefits are there to having a layered exr file rather than seperate passes?

I don't doubt that it is great but I've looked at it several times and thought, 'apart from the layered files, I can do that already'

Lightwolf
03-19-2009, 04:41 AM
I don't doubt that it is great but I've looked at it several times and thought, 'apart from the layered files, I can do that already'
Pretty much, yes. Except that it's a lot more convenient in exrTrader.
You can apply simple image processing easily, preview the buffers in VIPER plus you have complete control over the resulting OpenEXR image.

Basically, the main differences are:
More control over the resulting exr image Convenience ;) (plenty of it)


Cheers,
Mike

Netvudu
03-19-2009, 07:36 AM
what pisses me off is the only reason Mikeīs exrtrader is so dang amazing is that LW lacks of this functionality, which NT should have added the moment they started supporting OpenEXR.

Donīt want to ruin your business Mike, but you did write it for a reason, right? ;)

Lightwolf
03-19-2009, 07:42 AM
Donīt want to ruin your business Mike, but you did write it for a reason, right? ;)
Yup. And I kept delaying it because I was actually expecting NT to include openEXR support in LW 8.0 as was announced back then.
Having said that, what is now exrTrader started out as a quick test plugin to get the hang of OpenEXR... and just evolved from there (and is still evolving).

On the other hand, we've always kept the basic image i/o free (you only license the buffer export) because at the time it was released NT didn't include exr support at all, and the only third party plugin was Win32 only. We at least wanted to make basic exr support available for free for everybody.

Cheers,
Mike

Netvudu
03-19-2009, 07:59 AM
I donīt think anybody around will ever put in doubt your business politics or ethics which are as good as it gets, IMHO.

Not only your prices are more than fair, but the tools work great and youīve made an insane amount of plugin ports to Mac and stuff for the community.


what I meant is...will you marry me? :p (youīre a girl, right? Women are called "Mike" around here :D)

Lightwolf
03-19-2009, 08:18 AM
what I meant is...will you marry me? :p
:tsktsk: You'd get into massive troubles with the management (and key generator) here at db&w :D

Cheers,
Mike

The Dommo
03-19-2009, 10:05 AM
lol :D