Category Archives: Technology

Thinking about frame rates.

Once upon a time it was really simple. We made TV programmes and videos that would only ever be seen on TV screens. If you lived and worked in a PAL area you would produce programmes at 25fps. If you lived in an NTSC area, most likely 30fps. But today it’s not that simple. For a start the internet allows us to distribute our content globally, across borders. In addition PAL and NTSC only really apply to standard definition television as they are the way the SD signal is broadcast with a PAL frame being larger than an NTSC one and both use non-square pixels. With HD Pal and NTSC does not exist, both are 1280×720 or 1920×1080 and both use square pixels, the only difference between HD in a 50hz country and a 60hz country is the frame rate.

Today with HD we have many different frame rates to choose from. For film like motion we can use 23.98fps or 24fps. For fluid smooth motion we can use 50fps or 60fps. In between sits the familiar 25fps and 30fps (29.97fps) frame rates. Then there is also the option of using interlace or progressive scan. Which do you choose?

If you are producing a show for a broadcaster then normally the broadcaster will tell you which frame rate they need. But what about the rest of us?

There is no single “right” frame rate to use. A lot will depend on your particular application, but there are some things worth considering.

If you are producing content that will be viewed via the internet then you probably want to steer clear of interlace. Most modern TV’s and all computer monitors use progressive scan and the motion in interlaced content does not look good on progressive TVs and monitors. In addition most computer monitors run by default at 60hz. If you show content shot at 25fps or 50fps on a 60hz monitor it will stutter slightly as the computer repeats an uneven number of  frames to make 25fps fit into 60Hz. So you might want to think about shooting at 30fps or 60fps for smoother less stuttery motion.

24fps or 23.98fps will also stutter slightly on a 60hz computer screen, but the stutter is very even as 1 frame gets repeated in every 4 frames shown.  This is very similar to the “pull-up” that gets added to 24fps movies when shown on 30fps television, so it’s a kind of motion that many viewers are used to seeing anyway. Because it’s a regular stutter pattern it tends to be less noticeable in the irregular conversion from 25fps to 60hz. 25 just doesn’t fit into 60 in a nice even manner. Which brings me to another consideration – If you are looking for a one fits all standard then 24 or 23.98fps might be a wise choice. It works reasonably well via the internet on 60hz monitors. It can easily be converted to 30fps (29.97fps) using the pull-up for television and it’s not too difficult to convert to 25fps simply by speeding it up by 4% (many feature films are shown in 25fps countries simply by being sped up and a pitch shift added to the audio).

So, even if you live and work in a 25fps (Pal) area, depending on how your content will be distributed you might actually want to consider 24, 30 or 60fps for your productions. 25fps or 50fps looks great on a 50hz TV, but with the majority of non broadcast content being viewed on computers, laptops and tablets 24/30/60fps may be a better choice.

What about the “film look”? Well I think it’s obvious to say that 24p or 23.98p will be as close as you can get to the typical cadence and motion seen in most movies. But 25p also looks more or less the same. Even 30p has a hint of the judder that we see in a 24p movie, but 30p is a little smoother. 50p and 60p will give very smooth motion, so if you shoot sports or fast action and you want it to be smooth you may need to use 50/60p. But 50/60p files will be twice the size of 24/25 and 30p files in most cases, so then storage and streaming bandwidth have to be considered. It’s much easier to stream 24p than 60p.

For almost all of the things that I do I shoot at 23.98p, even though I live in a 50hz country. I find this gives me the best overall compatibility. It also means I have the smallest files sizes and the clips will normally stream pretty well. One day I will probably need to consider shooting everything at 60fps, but that seems to be some way off for now, HDR and higher resolutions seem to be what people want right now rather than higher frame rates.

Advertisements

What’s the difference between raw and S-Log ProRes – Re: FS5 raw output.

This is a question that comes up a lot.

Raw is the unprocessed (or minimally processed) data direct from the sensor. It is just the brightness value for each of the pixels, it is not a color image, but we know which color filter is above each pixel, so we are able to work out the color later. In the computer you take that raw data and convert it into a conventional color video signal defining the gamma curve and colorspace in the computer.  This gives you the freedom to choose the gamma and colorspace after the shoot and retains as much of the original sensor information as possible.Of course the captured dynamic and color range is determined by the capabilities of the sensor and we can’t magically get more than the sensor can “see”. The quality of the final image is also dependant on the quality of the debayer process in the computer, but as you have the raw data you can always go back and re-encode the footage with a better quality encoder at a later date. Raw can be compressed or uncompressed. Sony’s 12 bit FS-raw when recorded on an Odyssey or Atomos recorder is normally uncompressed so there are no additional artefacts from compression, but the files are large. The 16 bit raw from a Sony F5 or F55 when recorded on an R5 or R7 is made about 3x smaller through a proprietary algorithm.

ProRes is a conventional compressed color video format. So a ProRes file will already have a pre-determined gamma curve and color space, this is set in the camera through a picture profile, scene file or other similar settings at the time of shooting. The quality of the ProRes file is dependant on the quality of the encoder in the camera or recorder at the time of recording, so there is no way to go back and improve on this or change the gamma/colorspace later. In addition ProRes, like most commonly used codecs is a lossy compressed format, so some (minimal) picture information may be lost in the encoding process and artefacts (again minimal) are added to the image. These cannot easily be removed later, however they should not normally present any serious problems.

