Creative Communities of the World Forums

The peer to peer support community for media production professionals.

Forums Adobe After Effects 8 bit and 16 bit compositions..which to use?

  • 8 bit and 16 bit compositions..which to use?

  • Nathan Quattrini

    July 24, 2008 at 3:18 pm

    I am importing some clips from Premiere (Animation Codec MOV on Mac) and want to know if I should be setting the compositions to 8 bit or 16 bit. What’s the difference? And if I worked in 8 and need to switch to 16 for better quality, do I need to start over? I want the best quality to export back to Premiere when I’m done in AE

  • Chris Wright

    July 24, 2008 at 9:24 pm

    16 seems to take longer than 8 bit, so only use it if you have to, like color correction or many blending light layers.

  • Dennis Reibensteel

    October 27, 2011 at 9:53 am

    I know this is old, but FIY:

    I always work in 8-bit mode. Just if I want to see something in best quality I briefly switch to 16.
    I also do all my previews in 8-bit. Then in the end, the final export I render in 16-bit and full res.
    It helps to make preset render settings, like: “Half Res / 8bit” and “Full Res 16bit”.

  • rick nweg

    April 20, 2012 at 2:45 pm

    but if you render it in 16bit you also need a container and a codec that supports 16bit, don’t you? or can you render 16bit in eg h264-codec?

  • Chris Wright

    April 20, 2012 at 11:25 pm

    rendering in 16bpc means that the codec supports it anyway from the drop down box. All h.264 is 8bit. Working in a 16bpc or 32bpc gives the advantage of precision compositing even if you are simply going to an 8 bit video container, it will dither it out back to 8 bit again.

    Now, if you want 16 or 32, AE will ungrey trillions and float respectively. Cineons act as float, Tiff can be both, and other video codecs you have to buy. My own personal tests confirm that Tiff with LGW compression off gives both the smallest file size and zero errors for trillion/float plus it has built in color management and you can render off where you left.

  • Andrew Somers

    April 21, 2012 at 12:43 pm

    For the record, I do 99% of my work in 32 bit, linearized.

    The only time I use 8 bit is when I am trying to introduce 8 bit artifacts, like banding, on purpose.

    If you are doing any sort of image manipulation, such as levels, curves, etc etc, then you should at least be in 16 bit.

    If you are doing any compositing, then you should be doing that in 32 bit LINEAR space.

    AS FOR STARTING OVER:

    You can switch between 8 and 16 bit and not have to start over – HOWEVER, to switch between gamma encoded and LINEAR colorspace, you WILL need to start over. Linearized colorspace should never be used with 8 bit, and is best used with 32 bit float.

  • Andrew Somers

    April 21, 2012 at 3:29 pm

    Chris Wright Said:
    All h.264 is 8bit.

    For the record, H264 does support 10 bit (in fact, up to 14 bit with the High 444 profile), however, all the codecs supplied with After Effects for H264 and Mpeg4 only support 8 bit profiles.

    Chris Wright Said:
    Cineons act as float,

    Cineons do NOT act as float. Cin/DPX are 10 bit* – this is an integer format and IS NOT FLOAT. and each color channel has values from 0 to 1023. While AE reports this as “trillions” it is in fact only slightly more than one billion:

    10 bit RGB: 1,073,741,824

    Chris Wright Said:
    Tiff can be both, and other video codecs you have to buy.

    Tiff can be 8 bit or 16 bit integer, or 32 bit float. AE comes with a ton of codecs and you don’t have to buy them. There are even more codec varieties in the bundled Adobe Media Encoder (the preferred tool for creating H264 inside the Adobe line of products).

    EXR is a better choice than TIF, especially when working in 32 bit float linear space, as I will outline below:

    Chris Wright Said:
    My own personal tests confirm that Tiff with LGW compression off gives both the smallest file size and zero errors for trillion/float plus it has built in color management and you can render off where you left.

    EXR with lossless PIZ compression is superior in data efficiency to TIF with LGW compression and it’s not even close.

    Here are the same exact images rendered as 16 bit float EXR (PiZ compression), 16 bit integer TIF with LGW compression, and 32 bit float TIF with LGW compression:

    Even with LGW compression ON, the Tifs are eating up a huge amount of data space. This also greatly impacts bandwidth so that renders take substantially longer due to greater disk I/O times.

    EXR is normally a 16 bit floating point format (It can also do 32 bit float, but this is rarely used as it is really not needed in practice**). With EXR’s 16 bit float, there are 1024 levels PER STOP, and 30 stops of dynamic range (plus an additional 10 stops on the low end with reduced precision). See: https://www.openexr.com/about.html

    As such, EXR handles HDR imagery (16 bit TIF requires that you compress any such imagery into its integer format, and 32 bit TIF is a huge data hog, even with LGW compression).

    Also, EXR allows for embedded profiles, and is natively linear and thus integrated well into a linear colorspace workflow such as Nuke, or AE in 32 bit float linear.

    FOR THE RECORD:

    There are many Quicktime codecs that support 10 bit. Apple ProRes for instance supports 8 or 10 bit, and ProRes 4444 supports 12 bit. After Effects reports these as “trillions” of colors vs “millions” of colors. AE also calls 16 bit integer “trillions” and then 16 or 32 bit float just “float”.

    The maximum number of colors for an RGB image in various bit depths:

    6 bpc: 262,144 (many consumer grade LCD monitors are only 6 bpc).

    8 bpc: 16,777,216 — aka 16 million

    10 bpc: 1,073,741,824 — aka one billion

    12 bpc: 68,719,476,736 — aka 69 billion

    14 bpc: 4,398,046,511,104 — aka 4 Trillion

    15 bpc: 35,184,372,088,832 — aka 35 Trillion ***

    16 bpc integer: 281,474,976,710,656 — aka 281 Trillion ***

    16 bpc float (EXR): 328991029248000 within the nominal 30 stop range.

    32 bpc integer: This is 4 billion per channel (4,294,967,296)
    — This is 79,228,162,514,264,337,593,543,950,000 colors
    — More easily written 7.9^28 colors, aka 79 Octillion

    32 bpc float: 4,722,366,482,869,645,213,696 aka 4.7 sextillion – and this is only between the values of 0 and 1.0. To understand more about Single Precision float, see: https://en.wikipedia.org/wiki/Single_precision_floating-point_format

    Footnotes:

    *(note that DPX are 10 bit in AE, though the format does support higher bit depths in the official spec, those other bit depths are rarely used in practice).

    **(32 bit EXR has the advantage of eliminating any conversion errors from a native 32 bit float linear working space in AE or Nuke, but those errors are so small as to be insignificant). It should be noted that conversion from a 16 bit integer format to a 16 bit half precision float format will result in some rounding errors, but it should be noted that the general industry trend to to work in a linear color space in floating point (32 bit float or 64 bit float) for all image manipulation and compositing.

    *** Note that Adobe products internally use 15 bit when you set them to 16 bit, for 32768 values per channel instead of 65536. This is due to legacy reasons, see: https://forums.adobe.com/message/3472269

  • Andrew Somers

    April 21, 2012 at 4:03 pm

    TYPO ABOVE, the line

    16 bpc float (EXR): 328991029248000 within the nominal 30 stop range.

    Has an extra 3 at the front, the number should read 28,991,029,248,000


    (Hey Creative Cow: your “30 minute rule” sucks. I was in the midsts of reformatting that paragraph, and your system locked me out just as I was correcting the mis-pasted number.)

  • Chris Wright

    April 21, 2012 at 11:34 pm

    notice how i said, zero errors. If you zoom in with EXR, even with a regular render, you lose bits even with its compression off. It’s not lossless. Sometimes red and green will ok but blue will lose a digit of precision with the color picker.

    as for 10 bit h.264, what’s the point? even blue-ray is only 8 bit, HDTV’s are 8 bit, and if you want to use 10 bit h.264, you’ve already lost quality anyway so why bother using it for archival or intermediate format when there’s better choices?

    and cineons encode in log which mean they hold overbright values.

  • Andrew Somers

    April 22, 2012 at 3:35 pm

    No Chris, once again you are incorrect.

    Chris Stated: “and cineons encode in log which mean they hold overbright values.”

    The “Cineon System” was abandoned in 1997. “Cineon” as a file format is not an “application” so it does not encode anything. It is only a data container. Today, people use the DPX format (derived from/replacing Cineon) so I’ll assume you actually mean DPX.

    Regardless, DPX is not necessarily LOG – it can hold image data with a video gamma curve as well.

    Log/Vid/Lin does not matter, DPX/Cin is only a data container. It is not going to be log unless you specify when creating the file.

    Regardless, holding overbrights or not does not make it “float”. DPX/Cin is an INTEGER format. And when it is holding so-called “LOG” data, it is actually a linear integer representation of film density. It just so happens that film density is “log”.

    The “amount” of overbright information that a “typical” Log DPX file will contain is far less than a float format such as EXR. And in a Log DPX/Cin, as the image gets “brighter” the precision becomes less and less.

    Chris Stated: “as for 10 bit h.264, what’s the point? even blue-ray is only 8 bit, HDTV’s are 8 bit, and if you want to use 10 bit h.264, you’ve already lost quality anyway so why bother using it for archival or intermediate format when there’s better choices?”

    Not sure where you are getting your information.

    FIrst, it’s written “Blu-Ray”. Second, while it may only support 8 bit at present, the industry is moving toward “Deep Color” displays and players, and support for the wider gamut xvYCC colorspace. It is only a matter of time before 10 bit xvYCC (or indeed 12 bit DCI/P3) makes its way to a consumer distribution path.

    HDMI and many HDTVs support 10/12 bit depths. My HDTV supports 10 and 12 bit, aka “Deep Color” support.

    HDMI supports “Deep Color” since version 1.3 (10/12/16 bit support)

    “Deep Color” HDTV Monitors support 10 bit (Deep Color monitors must accept 10 and 12 bit, and can optionally accept 16 bit per color channel).

    Theatrical digital projection follows the DCI standard and is a 12 bit format in the P3 colorspace..

    So to answer your question “What’s the point”? Blu-Ray and Broadcast is not the only distribution medium – online distribution is certainly not limited to 8 bit, and higher bit depth distribution means are already in use and will undoubtedly continue.

    And I don’t think anyone in this thread is suggesting H264 as an intermediate medium.

    Chris Stated: “notice how i said, zero errors. If you zoom in with EXR, even with a regular render, you lose bits even with its compression off. It’s not lossless. Sometimes red and green will ok but blue will lose a digit of precision with the color picker.”

    You are confusing “lossy compression” with “conversion/precision/transform errors” – they are two separate things entirely.

    With lossless compression, no data is lost – that is, the data after decompression is identical to that before compression. With lossy compression, the data after decompression is different than before compression. For image data, this is typically done in such a way as to minimize perceptual artifacts.

    Conversion errors are an all together different issue. You can have conversion errors for any number of reasons. Most image transforms will result in some form of conversion error – spatial transforms, colrospace transforms, transforming the gamma curve, and (relevant to the present discussion) transforming between different data types and encoding schemes, i.e. INTEGER vs FLOAT.

    After Effects has three working bit depths: 8 bit INTEGER, 16 bit INTEGER and 32 bit FLOATING POINT.

    AE also can use any number of color spaces and any number of associated gamma curves for a working space.

    EXPORTING (i.e. rendering out) in a different bit depth/colorspace/gamma curve that what you are working in will frequently create an “error” as you are referring to it.

    If you are working in 16 bit integer sRGB, and you render out to a 16 bit integer format with sRGB at the same resolution with no lossy compression, then you should not have any transform errors.

    But if you are working in 32 bit float linear, and render out to a 16 bit integer format you are going to have some very significant errors.

    If you are in a 32 bit float linear working space, but go out to a 32 bit float TIF, you should not have any errors, but you will be eating up data space. If instead you go to a 16 bit float linear EXR with PiZ, you may have some VERY INSIGNIFICANT errors, but your data space/bandwidth will be reduced by 60% to 70%.

    For more on precision limitations of half float, see:

    https://en.wikipedia.org/wiki/Half-precision_floating-point_format

    16 bit float – aka half float – has 11 bits of precision between 0 and 1, but also extends far above one or overbright values, and the capability of handling HDR imagery.

    16 bit Integer has (in Adobe land) 15 bits of precision between the equivalent “0 and 1”, but nothing over “one”.

    With 16 bit float, you give up an insignificant amount of precision for a significantly extended dynamic range.

    As a side note, EXR 32 bit float with PiZ is functionally the same as 32 bit TIF float, but creates a slightly smaller file.

    RELATED article of interest:

    https://www.fxguide.com/featured/the-art-of-digital-color/

Viewing 1 - 10 of 12 posts

Log in to reply.

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy