Andrew Somers
Forum Replies Created
-
He’s not the only one that’s pleased 🙂
OpenGL as it has been was not useful, and did not play well at all with linear colorspace workflows.
YAY it’s gone. !
-
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/
-
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 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 Octillion32 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
-
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.
-
Both the D4 and D800 have both a mic and headphone jack. Both also have uncompressed HDMI out.
The D7000 takes excellent video, and has a mic jack, but does not have a headphone jack.
-
Chris said: “Your numbers are off, 104.2708333 is wrong, should be 104.2709376, so is 50050.0, should be 50050.05005005006. When you’re talking about 2+ hour movies, a single frame can be off.”
No, my numbers are CORRECT. Your numbers are off because you are ROUNDING.
In relation to pulldown, the true ratio is 1001/1000. This results in periodic decimals (infinitely repeating) for many of the conversion numbers.
For instance, the commonly used 23.976 is actually rounded from the periodic repeating decimal 23.976023976023976023976…
In practical reality, some software applications round off at three or four decimal places, though this is incorrect and will result in drift. Some will report the rounded number to the user, but will internally use the correct number at least out the the limits of double precision variables.
There are 172800 frames in a two hour movie – rounding at 4 decimal places will produce a drift of more than one frame over that period.
NOTE: 0.1% is only correct when pulling UP. When pulling DOWN, it is actually 0.0999000999000999000….% To understand this math, consider that if you take a value of 100 and increase it to 150, you have increased it by 50%. If you then take 150 and reduce it back to 100, you have now decreased it by 33.33333 % (this is a common concept for investors, that a 33% loss requires a 50% gain just to break even).
The “true rate” of 23.976 is
23.9760239760239760239760239760239760… (infinitely repeating)
When calculated on a calculator with 25 digits precision, the rate change from 25 to 23.976023976… is:
To keep a two hour film in sync within a frame, you need a minimum of 8 digits of precision (that is, 6 digits after the decimal point or 23.976023)
-
I’ve used AE to covert feature films shot at 25 fps to 24 with no problems.
History: back in the days before inexpensive 24P cameras, independent filmmakers would shoot in PAL DV, and then convert that 25 to 24 fps, and this would result in a *very* film-like look. In fact, the very first version of “Magic Bullet” was targeted at this specific task.
The principal issue is that there is a 4% speed change in the footage. This 4% is a common issue in the interchange of media from NTSC and PAL markets. In general, the preferred conversion method from NTSC to PAL or vice versa uses 24 FPS as the intermediate stage. In NTSC to PAL, fields are dropped to bring the interlaced 29.97 footage down to 23.976i. Then this would be sped up 4.1% to 25 fps. PAL to NTSC used the reverse of this path.
In the case of music content, it might become necessary to use a pitch shifter (such as Lexicon PrimeTime) to adjust the pitch due to the 4% change.
Your case:
So, it appears what you have 25 fps HD footage? The conversion is simple: In Aftereffects you can:
1) Bring in the footage and interpret it as 23.976 (or 24.00 depending on your delivery requirement). However, in this method you will need to convert the sound in a separate application, such as ProTools (this is preferable to After Effects, as ProTools has substantially better algorythyms for sample rate conversion).
1b) In this method, bring the sound into ProTools and sample rate convert it. If your sound is at 48K at 25 fps and you are going to 24 fps, then interpret the sound as 46080 Hz, and convert to 48000. If you are going to 23.976, then interpret the sound as 46033.966034 Hz. See the attached PDF document for more conversion numbers.
OR
2) Or, bring the footage in via AE, interpret it at its present rate of 25, and then use time remapping to convert it to 24 or 23.976.Andy’s List of Pulldown Numbers
-
When shooting, make sure that you have sharpening turned OFF, and I suggest using sRGB for the color space in the camera. sRGB shares the same primaries as Rec709, and is a smaller gamut than AdobeRGB. WHen you are shooting into a compressed and low bit depth format, such as the 8 bit video in the 5D, you want to use the smaller colorspace.
While I’m guessing (if you could upload a segment of the camera original, I could look), try adjusting the SHRINK setting under screen matte.
-
A) In theory when you are correctly white balanced, a green element that is sufficiently narrow should (in theory) occupy the green channel with little cross talk in the red and blue.
B) When you are working in AE in LINEAR color space, then a stop is just like in the real work – one half or double – i.e. 0.5 is one stop less than 1.0, and 0.25 is one stop less than 0.5, or two stops less than 1.0.
C) As for AT METER, when measuring REFLECTANCE using a SPOT METER on the surface, “at meter” implies that you are setting exposure for that value. If we are saying that you are setting exposure using the reflectance of an 18% card (putting that card in “Zone 5”, then your green screen can be as much as two stops darker than *that* level.
Of course, there are issues relating to the angle of reflectance, etc etc et that I am not going go into deeply here (for instance, in reality the meter inside dSLRs is calibrated to be “at meter” based on a 12% card, and this is a subject I am not going to get into at the moment, but here are two links with opposing viewpoints on the subject:
https://www.bythom.com/graycards.htm
https://dpanswers.com/content/tech_kfactor.php
But in terms of YOUR situation: If using a spot meter on an 18% grey card at your SUBJECT’s location you get a specific reading, and then point that spot meter at the green screen at roughly the same angle, the green screen should be NO BRIGHTER than the grey card, and can in fact be as much as 2 stops darker than the grey card. I normally aim for 1 stop darker than the grey card.
This assumes that you are shooting your subject “at meter” that is, at the settings as indicated by a light meter.
As the brightness of the green screen increases past “meter”, you will get into a region where it becomes clipped and/or washed out – washed out means that you are adding red and blue to the image which is exactly what you DON’T want.