It’s important to understand that there are many different types of raw and many different types of ProRes and not all are equal. The FS-raw from the FS5/FS7 is 12 bit linear and 12 bit’s are not really enough for the best possible quality from a 14 stop camera (there are not enough code values so floating point math and/or data rounding has to take place and this effects the shadows and low key areas of the image). You really need 16 bit data for 14 stops of dynamic range with linear raw, so if you are really serious about raw you may want to consider a Sony F5 or F55. ProRes is a pretty decent codec, especially if you use ProResHQ and 10 bit log approaches the quality of 12 bit linear raw but without the huge file sizes.  Incidentally there is very little to be gained by going to ProRes 444 when recording the 12 bit raw from an FS5/FS7, you’ll just have bigger files and less record time.

Taking the 12 bit raw from an FS5 and converting it to ProRes in an external recorder has potential problems of it’s own. The quality of the final file will be dependant on the quality of the debayer and encoding process in the recorder, so there may be differences in the end result from different recorders. In addition you have to add a gamma curve at this point so you must be careful to choose the correct gamma curve to minimise concatenation where you add the imperfections of 12 bit linear to the imperfections of the 10 bit encoded file (S-Log2 appears to be the best fit to Sony’s 12 bit linear raw).

Despite the limitations of 12 bit linear, it is normally a noticeable improvement over the FS5’s 8 bit internal UHD recordings, but less of a step up from the 10 bit XAVC that an FS7 can record internally. What it won’t do is allow you to capture anything extra. It won’t improve the dynamic range, won’t give you more color and won’t enhance the low light performance (if anything there will be a slight increase in shadow noise and it may be slightly inferior in under exposed shots). You will have the same dynamic and color range, but recorded with more “bits” (code values to be precise). Linear raw excels at capturing highlight information and what you will find is that compared to log there will be more textures in highlights and brighter parts of your captured scenes. This will become more and more important as HDR screens are better able to show highlights correctly. Current standard dynamic range displays don’t show highlights well, so often the extra highlight data in raw is of little benefit over log. But that’s going to change in the next few years so linear recording with it’s extra highlight information will become more and more important.

Will a bigger recording Gamut give me more picture information?

The short answer is it all depends on the camera you are using. With the F55 or F65 then S-Log2/S-Gamut and S-Log3/S-Gamut3 will give you a larger range of colours in your final image than S-Log3/S-Gamut3.cine. But if you have a PMW-F5, PXW-FS7 or PXW-FS5 this is not going to be the case.

What is Gamut?

The word Gamut means the complete range or scale of something. So when we talk about Gamut in a video camera we are talking about dynamic range and color range (colorspace) taken together. Then within the Gamut we can break that down into the dynamic range or brightness range which is determined by the gamma curve and the color range which is determined by the colorspace.

Looking at the current Sony digital cinema cameras you have a choice of 3 different gamuts when the camera is in log mode plus a number of conventional gamuts you get when shooting rec-709, rec-2020 or any other combination of rec-709 color with cinegammas or hypergammas.

Log gamma and gamuts.

But it’s in the log mode where there is much confusion. When shooting with log with the current cameras you have 3 recommended combinations.

S-Gamut (S-Gamut colorspace + S-log2 gamma).

S-Gamut3 (S-Gamut3 colorspace + S-Log3 gamma).

S-Gamut3.cine (S-Gamut3.cine colorpace + S-Log3 gamma).

The S-log2 and S-log3 gamma curves both capture the same dynamic range – 14 stops, there is no difference in the dynamic range captured.

In terms of the range of colors that can be recorded S-Gamut and S-Gamut3 are the same size and the largest recording colorspaces the cameras have. S-Gamut3.cine is a smaller colourspace but still larger than P3 (digital cinema projection) or rec-709.

Gamuts-only Will a bigger recording Gamut give me more picture information?

But those were all designed for the F55 and F65 cameras that have extremely high quality (expensive) colour filters on their sensors. The reality is that the F5/FS7/FS5 sensor cannot see the full range of any of the S-Gamut colorspaces so in reality you gain very little by using the larger versions. Don’t expect to see a noticeably greater range of colours than any of the other colour modes if you have the F5/FS7/FS5. But all the LUT’s designed for these cameras are based on the S-Gamuts and if you want to mix an FS5 with an F55 in one production it helps to use the same settings so that grading will be easier. It is worth noting at this point that most natural colors do fall within Rec-709, so while it is always nicer to have a bigger color range it isn’t the end of the world for most of what we shoot.

S-Log3 is a great example of what it means to have a bigger recording range than the camera can “see”. S-log3 is based on the Cineon film transfer log gamma curve developed back in the late 1980’s. Cineon was carefully tailored to match film response and designed around 10 bit data (as that was state of the art back then). It allows for around 16 stops of dynamic range. Much later, Arri and many others then adapted Cineon for use in video cameras – The “C” in Arri’s LogC stands for Cineon.

