Category Archives: Workflow

Atomos release new Neon range of HDR monitors with Dolby Vision.

This is BIG. Atomos have just announced a completely new range of monitors for HDR production. From 17″ to 55″ these new monitors will compliment their Atomos Sumo, Shogun, Shinobi and Ninja products to provide a complete suite of HDR monitors.

The new Neon displays are Dolby certified and for me this is particularly interesting and perfect timing as I am just about to do the post production on a couple of Dolby certified HDR productions.

I’m just about to leave for the Cinegear show over at Paramount Studios so I don’t have time to list all the amazing features here. So follow the link below to get the full low down on these 10 bit, million:1 contrast monitors.

https://www.atomos.com/neon

Advertisements

Using different gamuts when shooting raw with the PXW-FS5

This topic comes up a lot. Whenever I have been in discussion with those that should know within Sony they have made it clear that the FS-Raw system is designed around S-Log2 for monitoring and post production etc. This stems from the fact that FS-Raw, the 12 bit linear raw from the FS700, FS7 and FS5 was first developed for the FS700 and that camera only had SGamut and S-Log2. S-Log3 didn’t come until a little later.

The idea is that if the camera is set to SGamut + S-Log2 it is optimised for the best possible performance. The raw signal is then passed to the raw recorder where it will be recorded. For a raw recorder that is going to convert the raw to ProRes or DNxHD the recorder converts the raw to S-SGamut + Log2 so that it will match any internal recordings.

Finally in post the grading software would take the FS-Raw and convert it to SGamut + S-Log2 for further grading. By keeping everything as SGamut and S-Log2 throughout the workflow your brightness levels, the look of the image and any LUT’s that you might use will be the same. Internal and external recordings will look the same. And this has been my experience. Use PP7 with SGamut and S-Log2 and the workflow works as expected.

What about the other Gamuts?

However: The FS5 also has SGamut3, SGamut3.cine and S-Log3 available in the picture profiles. When shooting Log many people prefer S-Log3 and SGamut3.cine. Some people find it easier to grade S-Log3 and there are more LUT’s available for S-Log3/SGamut3.cine than for SGamut and S-Log2. So there are many people that like to use PP8 or PP9 for internal S-Log.

However, switching the FS5’s gamma from S-log2 to S-log3 makes no difference to the raw output. And it won’t make your recorder convert the raw to ProRes/DNxHD as S-Log3 if that’s what you are hoping for. But changing the gamut does have an effect on the colors in the image.

But shouldn’t raw be just raw sensor data?

For me this is interesting, because if the camera is recording the raw sensor output, changing the Gamut shouldn’t really change what’s in the raw recording. So the fact that the image changes when you change the Gamut tells me that the camera is doing some form of processing or gain/gamma adjustment to the signal coming from the sensor. So to try and figure out what is happening and whether you should still always stick to SGamut I decided to do a little bit of testing. The testing was only done on an FS5 so the results are only applicable to the FS5. I can’t recall seeing these same changes with the FS7.

DSC Labs Chroma Tru Test Chart.

For the tests I used a DSC Labs Chroma-tru chart as this allows you to see how the colors and contrast in what you record changes both visually and with a vectorscope/waveform. As well as the chart that you shoot, you download a matching reference overlay file that you can superimpose over the clip in post to visually see any differences between the reference overlay and the way the shot has been captured and decoded. It is also possible to place another small reference chart directly in front of the monitor screen if you need to evaluate the monitor or any other aspects of your full end to end production system. It’s a very clever system and I like it because as well as being able to measure differences with scopes you can also see any differences quite clearly without any sophisticated measuring equipment.

Test workflow:

The chart was illuminated with a mix of mostly real daylight and a bit of 5600K daylight balanced light from a Stella LED lamp. I wanted a lot of real daylight to minimise any errors that could creep in from the spectrum of the LED light (The Stellas are very good but you can’t beat real daylight). The camera was set to 2000 ISO. The raw signal was passed from the camera to an Atomos Shogun Inferno where the clips were recorded as both ProRes Raw and also by using the recorders built in conversion to S-Log2 for internal recording as ProRes HQ. I did one pass of correctly exposed clips and a second pass where the clips were under exposed by 1 stop to asses noise levels. The lens was the 18-105mm kit lens, which without the cameras built in lens compensation does show a fair bit of barrel distortion as you will see!

The ProRes clips were evaluated in DaVinci Resolve using the DaVinci Color Managed workflow with the input colorspace set to S-Log2/Sgamut for every clip and output colorspace set to 709. I also had to set the input range of the ProRes clips to Full Range as this is what S-Log2 files always are. If I didn’t change the input range to Full Range the clips exhibited clipped and crushed black after conversion to 709, this confirms that the clips recorded by the Shogun were Full Range – which follows the S-Log specifications.

I did also take a look at the clips in Adobe Premiere and saw very similar results to Resolve.

I will do a separate report on my findings with the ProRes Raw in FCP as soon as I get time to check out the ProRes raw files properly.

