What is the best format to save render?

[anejo]

I've alway saved my still rendering as jpg's than moving them into PS for any post work that maybe needed. I've never really understood why i've only saved the render as jpg's, just thought it was the correct thing to do. Is there any advantage to saving the render in any other format(ie...PNG, EXR)?

[WAcky]

Take a look here:

http://www.cgarchitect.com/vb/597-easy-jpg-vs-tif-question.html

http://www.cgarchitect.com/vb/6449-differences-between-tga-jpg.html

Edited December 3, 2009 by WAcky

[Deetee]

the quality will be compressed if u save in jpeg which u won't want it to be that way.

[amer abidi]

*.tga; Always!

[STRAT]

your choice. best what suits your needs.

 

we generally save the majority of our work in JPG format.

[Crazy Homeless Guy]

I never render out to anything less than 16bit. You can save it as a jpeg when done, but if you save it as an 8bit file when moving between your rendering application, and Photoshop, then you are giving up an emense amount of color information that you will not be able to cover.

 

With 8 bit, you have a maximum of 16.8 million colors available.

With 16 bit, you have a maximum of 281 Trillion colors available.

 

This means that you can do quite a bit of color correction, and level adjustment and adjustments to an image without worrying about banding. After I finish with my Photoshopping, I save the file as an 8bit, often a jpeg.

 

Now, I typically use 16bit tiff out of old habits, but I decided to go ahead and compare a few different formats when saving from Max.

 

640x480 16bit tiff file size with alpha = 2,401k

640x480 16bit png file size with alpha = 791k

640x480 16bit exr file size with alpha = 230k

640x480 16bit tga file size with alpha = 830k

 

Amazingly if I saved to a 16bit EXR file, and it was only 230k. This is still slightly more than twice what it would be if I saved to a Jpeg file with as little compression as possible, which wound up being 108k for this image.

 

Another wierd thing about this, when the I opened the 16bit EXR in PS, the file read with 32 bit channels. I am not exactly sure what this means? ...can I still do full eposure adjustments, before converting to 16 bit for processing. If so, this is amazing at this file size.

 

So, ...here is a quick example of why you should go 16bit over 8. The image below is rendered out from 3dsMax. I saved it as both an 8bit, and a 16bit image.

 

 

I then looked at the levels for each image, and went ahead and clamped down on each side to take full advantage of the visible color space available. The resulting image looks like this.

 

 

Now, if you look at the 8bit vs 16bit histograms you can start to see the differences. The breaks in the 8bit histogram are empty gaps, where no color exists, and no color can be brought back. The 16bit histogram is still smooth. Because the file had 281 trillion colors to start, it was able to expand those while still keeping a much smoother histogram than what was possible with the 8bit.

 

 

The lack of color information can result in banding in the 8bit image. In real world use this is typically most noticeable in skies, and across surfaces with gradients that very a fair amount in color from one side to the other.

 

Anyway, I think I am going to try and work with 16bit EXR's over the next couple of weeks, rather than 16bit tiffs. Maybe they will work better, maybe not.

Edited December 3, 2009 by Crazy Homeless Guy

[Dave Buckley]

travis

 

i'm currently looking into incorparting .openexrs into my workflow after the release of the new connection extension.

 

however, i don't know what i'm doing just yet.

 

i can't seem to access all of these 'passes' (in p/s) that are apparently stored in the .exr for this 'streamlined' compositing workflow

 

let me know how you get on with it

[d_mccreadie]

I was alxo interested in EXR and found this informaton but haven't had the time to look into it properly hope it is of use to you http://www.jamesshaw.co.nz/blog/?p=155

[amer abidi]

Travis, are you sure 32bit TGAs are read in 8bit only on PS? Does the same apply with all Adobe software; specifically premiere?

 

First time i ever hear of this!

[Nic H]

tga is a 8 bit format.

[Stephen Thomas]

Travis, are you sure 32bit TGAs are read in 8bit only on PS? Does the same apply with all Adobe software; specifically premiere?

 

First time i ever hear of this!

32-bit targas are not 32-bits per channel like an exr, they are 8-bits per channel just like a jpeg. RGBA = 4 x 8 = 32, hope that clears it up. An exr is actually 128-bit if you look at it this way.

[natysoz]

im using TGA for 32/16 Bit

[Stephen Thomas]

im using TGA for 32/16 Bit

Yes, but as I already explained that is 32/16 bits per pixel, not bits per channel. Completely different things.

Edited December 3, 2009 by stef.thomas