When Sony started doing wide dynamic range cameras they developed their own log gammas starting with S-Log, then S-Log2. These curves are matched very precisely to the way a video sensor captures a scene rather than film. In addition they are matched to the sensors actual capture range, S-Log can record 13 stops as that’s what the sensors in the cameras with S-Log can see. Then S-Log2 is 14 stops as the second generation cameras can all see 14 stops. As a result of being purpose designed for a video sensor, when using S-Log2 you maximise the entire recording range because the sensor is matched to the log which is matched to the record range.

But, these curves drew much criticism from early adopters and colorists because they were very different from the Cineon curve and all the other log curves based on this old school film curve. Colorists didn’t like it because none of their old Cineon LUT’s would work as expected and it was “different”.

S-log-levels Will a bigger recording Gamut give me more picture information?
Chart showing S-Log2 and S-Log3 plotted against f-stops and code values. Note how little data there is for each of the darker stops, the best data is above middle grey. Note that current sensors only go to +6 stops over middle grey so S-Log2 and S-Log3 record to different peak levels.

In response to this Sony then developed S-Log3 and surprise, surprise – S-log3 is based on Cineon. So S-log3 is based on a 16 stop film transfer curve, but the current cameras can only see 14 stops. What this means is that the top 14% of the gamma curve is never used (that’s where stops 15 and 16 would reside) and as a result s-Log3 tops out at 92% and never gets to the 107% that S-Log2 can reach. If Sony were to release a 16 stop camera then S-Log3 could still be used and then it would reach 107%.

Coming back to colorspace. If you understand that the sensor in the F5/FS7/FS5 cannot see the full colour range that S-Gamut or S-Gamut3 are capable of recording then you will appreciate that like S-log3 (that is larger than the camera can see and therefore part empty) many of the possible code values available in S-Gamut are left empty. This is a waste of data. So from a colourspace point of view the best match when shooting log for these cameras is the slightly smaller colorspace S-Gamut3.cine. But S-Gamut3.cine is meant to be matched with S-Log3 which as we have seen wastes data anyway. If the camera is shooting using a 10 bit codec such as XAVC-I or XAVC-L in HD there are plenty of code values to play with, so a small loss of data has little impact on the final image. But if you are recording with only 8 bit data, for example XAVC-L in UHD then this does become much more of a problem and this is when you will find that S-Gamut with S-Log2 is going to give a better result as S-Log2 was designed for use with a video sensor from day 1 and it maximises the use of what little data you have.

Raw and the PXW-FS5

This isn’t a “how to” guide. There are many different recorders that can be used to record raw from the FS5 and each would need it’s own user guide. This is an overview of what raw is and how raw recording works to help those that are a bit confused, or not getting the best results.

First of all – you need to have the raw upgrade installed on the FS5 and it must be set to output raw. Then you need a suitable raw recorder. Just taking the regular SDI or HDMI output and recording it on an external recorder is not raw.

Raw is raw data direct from the cameras sensor with very little image processing. It isn’t even a color image, it won’t become color until some external processing, often called “De-Bayer” is done to convert the raw data to a color image.

For raw to work correctly the camera has to be set up just right. On the FS5 you should use Picture Profile 7. Don’t try and use any other profile, don’t try and shoot without a profile. You must use Picture Profile 7 at it’s factory default settings. In addition don’t add any gain or change the ISO from 3200. Even if the scene is a dark one, adding gain will not help and it may in fact degrade the recorded image.

White balance is set using the appropriate SGamut + color temperature preset chosen from within Picture Profile 7, there are only 3 to choose from for S-Gamut, but with a raw workflow you will normally fine tune the white balance in post. No other color matrix or white balance method should be used. Trying to white balance any other way may result in the sensor data being skewed or shifted in a way that makes it hard to deal with later on.

All of the above is done to get the best possible, full dynamic range data off the sensor and out of the camera.

If you are viewing the S-Log2 (ie don’t have viewfinder gamma assist enabled) then the exposure level that Sony recommend is to have a white card at 60%. So consider setting the zebras to 60%. Don’t worry that this may look a bit dark or appear to be a low level, but that’s the level you should start with… More about exposure later on.

This raw data is then passed down the SDI cable to the external recorder. The external recorder will then process it, turn it into a color signal (de-bayer) and add a gamma curve so that it can be viewed on the recorders screen. Exactly what it will look like on the monitor screen will depend on how the recorder is set up. IF the recorder is set to show S-Log2, then the recorders screen and the FS5’s LCD should look similar. However you might find that it looks very different to what you are seeing on the FS5’s LCD screen. This is not unexpected. If the recorder is setup to convert the raw to Rec-709 for display then the image on the recorder will be brighter and show more contrast, in fact it should look “normal”.

Under the surface however, the external raw recorder is going to be doing one of two things (normally at least). It’s either going to be recording the raw data coming from the camera as it is, in other words as raw. Or it will be converting the raw data to S-Log2 and recording it as a conventional ProRes or DNxHR video file. Either way when you bring this footage in to post production it will normally appear as a flat, low contrast S-Log2 image rather than a bright, contrasty rec-709 image. So understand that the footage will normally need to be graded or have some other changes made to it to look nice.