So, what did I find?

In the images below the reference file has been overlaid on the very center of the clip. It can be a little hard to see. In a perfect system it would be impossible to see. But you can never capture the full contrast of the chart 1:1 and all cameras exhibit some color response imperfections. But the closer the center overlay is to the captured chart, the more accurate the system is. Note you can click on any of the capture examples to view a larger version.

Digi-ChromaMatch-Lt Using different gamuts when shooting raw with the PXW-FS5
This is the reference file (by the time it gets posted on my website as a jpeg I would no longer guarantee the colors etc. But when you look at the images below you will see this superimposed over the center of the clips.

Below is Picture Profile 6 (PP6) SGamut with S-Log2. It’s pretty good match. The camera didn’t quite capture the full contrast of the chart and that’s to be expected, reflections etc make it very difficult to get perfect blacks and shadow areas. But color wise it looks quite reasonable although the light blue’s are a little weak/pink.

SGamut_1.1.1 Using different gamuts when shooting raw with the PXW-FS5
SGamut and S-Log2

Below is Picture Profile 7 (PP7) SGamut3 with S-Log3. Straight away we can see that even though the camera was set to S-log3, the contrast is the same in the S-Log2 color managed workflow proving that the gamma of the recording is actually ProRes recording from the Shogun is S-log2, confirming what we already know which is that changing the log curve in the camera makes no difference to the raw recording and no difference to the raw to ProRes conversion in the recorder.

Note the extra noise in the greens. The greens appear to have more color, but they also appear a little darker. If you reduce the brightness of a color without altering the saturation the color appears to be deeper and I think that is what is happening here, it is a lightness change rather than just a saturation change. There is also more noise in the darker bars, grey and black really are quite noisy. Light blues have the same weak/pink appearance and there is a distinct green tint to the white, grey and black bars.

SGamut32_1.5.1 Using different gamuts when shooting raw with the PXW-FS5
SGamut3 with S-Log3

Below is when the camera was set to SGamut3.cine with S-Log3. Again we can see that the recording gamma is obviously S-Log2. The greens are still a touch stronger looking but now there is less noise in the greens. Cyan and reds are slightly lighter than SGamut and yellows appear a bit darker. This is also a little more noisy overall than SGamut, but not as bad as SGamut3. When you play the 3 clips, overall SGamut has the least noise, SGamut3.cine is next and then SGamut3 is clearly the noisiest. As with SGamut there is a distinct green tint to the white, grey and black bars.

SGamut3cine2_1.6.1 Using different gamuts when shooting raw with the PXW-FS5
SGamut3.cine with S-Log3

So that’s what the images look like, what do the scopes tell us. Again I will start with SGamut and we can see that the color response is pretty accurate. This suggests that Atomos do a good job of converting the raw to S-Log2/SGamut before it’s recorded and confirms what we already know which is this is that this is clearly how the system is designed to work. Note how the Red strip falls very close to the R box on the 2x vectorscope, yello almost in Y, green very close to G, Blue almost in B. Magenta isn’t so clever and this probably explains why the pinky blues at the top of the chart are not quite right. Do remember that all these test were done with the preset white balance so it’s not surprising to see some small offsets as the white balance won’t have been absolutely perfect. But that imperfection will be the same across all of my test examples.

Screenshot-2019-03-06-at-12.23.31 Using different gamuts when shooting raw with the PXW-FS5
SGamut + S-Log2

Below is SGamut3. The first thing I noticed was all the extra noise on the right side of the waveform where the greens are. The waveform also shows the difference in lightness compared to SGamut with different colors being reproduced at different brightness levels. The greens are being reproduced at a slightly lower luma level and this is probably why the greens appear more saturated. Also notice how much more fuzzy the vectorscope is, this is due to some extra chroma noise. There is a bit more red and magenta is closer to it’s target box, but all the other key colors are further from their boxes. Yellow and Green and Cyan are all a long way from their target boxes. Overall the color is much less accurate than SGamut and there is more chroma noise.

Screenshot-2019-03-06-at-12.23.53 Using different gamuts when shooting raw with the PXW-FS5

And finally below is SGamut3.cine. There is less noise on the green side of the waveform than SGamut and SGamut3 but we still have a slightly lower luma level for green, making green appear more saturated. Again overall color accuracy is not as good as SGamut. But the vector scope is still quite fuzzy due to chroma noise.

Screenshot-2019-03-06-at-12.24.24 Using different gamuts when shooting raw with the PXW-FS5

Under Exposure:

I just want to show you a couple of under exposed examples. These have had the under exposure corrected in post. Below is SGamut and as you can see it is a bit noisy when under exposed. That shouldn’t be a surprise, under expose and you will get noisy pictures.

SGamut_1.1.1-1 Using different gamuts when shooting raw with the PXW-FS5
SGamut with S-Log2 1 stop under (exposure corrected in post)

Below is SGamut3 and you can really see how much noisier this is than SGamut. I recommend clicking on the images to see a full screen version. You will see that as well as the noise in the greens there is more chroma noise in the blacks and greys. There also seems to be a stronger shift towards blue/green in the whites/greys in the under exposed SGamut3.

SGamut3_1.2.1 Using different gamuts when shooting raw with the PXW-FS5
SGamut3 with S-Log3 1 stop under (exposure corrected in post)

Conclusions:

Clearly changing the gamut makes a difference to the raw output signal. In theory this shouldn’t really happen. Raw is supposed to be the unprocessed sensor output. But these test show that there is a fair bit of processing going on in the FS5 before the raw is output. It’s already known that the white balance is baked in. This is quite easy to do as changing the white balance is largely just a matter of changing the gain on the pixels that represent red and blue relative to green. This can be done before the image is converted to a color image.

What I believe I am seeing in this test is something more complex than that. I’m seeing changes in the luminance and gain levels of different colors relative to each other. So what I suspect is happening is that the camera is making some independent adjustments to the gamma of the Red, Blue and Green pixels before the raw signal is output. This is probably a hang over from adjustments that need to be made when recording S-Log2 and S-Log3 internally rather than something being done to deliberately adjust the raw output. But I didn’t design the camera so I can’t be sure that this is really the case. Only Sony would know the truth.

Does it matter?

Yes and no. If you have been using SGamut3.cine and have been getting the results you want, then, no it doesn’t really matter. I would probably avoid SGamut3. It really is very noisy in the greens and shadows compared to the other two. I would be a little concerned by the green tint in the parts of the image that should be colour free in both SGamut3 and SGamut3.cine. That would make grading a little tougher than it should be.

So my advice remains unchanged and continues to match Sony’s recommendation. This is that you should use PP7 with SGamut and S-Log2 when outputting raw. That doesn’t mean you can’t use the other Gamuts and your milage may vary, but these tests do for me at least confirm my reasons for sticking with PP7.

Both Premiere and Resolve show the same behaviour. Next I want to take a look at what happens in FCP with the ProRes Raw clips. This could prove interesting as FCP decodes and converts the FS-Raw to S-Log3 and SGamut3.cine rather than S-Log2/Sgamut by default. Whether this will make any difference I don’t know. What I do know is that having a recorder that’s converting to S-Log2 for display and software that converts to S-Log3 is very confusing as you need different LUT’s for post and the recorder if you want to use LUT’s for your monitoring. But FCP will have to wait for another day. I have paying work to do first.

Sony’s Internal Recording Levels Are Correct.

There is a video on YouTube right now where the author claims that the Sony Alpha cameras don’t record correctly internally when shooting S-Log2 or S-Log3. The information contained in this video is highly miss-leading and the conclusion that the problem is with the way Sony record internally is incorrect. There really isn’t anything wrong with the way Sony do their recordings. Neither is there anything wrong with the HDMI output. While centered around the Alpha cameras the information below is also important for anyone that records S-Log2 or S-log3 externally with any other camera.

Some background: Within the video world there are 2 primary ranges that can be used to record a video signal.

Legal Range uses code value 16 for black and code value 235 for white (anything above CV235 is classed as a super-white and these can still be recorded but considered to be beyond 100%).

Full or Data Range uses code value 0 for black and code value 255 for white or 100%.

Most cameras and most video systems are based on legal range. ProRes recordings are almost always legal range. Most Sony cameras use legal range and do include super-whites for some of the curves such as Cinegammas or Hypergammas to gain a bit more dynamic range. The vast majority of video recordings use legal range. So most software defaults to legal range.

But very, very importantly – S-log2 and S-log is always full/data range.

Most of the time this doesn’t cause any issues. When you record internally in the camera the internal recordings have metadata that tells the playback, editing or grading software that the S-Log files have been recorded using full range. Because of this metadata the software will play the files back and process them at the correct levels. However if you record the S-Log with an external recorder the recorder doesn’t always know that what it is getting is full range and not legal range, it just records it, as it is, exactly as it comes out of the camera. That then causes a problem later on because the externally recorded file doesn’t have the right metadata to ensure that the full range S-Log material is handled correctly and most software will default to legal range if it knows no different.

Lets have a look at what happens when you import an internally recorded S-Log2 .mp4 file from a Sony A7S into Adobe Premiere:

Screenshot-2019-03-01-at-10.04.22 Sony's Internal Recording Levels Are Correct.
Internal S-Log2 in Premiere.

A few things to note here. One is Adobe’s somewhat funky scopes where the 8 bit code values don’t line up with the normally used IRE values used for video productions. Normally 8 bit code value 235 would be 100IRE or 100%, but for some reason Adobe have code value 255 lined up with 100%. My suspicion is that the scope % scale is not video % or IRE but instead RGB%. This is really confusing. A further complication is that Adobe have code value 0 as black, again, I think, but am not sure that this is RGB code value 0. In the world of video Black should be code value 16. But the scopes appear to work such that 0 is black and that 100 is full scale video out. Anything above 100 and below 0 will be clipped in any file you render out.

Looking at the scopes in the screen grab above, the top step on the grey scale chart is around code value 252. That is the code value you would expect it to be, that lines up just nicely with where the peak of an S-Log2 recording should be. This all looks correct, nothing goes above 100 or below 0 so nothing will be clipped.

So now lets look at an external ProRes recording, recorded at exactly the same time as the internal recording and see what Premier does with that:

Screenshot-2019-03-01-at-10.05.32 Sony's Internal Recording Levels Are Correct.
External ProRes in Adobe Premiere

OK, so we can see straight away something isn’t quite right here. In an 8 bit recording it should be impossible to have a code value higher that 255, but the scopes are suggesting that the recording has a peak code value of something around CV275. That is impossible, so alarm bells should be ringing. Something is not quite right here. In addition the S-Log2 appears to be going above 100, so that means if I were to simply export this as a new file, the top of the recording will be clipped and it won’t match the original. This is very clearly not right.

Now lets take a look at what happens in Adobe Premiere when you apply Sony’s standard S-Log2 to Rec-709 LUT to a correctly exposed internal recording:

Screenshot-2019-03-01-at-10.10.05 Sony's Internal Recording Levels Are Correct.
Internal S-Log2 with 709 LUT applied.

This all looks good and as expected. Blacks are sitting down just above the 0 line (which I think we can safely assume is black) and the whites of the picture are around code value 230 or 90, whatever that means. But they are certainly nice and bright and are not in the range that will be clipped. So I can believe this as being more or less correct and as expected.

So next I’m going to add the same standard LUT to the external recording to see what happens.

Screenshot-2019-03-01-at-10.11.24 Sony's Internal Recording Levels Are Correct.
External S-Log2 with standard 709 LUT applied.

OK, this is clearly not right. Our blacks now go below the 0 line and they look clipped. The highlights don’t look totally out of place, but clearly there is something going very, very wrong when we this normal LUT to this correctly exposed external recording. There is no way our blacks should be going below zero and they look crushed/clipped. The internal recording didn’t behave like this. So what is going on with the external recording?

To try and figure this out lets take a look at the same files in DaVinci Resolve. For a start I trust the scopes in Resolve much more and it is a far better programme for managing different types of files. First we will look at the internal S-Log2 recording:

Screenshot-2019-03-01-at-10.21.17-1 Sony's Internal Recording Levels Are Correct.
Internal S-Log2, all looks good.

Once again the levels of the internal S-Log2 recordings look absolutely fine. Our peak is around code value 1010 which would be 252 in 8 bit. Right where the brightest bits of an S-log2 file should be. Now lets take a look at the external recording.

Screenshot-2019-03-01-at-10.22.51 Sony's Internal Recording Levels Are Correct.
External ProRes S-Log2 (Full Range)

If you compare the two screen grabs above you can see that the levels are exactly the same. Our peak level is around CV1010/CV252, just where it should be and the blacks look the same also. The internal and external recordings have the same levels and look the same. There is no difference (other then perhaps less compression and fewer artefacts in the ProRes file). There is nothing wrong with either of these recordings and certainly nothing wrong with the way Sony record S-Log2 internally. This is absolutely what I expect to see.

BUT – I’ve been a little bit sneaky here. As I knew that the external recording was a full range recording I told DaVinci Resolve to treat it as a full range recording. In the media bin I right clicked on the clip and under “clip attributes” I changed the input range from “auto” to “full”. If you don’t do this DaVinci Resolve will assume the ProRes file to be legal range and it will scale the clip incorrectly in the same way as Premiere does. But if you tell Resolve the clip is full range then it is handled correctly.

This is what it looks like if you allow Resolve to guess at what range the S-Log2 full range clip is by leaving the input range setting to “auto”:

Screenshot-2019-03-01-at-10.24.46 Sony's Internal Recording Levels Are Correct.
External ProRes S-Log2 Auto Range

In the above image we can see how in Resolve the clip becomes clipped because in a legal range recording anything over CV235/CV940 would be an illegal super white. Resolve is scaling the clip and pushing anything in the original file that was above CV235/CV940 off the top of the scale. The scaling is incorrect because Resolve doesn’t know the clip is supposed to be full range and therefore not scaled. If we compare this to what Premiere did with the external recording it’s actually very similar. Premiere also scaled the clip, only Premiere will show all those “illegal” levels above it’s 100 line instead of clipping then as Resolve does. That’s why Premiere can have those “impossible” 8 bit code values going up to CV275.

Just to be complete here, I did also test the internal .mp4 recordings in Resolve switching between “auto” and “full” range and in both cases the levels stayed exactly the same. This shows that Resolve is correctly handling the internally record full range S-Log as full range.

What about if you add a LUT? Well you MUST tell Resolve to treat the S-Log2 ProRes clip as a full range clip otherwise the LUT will not be right, if your footage is S-Log3 you also have to tell Resolve that it is full range:

Screenshot-2019-03-01-at-13.09.16 Sony's Internal Recording Levels Are Correct.
Resolve: Internal recording with the standard 709 LUT applied, all is exactly as expected. Deep shadows and white right at the top of the range.
Screenshot-2019-03-01-at-13.10.10 Sony's Internal Recording Levels Are Correct.
Resolve: External recording with the standard 709 LUT applied, clip input range set to “full”. Everything is once again as you would expect. Deep shadows and white at the top of the range. Also not that it is near perfect match to the internal recording. No hue or color shift (Premiere introduces a color shift, more on that later).
Screenshot-2019-03-01-at-13.14.02 Sony's Internal Recording Levels Are Correct.
Resolve: External recording with the standard 709 LUT applied, clip input range set to “auto”. This is clearly not right. The highlights are clipped and the blacks are crushed and clipped. It is so important to get the input range right when working with LUT’s!!

CONCLUSIONS:

Both the internal and external recordings are actually exactly the same. Both have the same levels, both use FULL range. There is absolutely nothing wrong with Sony’s internal recordings. The problem stems from the way most software will assume that the ProRes files are legal range. But if it’s an S-Log2 or S-Log3 recording it will in fact be full (data) range. Handling a full range clip as legal range means that highlights will be too high/bright or clipped and blacks will be crushed. So it’s really important that your software handles the footage correctly. If you are shooting using S-Log3 this problem is harder to spot as S-Log3 has a peak recording level that is well with the legal range, so you often won’t realise it’s being scaled incorrectly as it won’t necessarily look clip. If you use LUT’s and your ProRes clips look crushed or highlights look clipped you need to check that the input scaling is correct. It’s really important to get this right.

Why is there no difference between the levels when you shoot with a Cinegamma? Well when you shoot with a cinegamma the internal recordings are legal range so the internal recordings get treated as legal range and so do the external recordings, so they don’t appear to be different (In the YouTube video that led to this post the author discovers that if you record with a normal profile first and then switch to a log profile while recording the internal and external files will match. But this is because now the internal recording has the incorrect metadata, so it too gets scaled incorrectly, so both the internal and external files are now wrong – but the the same).

Once again: There is nothing wrong with the internal recordings. The problem is with the way the external recordings are being handled. The external recordings haven’t been recorded incorrectly, they have been recorded as they should be. The problem is the edit software is incorrectly interpreting the external recordings. The external recordings don’t have the necessary metadata to mark the files as full range because the recorder is external to the camera and doesn’t know what it’s being sent by the camera. This is a common problem when using external recorders.

What can we do in Premiere to make Premiere work right with these files?

You don’t need to do anything in Premiere for the internal .mp4 recordings. They are handled correctly but Premiere isn’t handling the full/data range ProRes files correctly.

My approach for this has always been to use the legacy fast color corrector filter to transform the input range to the required output range. If you apply the fast color corrector filter to a clip you can use the input and output level sliders to set the input and output range. In this case we need to set the output black level to CV16 (as that is legal range black) and we need to set output white to CV235 to match legal range white. If you do this you will then see that the external recording appears to have almost exactly the same values as the internal recording. However there is some non-linearity in the transform, it’s not quite perfect. So if anyone knows of a better way to do this do please let me know.

Screenshot-2019-03-01-at-11.04.04 Sony's Internal Recording Levels Are Correct.
Using the legacy “fast color corrector” filter to transform the external recording to the correct range within Premiere.

Now when you apply a LUT the picture and the levels are more or less what you would expect and almost identical to the internal recordings. I say almost because there is a slight hue shift. I don’t know where the hue shift comes from. In Resolve the internal and external recordings look pretty much identical and there is no hue shift. In Premiere they are not quite the same. The hue is slightly different and I don’t know why. My recommendation – use Resolve, it’s so much better for anything that needs any form of grading or color correction.

Windows 10 and removable media.

It has come to my attention that there was a bug in Windows 10 a couple of years ago that could cause some very big problems. The bug was patched by Microsoft so provided the computer is up to date this should not be a problem. But there are other things that can cause a card to become corrupted or un-readable before you have had a chance to make a copy of your files.

With the problem release of Windows 10, when you connected removable media to the computer that contained audio files the computer would attempt to encrypt the card. When you try to browse to the files instead of being able to open the files they will show up as files with a size of 0 Bytes and you won’t be able to do anything with them on any computer. But, as I said this issue was fixed some time ago. So provided the computer has been kept up to date this should no longer be an issue. So make sure your computer is up to date!

But it is also worth noting that Windows 10 includes an encryption app called BitLocker. If this is a accidentally used on any of your removable media it will make that media impossible to read on any other device and the files will appear to be 0 Bytes long until the media is unlocked.

In addition there have been problems with the drivers for some card readers that have led to the corruption of SD cards. So make sure your drivers are up to date and do some test transfers before plugging in a card with anything important on it.

Use the write protect tab on SxS and SD cards.

If you are using SxS cards or SD cards, the cards have a write protect tab. If you lock the card before connecting it to the computer it will prevent the computer from writing to the card and this will protect your media from corruption. You should always do this if you can and then verify your copies, preferably including clip playback as one of your copy checks. Ideally you should use dedicated backup software such as Hedge or Shot Put Pro to do verified copies and transfers. Sony’s Catalyst Prepare can also copy clips with checksum verification.

New Training Videos For DaVinci Resolve.

Blackmagic Designs DaVinci Resolve is a really amazing piece of software, especially given that there is a free version that packs in almost all of the power of the full paid studio version.

Today, post production grading is becoming an ever more important part of the video production process. In the past basic colour correction functions of most edit applications were enough for most people. But now if you are shooting using log or raw it’s very important that you have the right toolset to take advantage of the benefits that log and raw offer.

For decades I have used Adobe Premiere for my editing and it has allowed me to create many great videos from broadcast TV series to simple corporates. As an edit application it’s still pretty solid. But now I shoot almost everything using log and raw and I have never been completely happy with the results from Premiere, even with Lumetri.

So I started to do my grading in Resolve and I have never looked back. The degree of control I have in Resolve is much greater. There are wonderful features such as DaVinci’s own Colour Managed workflow or the ACES workflow which makes dealing with log and raw from virtually any camera a breeze. If you want a film look choose ACES, for more punchy looks choose DaVinci Color Managed. You don’t need LUT’s, exposure adjustments are easy and you can then add all kinds of different secondary corrections such as power windows quickly and easily. The colour managed workflow are particularly beneficial if you wish to produce HDR versions of your productions.

But until recently my workflow was a 2 stage workflow. Edit in Premiere, then grade and finish in Resolve. But the last couple of versions of Resolve have seen some huge advances in its editing speed and capabilities. The editor is now as good as anyone else’s, so I am now editing in Resolve too. It’s a very similar to Premiere so it didn’t take long to make the switch.

One question that I am often asked is where to find good training information and guides for Resolve. Well clearly Blackmagic Design have been listening as they have now released a series of videos that will help guide anyone new to Resolve through the basics. In total there are 8 hours of easy to follow video. The manual is also pretty good!

If you have never tried Resolve then I really urge you to give it a go. It is an incredibly powerful piece of software. It isn’t difficult to master once you see how it’s laid out, how the different “rooms” work and how to use nodes. When I started with it I really found it all quite logical. You start in the “media” room to bring in your material, then progress on to the edit room for editing, finishing in the deliver room to encode and produce your master files and other output versions.

So do take a look at the videos linked below if you want to learn more about Resolve and do give it a try. Remember the free version will do almost everything that the full version will. The full Studio version isn’t expensive and features one of the best suites of noise reduction tools anywhere. It only costs a one off payment of $299.00 USD, no silly subscription fees to keep having to pay as with Adobe!

One last thing before I get to the videos: If you do a lot of grading you really should get a proper control panel. I have the Blackmagic micro panel and this really speeds up my grading. If you don’t have a panel you can only adjust a single grading parameter at a time. With a panel you can do things like bringing up the gain while pulling down the black level. This allows you to see the interaction between your different adjustments much more dynamically and it’s just plain faster. Most of the key functions have dedicated controls so you can quickly dial in a bit of contrast, switch to log mode, bypass a node and boost the saturation all through direct controls, very much quicker than with just a mouse. The use of the micro panel has probably halved the amount of time it takes me to grade a typical project – and – I’m getting a better result because it’s more intuitive.

So here are the videos:

Introduction to Editing.
Colour Grading. Fusion Part 1. VFX and Graphics Fusion Part 2. 3D FX Fairlight Audio Part 1. Fairlight Audio Part 2. Delivery and Encoding. Media Mangement. DaVinci Resolve Mini Panel.

Recovering footage from formatted cards.

Following a series of recent discussions about whether or not it was possible to recover files from XQD cards that have been formatted by mistake I have obtained some clarification from Sony of what can or can’t be done.

This information is specifically for XQD cards and the PXW-FS7 but probably applies to most Sony cameras and also SxS media. I’m not sure about SD cards.

Formatted In-Camera:

The bottom line is that if you format the card in the camera you will not be able to recover any previously shot material. An in-camera format completely erases everything on the card. This is done to ensure that material shot on the cards cannot be recovered by another production company in the case of card or camera rentals. So there is no point in attempting any form of data recovery on a card formatted in the camera as there is nothing recoverable left on the card.

Formatted by a computer:

When you format a card with a computer it is possible that the material will still be on the card. However different operating systems handle the formatting of the cards differently, so there is no guarantee that the data will be recoverable and often it won’t be recoverable. For very important material it may be worth attempting to recover the card. Sony may be able to assist with this in some cases.

Deleted Clips:

Clips deleted from a card can typically be recovered provided they have not be recorded over by a later recording. Again Sony may be able to assist with this.

Delete or Format?

Based on this new information from Sony I may be adjusting my workflow. My own workflow has always been to off-load material from a card. Then to do a parity check to compare the original files on the card and what is now on the hard drives. This checks not just the file size but also the general structure of the files so should pick up most problems with any copies. My last check is then to skim through the files with Catalyst Browse or my edit application to make sure the clips are there and playable. Only then do I format a card. In light of this new information I may use my computer to delete the clips from a card rather than format it. Of course this will only ever offer some benefit if the card is not recorded on again causing the previous files to be over written, but it might add an extra chance of data recovery should the backups get lost or some other disaster occur. From time to time I would format the cards in camera as this helps keep the cards in the best possible condition.

Do the images from my Sony camera have to look the way they do?

— And why do Sony cameras look the way they do?

It all about the color science.

“Color Science” is one of those currently in fashion phrases that gets thrown around all over the place today. First of all – what the heck is color science anyway? Simply put it’s how the camera sees the colors in a scene, mixes them together, records them – and then how your editing or grading software interprets what is in the recording and finally how the TV or other display device turns the digital values it receives back into a color image. It’s a combination of optical filters such as the low pass filter, color filters, sensor properties, how the sensor is read out and how the signals are electronically processed both in the camera, by your edit/grading system and by the display device. It is no one single thing, and it’s important to understand that your edit process also contributes to the overall color science.

Color Science is something we have been doing since the very first color cameras, it’s not anything new. However us end users now have a much greater ability to modify that color science thanks to better post production tools and in camera adjustments such as picture profiles or scene files.

Recently, Sony cameras have sometimes been seen by some as having less advanced or poor color science compared to cameras from some other manufacturers. Is this really the case? For Sony part of the color science issue is that historically Sony have deliberately designed their newest cameras to match previous generations of cameras so that a large organisation with multiple cameras can use new cameras without having them look radically different to their old ones. It has always been like this and all the manufacturers do this, Panasonic cameras have a certain look as do Canon etc. New and old Panasonics tend to look the same as do old and new Canon’s, but the Canon’s look different to the Panasonics which look different to the Sony’s.

Sony have a very long heritage in broadcast TV and that’s how their cameras look out of the box, like Rec-709 TV cameras with colors that are similar to the tube cameras they were producing 20 years ago. Sony’s broadcast color science is really very accurate – point one at a test chart such as a Chroma DuMonde and you’ll see highly repeatable, consistent and accurate color reproduction with all the vectors on a vector scope falling exactly where they should, including the skin tone line.

On the one hand this is great if you are that big multi-camera business wanting to add new cameras to old ones without problems, where you want your latest ENG or self-shooters cameras to have the same colors as your perhaps older studio cameras so that any video inserts into a studio show cut in and out smoothly with a consistent look.

But on the other hand it’s not so good if you are a one man band shooter that wants something that looks different. Plus accurate is not always “pretty” and you can’t get away from the fact that the pictures look like Rec-709 television pictures in a new world of digital cinematography where TV is perhaps seen as bad and the holy grail is now a very different kind of look that is more stylised and much less true to life.

So Sony have been a bit stuck. The standard look you get when you apply any of the standard off-the shelf S-Log3 or S-Log2 LUT’s will by design be based on the Sony color science of old, so you get the Sony look. Most edit and grading applications are using transforms for S-Log2/3 based on Sony’s old standard Rec-709 look to maintain this consistency of look. This isn’t a mistake. It’s by design, it’s a Sony camera so it’s supposed to look like other Sony cameras, not different.

But for many this isn’t what they want. They want a camera that looks different, perhaps the “film look” – whatever that is?

Recently we have seen two new cameras from Sony that out of the box look very different from all the others. Sony’s high end Venice camera and the lower cost FS5 MKII. The FS5 MKII in particular proves that it’s possible to have a very different look with Sony’s existing colour filters and sensors. The FS5 MK II has exactly the same sensor with exactly the same electronics as the MK I. The only difference is in the way the RGB data from the sensor is being processed and mixed together (determined by the different firmware in the Mk1 and mk2) to create the final output.

The sensors Sony manufacture and use are very good at capturing color. Sony sensors are found in cameras from many different manufacturers. The recording systems in the Sony cameras do a fine job of recording those colors as data within the files the camera records as data with different code values representing what the sensor saw. Take that data into almost any half decent grading software and you can change the way it looks by modifying the data values. In post production I can turn almost any color I want into any other color. It’s really up to us as to how we translate the code values in the files into the colors we see on the screen, especially when recording using Log or raw. A 3D LUT can change tones and hues very easily by shifting and modifying the code values. So really there is no reason why you have to have the Sony 709 look.

My Venice emulation LUT’s will make S-Log3 from an FS5 or FS7 look quite different to the old Sony Broadcast look. I also have LUT’s for Sony cameras that emulate different Fuji and Kodak film stocks, apply one of these and it really looks nothing like a Sony broadcast camera. Another alternative is to use a color managed workflow such as ACES which will attempt to make just about every camera on the market look the same applying the ACES film style look and highlight roll-off.

We have seen it time and time again where Sony footage has been graded well and it then becomes all but impossible to identify what camera shot it. If you have Netflix take a look at “The Crown” shot on Sony’s F55 (which has the same default Sony look as the FS5 MK1, FS7 etc). Most people find it hard to believe the Crown was shot with a Sony because it has not even the slightest hint of the old Sony broadcast look.

If you use default settings, standard LUT’s etc it will look like a Sony, it’s supposed to! But you have the freedom to choose from a vast range of alternative looks or better still create your own looks and styles with your own grading choices.

But for many this can prove tricky as often they will start with a standard Sony LUT or standard Sony transform. So the image they start with has the old Sony look. When you start to grade or adjust this it can sometimes look wrong because you have perhaps become used to the original Sony image and then anything else just doesn’t seem right, because it’s not what you are used to. In addition if you add a LUT and then grade, elements of the LUT’s look may be hard to remove, things like the highlight roll off will be hard baked into the material, so you need to do need to think carefully about how you use LUT’s. So try to break away from standard LUT’s. Try ACES or try some other starting point for your grade.

Going forward I think it is likely that we will see the new Venice look become standard across all of the Cinema style cameras from Sony, but it will take time for this to trickle down into all the grading and editing software that currently uses transforms for s-Log2/3 that are based on the old Sony Rec-709 broadcast look. But if you grade your footage for yourself you can create just about any look you want.

Black and White LUT set.

This was asked for on one of the online groups I follow. It’s a simple Black and White LUT that gives a wide dynamic range black and white image. The LUT has been designed to give a pleasing and gentle highlight roll-off with a reasonably contrasty mid range. I decided not to go too contrasty via the LUT so that more contrast can be added in post if needed. The output is legal range (broadcast safe). There is a single camera LUT for use in camera as well as a set of exposure compensated LUT’s going from -2 to plus 2 stops in half stop steps.

As always (to date at least) I offer these as a free download available by clicking at the bottom of the page. It takes time to create them and money to host them. I feel that this LUT set is worth $5.00 and would really appreciate that being paid if you find the LUT’s useful. But I will let you pay what you feel is fair, all contributions are greatly appreciated and it really does help keep this website up and running. If you can’t afford to pay, then just download the LUT’s and enjoy using them. If in the future you should choose to use them on a paying project, please remember where you got them and come back and make a contribution. More contributions means more LUT offerings in the future.

Please feel free to share a link to this page if you wish to share these LUT’s with anyone else or anywhere else.

To make a contribution please use the drop down menu here, there are several contribution levels to choose from.


Your choice:



pixel Black and White LUT set.

Click here to download AC Black and White LUT’s V1

SEE ALSO:

Film Emulation LUT’s set 1.

Venice Look LUT’s V3 (lower contrast and minus green)

Venice Look LUT’s V1 (high contrast)

HLG HDR LUT for FS7, F5 and F55.

WYSIWYG LUT’s (Designed to be baked in)

Adobe still can’t get XAVC levels right!

I’m often asked at the various workshops I run why I don’t grade in Adobe Premiere. Here’s why – they can’t even get basic import levels right.

Below are two screen grabs. The first is from Adobe Premiere CC 2019 and shows an ungraded, as shot, HLG clip. Shot with a Sony Z280 (love that little camera). Note how the clip appears over grossly exposed with a nuclear looking sky and clipped snow, it doesn’t look nice. Also note that the waveform suggest the clips peak levels exceed 110%. Now I know for a fact that if you shoot HLG with any Sony camera white will never exceed 100%.

Adobe-HLG1c-1024x626 Adobe still can't get XAVC levels right!
Incorrect levels with an XAVC clip in Adobe Premier. Click on the image to view a larger version.

The second screen grab is from DaVinci Resolve and it shows the same clip. Note how in Resolve that although bright the clip certainly doesn’t look over exposed as it does in Premiere. Note also how the levels show by the waveform now no longer exceeds code value 869 (100% white is 940).  These are the correct and expected levels, this is how the clip is supposed to look. Not the utter nonsense that Adobe creates.

resolve-hlg1b-1024x626 Adobe still can't get XAVC levels right!
Same XAVC clip in Resolve and now the levels are correct. Click on the image to view a larger version.

Why can’t Adobe get this right. This problem has existed for ages and it really screws up your footage. If you are using S-Log and you try to add a LUT then things get even worse as the LUT expects the correct levels, not these totally incorrect levels.

Take the SDI or raw out from the camera and record a ProRes file on something like a Shogun while recording XAVC internally and the two files look totally different in Premiere but they look the same in Resolve. Come on Adobe – you should be doing better than this.

If they can’t even bring clips in at the correct levels, what hope is there of being able to get a decent grading output? I can make the XAVC clips look OK in Premiere but I have to bring the levels down to do this. I shouldn’t have to. I exposed it right when I shot it so I expect it to look right in my edit software.