joema

Forgot to add: starting with Resolve Studio 18.5, it reads the EI (Exposure Index) data from the FX6 and FX9 and automatically applies that in post in the color page's RAW controls. Previously, an issue with the FX6/FX9 "ISO/gain" switch (in Cine EI mode, the L/M/H EI switch) on the FX6/FX9 was no NLE software could interpret it. Now Resolve does. In Cine EI mode, the camera switch did two things: (1) Altered the *apparent* (not actual) exposure if using an MLUT, and (2) Wrote the selected EI data to the MXF file metadata. However this meant if you never used EI and MLUTs, your L/M/H EI switch (and associated menu settings) might have been in any state. Starting with Resolve Studio 18.5, it reads and automatically applies the L/M/H switch state -- even if you never used MLUTs. That alters the exposure slider in the RAW controls of Resolve's color page. E.g, say two years ago you pulled your FX6/FX9 out of the bag and something moved that switch. It made no difference unless you were using Cine EI mode *and* MLUTs. Now on Resolve 18.5+, whatever position that switch was two years ago now matters. It's not a big deal because the changes are "lossless" -- you just move the exposure slider in Resolve. But it could cause certain clips to suddenly appear in Resolve as over or under-exposed. My team still doesn't use MLUTs or the L/M/H ISO/gain switch. However, we have now programmed the FX6 Main Menu>Shooting>ISO/gain EI settings to 800 for all three switch positions in low base sensitivity and 12800 for all three switch positions in high base sensitivity. That means no matter what position the switch is in, it will not cause an exposure offset change in Resolve Studio. Again, those changes are easy to fix but this prevents it from surprising anybody in post for future clips.

Unfortunately, my team never uses S-Gamut3, only S-Log3/S-Gamut3.cine, so I don't have any experience with regular S-Gamut3. However, we do use an S-Log3-to-Rec.709 monitoring LUT on the Atomos Ninja V and Shogun 7 from our FX6 cameras. We use Alister Chapman's LUTs which are in various versions, including G1 and G2 variants with green correction and monitoring LUTs: https://www.xdcam-user.com/2018/08/new-venice-look-luts-version-3-includes-minus-green-luts-for-fs5-fs7-f55-a7s-a7r/alister-v-look-v3-s-log3/ On the FX6s we use only Cine EI mode and don't use any MLUTs, just monitor using waveform in S-Log3. We set exposure at 61% to 68% IRE on a 90% reflective white target using Zebra 2. That is the procedure recommended by Doug Jensen in his classes. I've seen countless operators try more complex procedures and they often get confused and make mistakes. Thanks, Doug, your advice has saved us many times! Starting with Resolve 18.5, there are "RAW controls for XAVC," which requires Cine EI S-Log3 XAVC-I MXF files from the FX6 and FX9. This enables RAW-like corrections to white balance, tint and exposure in post. It's not equal to true RAW but it's very nice. Here are some full-res TIFF frame grabs comparing extreme WB adjustment in FCP using ProRes RAW vs simultaneously-recorded FX6 XAVC-I using Resolve 18.5 "RAW controls for XAVC": https://www.dropbox.com/scl/fo/kr0x078460qichhgy5r8z/h?rlkey=mhc90mr03xgwc8tw4bnhsm2zx&dl=0 It works so well that we rarely use ProRes RAW from the FX6 cameras. We do use ProRes RAW on the DJI Ronin 4D because it has no equivalent to this adjustability without using RAW. I don't think Resolve currently provides that feature for any other brand or camera -- only the Sony "cinema" series. I don't know who in Blackmagic and Sony negotiated that but it is a fantastic feature.

Doug was talking about a two-camera interview, happens in one location and typically has good audio and relatively few takes. Yes, in that case, you often don't need timecode. But what if it's a documentary and you're shooting 50 interviews over six months in different locations? What if it's intercut with event B-roll shot by three widely separated cameras doing dozens of stop/start takes? What if it's stand-up interviews in a disaster area and due to the stress, a camera operator misses the slate and accidentally has his audio turned off? What if you're looking through hundreds of interview files in post, and some operators had the wrong date/time on their camera? Timecode comes in really handy in all those situations. For all those reasons (and more) my team always uses timecode, even for "easy" two-camera interviews. It keeps the procedures fresh and ensures ongoing familiarity with the devices, cables, adapters and camera timecode operation. Regarding jam sync vs. continuous timecode, we've done it both ways, but having a continuous timecode device on each camera and recorder seems more reliable. E.g, after jam sync the FX6 maintains TC during shutdown for battery changes, but some of our RED cameras did not until a firmware update. It's easier to verify and resync the cameras using a smartphone app than revisiting each camera. There is no "harm" from TC drift. They will drift anyway, whether TC synced or not. Even though continuous TC does not lock the cameras together, when the TC devices are remotely resynced via smartphone device or if the camera is shut down to change batteries, etc. it will usually automatically resync from the TC master. So this tends to shorten the drift period to typically around 1-2 hrs. If the camera internal timebases have significant drift, that will exist even if syncing by audio. Most NLE audio sync algorithms use a single point on each clip. If the camera timebases are drifting, it will drift before/after that sync point on the 30 min. clip. The former Plural Eyes sync app had continuous sync drift correction, but that only applied to an audio file, not two A/V files. It's important to do long-duration test clips in advance and characterize the drift behavior of the specific recorders and cameras. Our FX6 cameras and Sound Devices audio recorders have all shown very low drift. That assumes you don't make a mistake and intermix DF and NDF timecode between cameras. Now THAT will drift.

I have tested simultaneously-recorded S-Log3 FX6 4k/23.98 10-bit 4:2:2 XAVC-I vs 4k/23.98 ProRes 422 (recorded on Atomos) many times. A few people have alleged XAVC-I has significant "macro blocking" issues on certain scene types, especially complex tree branches moving in the wind. The videos they've posted allegedly showing these used zoom factors of 400% to 1000%. In general I can't see any difference when viewed normally or even when cropped to the maximum 200% limit for maintaining equivalent resolution for 4k on 1080p presentation. When comparing them in an NLE using overlayed clips with the top layer using "difference" compositing instead of "normal", you can see some *tiny* differences but when viewed normally, I can't see differences except in rare cases on paused frames at about 400% or so magnification. Here are some original camera files of simultaneously-recorded FX6 XAVC-I S-Log3 vs ProRes 422 from a Shogun 7. Also included is a split-screen 200% full-res TIFF file showing the same frame from both formats. It's not labeled, but according to those claiming the XAVC-I problem, it is so obvious that anybody can tell the difference under normal viewing conditions. However, I cannot tell the difference even at 200% magnification -- and of a scene type that supposedly manifests the problem: https://www.dropbox.com/scl/fi/40nkhlin8x6gn3mzy07oo/SHGN7_S001_S001_T021.MOV?rlkey=itzbt86ie81ti8ron7pg9wueo&dl=0 Also, the MXF container used by the FX6 has much better metadata than externally-recorded ProRes. For S-Log3 it enables the "raw controls for XAVC" feature of Resolve Studio 18.5 and later. It's not true RAW, but it enables RAW-like adjustments in post for white balance, tint, exposure, etc.