Recording the actual raw data will give you the best possible information that you can get from the FS5 to work with in post production. The downside is that the files will be huge and will take a fair amount of processing power to work with. Recording a ProRes or DNxHR video file with S-Log2 gamma is second best. You are throwing away a bit of image quality (going from 12 bit linear down to 10 bit log) but the files should still be far superior to the 8 bit UHD internal recordings or even an external recording done via the HDMI which is also limited to 8 bit in UHD.

Most raw recorders have the ability to add a LUT – Look Up Table – to the image viewed on the screen. The purpose of the LUT is to convert the S-Log2/raw to a conventional gamma such as Rec-709 so that the picture looks normal. If you are using a LUT then the normal way to do things is to view the normal looking picture on the recorders screen while the recorder continues to record S-Log2 or raw. This is useful as the image on the screen looks normal so it is easier to judge exposure. With a 709 LUT you would expose the picture so that the image on the recorders screen looks as bright as normal, skin tones would be the usual 70% (ish) and white would be 90%.

There is a further option and that is to “bake in the LUT”. This means that instead of just using the LUT to help with monitoring and exposure you actually record the image that you see on the recorders screen. This might be useful if you don’t have any time for grading, but… and it’s a big BUT…. you are now no longer recording S-log2 or raw. You will no longer have the post production grading flexibility that raw or S-Log2 provide and for me at least this really does defeat the whole point of recording raw.

Exposure: Raw will not help you in low light. Raw needs to be exposed brightly. If viewing S-Log2 then Sony’s recommendation is to have a white card or white piece of paper at 60%. I consider that to be the absolute minimum level you can get away with. The best results will normally be achieved if you can expose that white card or piece of paper at around 70% (when looking at an S-Log2 image). Skin tones would be around 55%. If you expose like this you may need to use a different LUT on the recorder to ensure the picture doesn’t look over exposed on the recorders monitor screen. Most of the recorders include LUT’s that have offsets for brighter exposures to allow for this. Then in post production you will also want a LUT with an exposure offset to apply to the S-Log2 recordings. You can use the search function (top right) to find my free LUT sets and download them.

SEE ALSO: https://www.sony.co.uk/pro/article/broadcast-products-FS5-raw-shooting-tips

 

Sony FDR-X3000 4K Action Cam – built in gimbal.

One of the cameras I used a lot in Norway is the new Sony FDR-X3000 action cam. What’s different about this POV camera is that the lens and sensor are actually mounted in an internal miniaturised gimbal. This really does work and helps stabilise the image.

There is also a tiny bluetooth monitor that you can wear on your wrist to view the pictures and control the camera. The image quality you get from these tiny cameras really is quite amazing. Take a look at the video to find out more and see some sample footage.

Not all raw is created equal. Log may be better

This keeps cropping up time and time again.

Unfortunately every now and again a new term or buzzword comes along that gets taken as a holy grail term. Two that come to mind right now are log and raw. Neither log, nor raw, are magic bullet solutions that guarantee the best performance. Used incorrectly or inappropriately both can result in inferior results. In addition there are many flavours of log and raw each with very different performance ranges.

A particular point in case is the 12 bit raw available from several of Sony’s mid range large sensor cameras, the FS700, FS7 and FS5.

Raw can be either log or linear. This particular flavour of raw is encoded using linear data.  If it is linear then each successively brighter stop of exposure should be recorded with twice as many code values or shades as the previous stop. This accurately replicates the change in the light in the scene you are shooting.  If you make the scene twice as bright, you need to record it with twice as much data. Every time you go up a stop in exposure you are doubling the light in the scene. 12 bit linear raw is actually very rare, especially from a camera with a high dynamic range. To my knowledge, Sony are the only company that offer 14 stops of dynamic range using 12 bit linear data.

There’s actually a very good reason for this: Strictly speaking, it’s impossible! Here’s why: For each stop we go up in exposure we need twice as many code values. With 12 bit data there are a maximum of 4096 code values, this is not enough to record 14 stops.

If stop 1 uses 1 code value, stop 2 will use 2, stop 3 will use 4, stop 4 will use 8 and so on.

STOP:  CODE VALUES:  TOTAL CODE VALUES REQUIRED.

+1          1                                   1
+2          2                                   3
+3          4                                   8
+4          8                                   16
+5          16                                32
+6          32                                64
+7          64                                128
+8          128                             256 Middle Grey
+9          256                             512
+10       512                             1,024
+11       1,024                          2,048
+12       2,048                         4,096
+13       4,096                         8,192
+14       8,192                         16,384

As you can see from the above if we only have 12 bit data and as a result 4096 code values to play with, we can only record an absolute maximum of 12 stops of dynamic range using linear data. To get even 12 stops we must record the first couple of stops with an extremely small amount of tonal information. This is why most 14 stop raw cameras use 16 bit data for linear or use log encoded raw data for 12 bit, where each stop above middle grey (around stop +8) is recorded with the same amount of data.