[Crazy Homeless Guy]

travis

 

i'm currently looking into incorparting .openexrs into my workflow after the release of the new connection extension.

 

however, i don't know what i'm doing just yet.

 

i can't seem to access all of these 'passes' (in p/s) that are apparently stored in the .exr for this 'streamlined' compositing workflow

 

let me know how you get on with it

 

Ignore the extra passes and channels for now. You will need third party software to read them into PS anyway.

 

I used to render to EXR's almost exclusively, but became tired of the bloated file size. But, ....if I switch to half float 16 bit EXR, my file size for my test image goes from 2.8megs to 230k. If this type of reduction stays consistent across my files, then I am switching back to EXR.

 

Now, the potential problem with this solution is that EXR's are floating point, and can support colors way beyond 1 for white. Meaning, if I have white values of close to 30, and black values close to 0, then I may be stretching the 16bit color depth too much. I don't know if this is true, but as I think about this, it may be a potnetial problem.

 

But, I typically try to keep my files close to properly exposed, which should keep the brights and darks from being to far seperated. So, using a 16bit EXR should work fine for me, and the greatly reduced file size brings a smile to my face.

[Dave Buckley]

Ignore the extra passes and channels for now. You will need third party software to read them into PS anyway.

 

I used to render to EXR's almost exclusively, but became tired of the bloated file size. But, ....if I switch to half float 16 bit EXR, my file size for my test image goes from 2.8megs to 230k. If this type of reduction stays consistent across my files, then I am switching back to EXR.

 

. . . and the greatly reduced file size brings a smile to my face.

 

first part of the quote - are you talking about proexr?

 

second and third part of quote - isn't this due to the improved openexr workflow that had been improved for and incorporated into the connection extension?

[Crazy Homeless Guy]

Yes, ProEXR.

 

The test file I was using was saved out of Max2009, so no advanced EXR extension.

[Stephen Thomas]

Another wierd thing about this, when the I opened the 16bit EXR in PS, the file read with 32 bit channels. I am not exactly sure what this means? ...can I still do full eposure adjustments, before converting to 16 bit for processing. If so, this is amazing at this file size.

As far as I am aware the difference between full-float (32-bit) and half-float (16-bit) EXRs is in the precision rather than the values. In other words the intensity values are the same but the 32-bit file has more decimal places than the 16-bit one and therefore finer gradation between tonal values, similar to the difference between 8 and 16 bit files.

 

However the 16-bit EXR is probably more than sufficient for most uses and since you are more than likely going to be reducing the dynamic range rather than expanding it I can't imagine there being any issues with banding etc as you are working in 32-bit colour space and the software will just interpolate the values.

[Dave Buckley]

guys, can i just ask, where does this sort of knowledge come from

[Nic H]

staring at the the internet for along time plus going through a few years of making gradient skies that go all bandy

[Stephen Thomas]

An unhealthy fascination with how things work and why they sometimes don't

[Dave Buckley]

not trying to hijack the thread but i've just looked at my max output formats when saving a render

 

i've got 2 different entried for openexr as follows:

 

OpenEXR Image File (*.exr,*.fxr)

 

OpenEXR Image File (*.exr)

 

Any particular reason for this that you know of?? Any major differences i need to be aware of?

[erickdt]

I am currently rendering out 16bit TIF files which work great. The only problem is that when I'm using multiple passes they are saved as seperate images which need to be composited in Photoshop. This isn't a huge deal but I prefer to skip this step if it's possible. From what I gather ProEXR will do this. The issue is that, last time I checked, ProEXR did not work with CS4.

 

Is it still true that ProEXR does not work for Photoshop CS4?

 

E

[BrianKitts]

I am currently rendering out 16bit TIF files which work great. The only problem is that when I'm using multiple passes they are saved as seperate images which need to be composited in Photoshop. This isn't a huge deal but I prefer to skip this step if it's possible. From what I gather ProEXR will do this. The issue is that, last time I checked, ProEXR did not work with CS4.

 

Is it still true that ProEXR does not work for Photoshop CS4?

 

E

 

correct.

 

My current workflow with new images is to open them in CS3, run my action script that sets up all the render elements in the proper order and layer filtering, then save the image and then continue working from there on in CS4 so that I can use the 64bit photoshop.

[WAcky]

An unhealthy fascination with how things work and why they sometimes don't

 

That would be a good quote for a sig

[anejo]

I greatly appreciate everyone input on this topic, now i have some options to further look into.