So how are Sony doing it on the FS5, FS7 etc? I suspect (I’m pretty damn certain in fact) that Sony use something called floating point math. In essence what they do is take the linear data coming off the sensor and round the values recorded to the nearest 4 or 8. So, stop +14 is now only recorded with 2,048 values, stop +13 with 512 values etc. This is fine for the brighter stops where there are hundreds or even thousands of values, it has no significant impact on the brighter parts of the final image. But in the darker parts of the image it does have an impact as for example stop +5 which starts off with 16 values ends up only being recorded with 4 values and each stop below this only has 1 or two discreet levels. This results in blocky and often noisy looking shadow areas – a common complaint with 12 bit linear raw. I don’t know for a fact that this is what they are doing. But if you look at what they need to do, the options available and you look at the end results for 12 bit raw, this certainly appears to be the case.

Meanwhile a camera like the FS7 which can record 10 bit log will retain the full data range in the shadows because if you use log encoding, the brighter stops are each recorded with the same amount of data. With S-Log2 and 10 bit XAVC-I the FS7 uses approx 650 code values to record the 6 brightest stops in it’s capture range reserving approx 250 code values for the 8 darkest stops. Compare this to the linear example above and in fact what you will see is that 10 bit S-Log2 has as much data as you would expect to find in a straight 16 bit linear recording below middle grey (S-Log 3 actually reserves slightly more data for the shadows). BUT that’s for 16 bit. Sony’s 12 bit raw is squeezing 14 stops into what should be an impossibly small number of code values, so in practice what I have found  is that 10 bit S-log has noticeably more data in the shadows than 12 bit raw.

In the highlights 12 bit linear raw will have more data than 10 bit S-log2 and S-Log3 and this is borne out in practice where a brightly exposed raw image will give amazing results with beautiful highlights and mid range. But if your 12 bit raw is dark or underexposed it is not going to perform as well as you might expect. For dark and low key scenes 10 bit S-Log is most likely going to give a noticeably better image. (Note: 8 bit S-log2/3 as you would have from an FS5 in UHD only has a quarter of the data that 10 bit has. The FS5 records the first 8 stops in  8 bit S-log 2 with approx 64 code values, S-Log3 is only marginally better at approx 80 code values. 12 bit linear outperforms 8 bit log across the entire range).

Sony’s F5 and F55 cameras record to the R5 and R7 recorders using 16 bit linear data. 16 bit data is enough for 14 stops. But I believe that Sony still use floating point math for 16 bit recording. This time instead of using the floating point math to make room for an otherwise impossible dynamic range they use it to take a little bit of data from the brightest stop to give extra code values in the shadows. When you have 16,384 code values to play with you can afford to do that. This then adds a lot of extra tonal values and shades to the shadows compared to 10 bit log and as a result 16 bit linear raw will outperform 10 bit log across the entire exposure range by a fairly large margin.

So there you have it.  I know it’s hugely confusing sometimes. Not all types of raw are created equal. It’s really important to understand this stuff if you’re buying a camera. Just because it has raw it doesn’t necessarily mean an automatic improvement in image quality in every shooting situation. Log can be just as good or possibly even better in some situations, raw better in others. There are reasons why cameras like the F5/R5 cost more than a FS5/Shogun/Odyssey.

What is XOCN? Why is it so good, why do we need it?

This time last year I was just starting to earn about a new codec from Sony called XOCN (eXtended Original Camera Negative). XOCN is currently only available with the Sony F5/F55 and the new AXS-R7 raw recorder. Sony’s original R5 raw recorder takes 16 bit sensor data and applies a very mild amount of compression before recording the sensor data as linear raw. I have never seen any compression artefacts when using the 16 bit linear raw and it really is an amazing format to work with. So much so that I will always use it whenever possible.

But now as well as 16 bit linear raw the R7 can record 16 bit linear XOCN. Now, I’ll be completely honest here, I’m really not sure what the difference is between raw and XOCN. As far as I can tell XOCN is very, very similar to raw but sufficiently different to raw to avoid infringing on patents held by other manufacturers for compressed raw. XOCN is more highly compressed than Sony’s raw, but in every test I’ve done I have found it hard to spot any compression problems or any significant difference between XOCN and the original 3:1 raw.

So, I hear you ask…. “If it’s really that good what don’t we just do away with XAVC and use XOCN?” Well that is a good question. It all depends on processing power. XAVC is a traditional codec so inside the codec is a normal video image, so the only thing a computer has to do to play it back is uncompress the codec. XOCN is a compressed wrapper that contains sensor data, in order to view the image the computer has to uncompress the data and then it has to construct the image from the data. So you need a really good graphics card in a decent computer to work with XOCN. But if you do have a decent edit or grading workstation you should find XOCN straight forward to work with, it doesn’t require specialist cards to accelerate the decoding as Red raw does.

The key benefit that XOCN brings over traditional video is that it is 16 bit. 10 bit video is pretty good. In a 10 bit video you have almost 1000 tonal values, not bad when you consider that we have been using 8 bit for decades with only 235 shades. But 16 bit brings the potential for a whopping great 65,535 shades. This starts to make a big difference when you are extensively manipulating the image in post production. Any of you that are in to photography will know that you can push and pull a 16 bit raw photograph far, far further than an 8 bit jpeg. 16 bit video is no different.

But what’s really amazing about XOCN is you get almost all the benefits of linear raw but in a file size smaller than the same resolution 10 bit ProResHQ. If you use XOCN-LT the files are roughly half the size of ProResHQ. This means your media lasts a sensible amount of time and backups, transfers and archiving are all much easier, much faster than with uncompressed raw. Sony’s 3:1 compressed raw from the R5 has always been pretty easy to deal with. XOCN is even easier. Using XOCN-LT you can squeeze well over 2 hours of 16bit 4K on to a 512GB AXS card! In fact the file sizes are only marginally larger than XAVC class 480.

xocn-data-rates-1024x276 What is XOCN? Why is it so good, why do we need it?

The reduction in data rates becomes really significant if you shoot at high frame rates. As 50p and 60p productions become more common XOCN allows production companies to shoot 60fps with the benefits of 16 bit data but with files sizes barely any bigger than 24fps ProResHQ. If you have a Sony PMW-F55 you can shoot at 120fps in 4K using XOCN and the files are twice as big as 24fps raw.

For further information on XOCN please take a look at this page from Sony, it’s very informative and has a very good example of why 16 bit data is important, especially if you are shooting for HDR.

https://pro.sony.com/bbsc/ssr/show-highend/resource.solutions.bbsccms-assets-show-highend-f55xocn.shtml

The great S-Log2 or S-Log3 debate.

I’ve written about this many times before, but still it comes up again and again. Which is better? Which should I use? I hear all kinds of crazy comments and a lot of incorrect information, so first of all lets dispel a few myths:

S-Log2 captures more dynamic range than S-Log3, it goes to a higher level on the waveform.

S-Log2 and S-Log3 both currently record exactly the same dynamic range as this is limited by the sensors that Sony are using. The S-log3 curve could be used in a future camera to capture up to 16 stops, but that camera does not exist at the time of writing. As the S-Log3 curve is designed to go beyond 14 stops, stop No. 14 is recorded at a lower level to allow space for up to 2 more stops.  S-Log2 is a 14 stop maximum curve, so the peak level is much higher. In Sonys current camera range the limit is 14 stops whether it’s S-Log2 or S-Log3. The chart that Sony provide showing both S-Log2 and S-Log3 is a little confusing as it shows the entire gamma curve rather than what the camera can actually “see”. In their current implementations both curves stop at +6 stops over middle grey, both capture the same dynamic range, there is no difference.

S-Log2 is brighter than S-Log3 so it must be capturing highlights better.

No, not really, see above. Playback and on screen brightness comes from the levels chosen to record something at and is dependant on the shape and range of the gamma curve. But the actual captured range is dependant on what the sensor can cope with. As we are not changing the sensor, the captured dynamic range, brightness range and shadow range does not change between S-Log2 and S-log3, both of which take the entire sensor range (they just store that same range using slightly different levels). After applying a LUT or other conversion to your normal viewing gamma both S-Log2 and S-log3 will have the same brightness, same highlight and same shadow range.

S-Log3 has noisy shadows.

No, not really. Shadows appear noisy with S-Log3 as the shadow part of the curve is stored using higher code values compared to S-Log2. So when you view S-Log3 uncorrected the shadows are raised and stretched on your conventional monitor and this gives the impression of a noisy picture. In reality once you restore the levels to normal there is no additional noise. See this article for a full explanation.

S-log-levels The great S-Log2 or S-Log3 debate.
Chart showing S-Log2 and S-Log3 plotted against f-stops and code values. Note how little data there is for each of the darker stops, the best data is above middle grey. Note that current sensors only go to +6 stops over middle grey so S-Log2 and S-Log record to different peak levels.

S-Log3 is newer than S-Log2 so it must be better.

Newer, perhaps not. Better, no not really. S-Log3 is based on the industry standard Cineon log gamma curve. This curve was developed in the late 1980’s to allow the digitising of film using 10 bit data. So S-Log3 matches a curve designed to work with negative film and is capable of storing more than the 14 stops that the current cameras sensors can see. In effect it is an old log gamma curve. As it is a curve designed for more than 14 stops, when used in a 14 stop camera some of the available recording data is empty and wasted.

S-Log2 was specifically designed by Sony to work with an electronic sensor with 14 stops of dynamic range and is optimised to match the performance characteristics of video sensors. By using a 14 stop curve with a 14 stop camera almost every bit of available data is utilised, there is no wastage.

BUT THERE ARE SOME OTHER FACTORS WE NEED TO CONSIDER.

S-Log2 and S-Gamut:

As well as the gamma curve we also have different Gamuts or color ranges. S-Log2 was originally designed for the F65 camera. The F65 sensor can capture a huge color range beyond the range that most conventional video sensors can see. So as well as S-Log2 Sony introduced S-Gamut which was matched to the very wide color range of the F65 sensor. S-Log2 is designed to be used with S-Gamut. But many of the cameras we use, like the FS7, F5, FS5 cannot see this color range (Sony’s F55 can). In addition this very large color range can be a little tricky to deal with in post production. Add to this the fact that S-Log2 is quite different to the quite common Cineon gamma curve and as a result behaves differently in post. The end result was that there were a number of complaints and comments that Sony’s S-log2 material was difficult to grade.

S-Log3 and S-Gamut3.

Because some people were struggling a bit with S-Gamut and S-Log2 in post production (Resolve and many of the other tools we have today were not as well developed 4 years ago), Sony introduced S-Gamut3 and S-log3 as well as a further Gamut called S–Gamut3.cine. S-Log3 was based on Cineon as that’s what people were familiar with. Arri’s Log-C is also based on Cineon as are many other log curves. This makes it a more “familiar” grading experience for many colorists. In addition Sony created a modified version of the super large S-Gamut to make it easier to grade.  S-Gamut3 is just as big as S-Gamut but some tweaks inside make it easier to grade (fewer color shifts). At the same time Sony realised that most users were producing content for TV, the web or digital cinema that had little use for the huge color range of S-Gamut/S-Gamut3.  So S-Gamut3.cine was developed as a smaller, more manageable version of S-Gamut3 and it incorporated a few tweaks to the color science to provide colors closer to those used by other manufacturers. S-Gamut3.cine is also a better match for cameras with sensors that cannot see the full S-Gamut range (like the FS5, FS7, F5, A7).

The end result is that in general most people prefer or find it easier to grade S-Log3/S-Gamut3.cine material than S-Log2/S-Gamut. Plus you can often use LUT’s designed for Log-C or Cineon with S-log3 material (this isn’t optimum, but it can work).

Gamuts-1024x632 The great S-Log2 or S-Log3 debate.
SGamuts Compared.

Getting the data from camera to post.

In terms of getting the data from your cameras sensor in to post production S-Log2 is the better choice. It is optimised for the way an electronic sensor works. S-log3 is essentially a curve designed for negative film applications, not video and no matter how you look at it, these are electronic video cameras. However if you are recording 10 bit or greater you have a lot of data whichever curve you use, so in practice it will be rare to see any difference in the final result.

So use the curve you find easiest to work with. It is true that S-Log 3 allocates a little more data to the shadows and less to the highlights than S-Log2, but don’t confuse data and code values with more range. S-Log3 has a few extra code values in it’s darkest stops, S-log2 has a few extra in the bright stops, but the dynamic range, highlight and shadow handling is governed by the sensor not the gamma curve. Overall S-Log3 has fewer code values than S-Log2, S-Log2  makes better use of the data available, but with 10 bit this really isn’t going to make a huge difference.

8 Bit Recording.

But if you are only recording with an 8 bit codec you are already at a disadvantage. When recording 8 bit you really need to maximise the way what little data you have is used. For that reason I will always recommend that S-Log2 is used when recording 8 bit on a camera like the FS5 in UHD or A7s or similar (FS5 is 10 bit in HD). By using S-Log2 you are using as many of the limited code values available as you can. This doesn’t mean you can’t use S-log3, it just wouldn’t be my choice.

The end result should be the same.

At the end of the day, if you were to use matching LUTs, S-log2 and S-log3 material should look more or less exactly the same after grading or application of the LUT, no matter what the scene you are shooting. If they do look significantly different then you are doing something wrong. So your choice of curve, other than for 8 bit recordings will most likely come down to ease of use rather than anything else.

If your camera doesn’t have LUT’s then S-Log2 can be easier to work with as it is more contrasty. This makes it a bit easier to focus and also makes it easier to gauge exposure. If your camera has LUT’s and you use them, then you may decide to use S-Log3 simply because you should find it a little easier to work with in post. Either way both curves capture the same range of picture information and both should give more or less the same end result.

There may be some very, very subtle differences due to the small differences in data distribution, but often these will be hard to really see in the final image.

Notes on Timecode and Timecode Sync for cinematographers.

This is part 1 of two articles. In this article I will look at what timecode is and some common causes of timecode drift problems. In part 2 I will look at the correct way to synchronise timecode across multiple devices.

This is a subject that keeps cropping up from time to time. A lot of us camera operators don’t always understand the intricacies of timecode. If you live in a PAL/50Hz area and shoot at 25fps all the time you will have few problems. But start shooting at 24fps, 23.98 fps or start trying to sync different cameras or audio recorders and it can all get very complicated and very confusing very quickly.

So I’ve written these notes to try to help you out.

WHAT IS TIMECODE?

The timecode we normally encounter in the film and video world is simply a way to give every frame that we record a unique ID number based on the total number of frames recorded or the time of day.  It is a counter that counts whole frames. It can only count whole frames, it cannot count fractions of frames, as a result the highest accuracy is 1 frame. The timecode is normally displayed as Hour:Minute:Second:Frame in the following format

HH:MM:SS:FF

RECORD RUN AND FREE RUN

The two most common types of timecode used are “Record Run” and “Free Run”. Record run, as the name suggests only runs or counts up when the camera is recording. It is a cumulative frame count, which counts the total number of frames recorded. So if the first clip you record starts with the time code clock at 00:00:00:00 and runs for 10 seconds and 5 frames then the TC at the end of the clip will be 00:00:10:05. The first frame of the next clip you record will continue the count so will be 00:00:10:06 and so on. When you are not recording the timecode stops counting and does not increase.

With “Free Run” the timecode clock in the camera is always counting according to the frame rate the camera is set to. It is common to set the free run clock so that it matches the time of the day. Once you set the time in the timecode clock and enable “Free Run” the clock will start counting up whether you are recording or not.

HERE COMES A REALLY IMPORTANT BIT!

In “Free Run” once you have set the timecode clock it will always count the number of frames recorded and in some cases this will actually cause the clock to drift away from the actual time of day.

SOME OF THE PROBLEMS.

An old problem is that in the USA and other NTSC areas the frame rate is a really odd frame rate, it’s 29.97fps (this came about to prevent problems with the color signal when color TV was introduced). Timecode can only count actual whole frames, so there is no way to account for the missing 0.03 frames in every second. As a result timecode running at 29.97fps runs slightly slower than a real time clock.

If the frame rate was actually 30fps in 1 hour there would be 108,000 frames. But at 29.97fps after one real time hour you will have only recorded  107,892 frames, the frame counter TC, won’t reach one hour for another 3.6 seconds.

DROP FRAME TIMECODE.

To eliminate this 3.6 seconds per hour (relative to real time) timecode discrepancy in footage filmed at 29.97fps a special type of time code was developed called “Drop Frame Timecode“. Drop Frame Timecode (DF) works by: every minute, except each tenth minute, two timecode numbers are dropped from the timecode count. So there are some missing numbers in the timecode count but after exactly 1 real time hour the time code value will increment by 1 hour. No frames themselves are dropped, only numbers in the frame count.

WHEN TO USE DROP FRAME (DF) OR NON DROP FRAME (NDF).

Drop Frame Timecode is only ever used for material shot at  29.97fps, which includes 59.94i. (We will often incorrectly refer to this as 60i or 30fps – virtually all 30fps video these days is actually 29.97fps). If you are using “Rec Run” timecode you will almost never need to use Drop Frame as generally you will not by syncing with anything else.

If you are using 29.97fps  “Free Run” you should use Drop Frame (DF) when you want your timecode to stay in sync with a real time clock. An example would be shooting a long event or over several days where you want the timecode clock to match the time on your watch or the watch of an assistant that might be logging what you are shooting.

If you use 29.97fps Non Drop Frame  (NDF) your cameras timecode will drift relative to the actual time of day by a minute and a half each day. If you are timecode syncing multiple cameras or devices it is vital that they are all using the same type of timecode, mixing DF and NDF will cause all kinds of problems.

It’s worth noting that many lower cost portable audio recorders that record a “timecode” don’t actually record true timecode. Instead they record a timestamp based on a real time clock. So if you record on the portable recorder for lets say 2 hours and then try to sync the 1 hour point (01:00:00:00 Clock Time) with a camera recording 29.97fps NDF timecode using the 1 hour timecode number (01:00:00:00 NDF Timecode) they will be out of sync by 3.6 seconds. So this would be a situation where it would be preferable to use DF timecode in the camera as the cameras timecode will match the real time clock of the external recorder.

WHAT ABOUT 23.98fps?

Now you are entering a whole world of timecode pain!!

23.98fps is a bit of a oddball standard that came about from fitting 24fps films into the NTSC 29.97fps frame rate. It doesn’t have anything to do with pull up, it’s just that as NTSC TV runs at 29.97fps rather than true 30fps movies are sped up by 0.1% to fit in 29.97fps.

Now 23.98fps exists as a standalone format. In theory there is still a requirement for Drop Frame timecode as you can’t have 0.02 frames in a timecode frame count, each frame must have a whole number. Then after a given number of frames you go to the next second in the count. With 23.98fps we count 24 whole frames and the increment the timecode count by one second, so once again there is a discrepancy between real time and the timecode count of 3.6 seconds per hour. The time on a camera running at 23.98fps will run fast compared to a real time clock.  Unlike 29.97fps there is no Drop Frame (DF) standard for 23.98, it’s always treated as a 24fps count (TC counts 24 frames, then adds 1 to the second count), this is because there  is no nice way to adjust the count and make it fit real time as there is with 29.97fps. No matter how you do the math or how many frames you drop there would always be a fraction of a frame left over.

So 23.98fps does not have a DF mode. This means that after 1 hour of real time the timecode count on a camera shooting at 23.98 fps will be 00:01:03:14. If you set the camera to “Free Run” the timecode will inevitably drift relative to real time, again over the course of a day the camera will be fast by almost one and a half minutes compared to a real time clock or any other device using either drop frame timecode, 24fps or 25fps.

So, as I said earlier 23.98fps timecode can be painful to deal with.

24fps timecode does not have this problem as there are exactly 24 frames in every second, so a video camera shooting at 24fps should not see any significant timecode drift or loss of timecode sync compared to a real time clock.

It’s worth considering here the problem of shooting sync sound (where sound is recorded externally on a remote sound recorder). If your sound recorder does not have 23.98fps timecode the timecode  will drift relative to a camera shooting at 23.98fps. If your sound recorder only has a real time timecode clock you might need to consider shooting at 24fps instead of 23.98fps to help keep the audio and picture time codes in sync. Many older audio recorders designed for use alongside film cameras can only do 24fps timecode.

In part 2 I will look at the correct way to synchronise timecode across multiple devices.

CLICK HERE FOR PART 2