Calibrating monitors for HLG-1.2 High Dynamic Range working

I've now done a couple of Sony BVM-X300 (4k/HDR OLED panel) monitors for HDR-TV deliverables to the BBC. The Beeb are behind the Hybrid Log Gamma standard, currently at 1.2 for broadcast. It's benefits over Dolby's 10-bit version of their Vision HDR system (also called DolbyPQ) are many and rather splendidly the DVB as well as most manufacturers are now behind HLG. I'll write further about why a scene-referred system is a better bet for domestic TV than a display-referred one (like DolbyPQ) but I just wanted to get down some notes on monitor calibration for HLG.

So first up you need to get the monitor into HDR mode (the correct one! As of v.2 firmware the X300 supports several; the camera gammas; CLog, CLog2, SLog & SLog3 as well as the deliverable standards; SMPTE-2084 (DolbyPQ) as well as SMPTE-2100 (HLG 1.2).

You'll notice the EOTF setting (lit. "Electronic - Optical Transfer Function") is NOT set for HLG 1.2; this available but in the current v. 2.0 firmware it is wrong. Select HLG (Variable), click the know again and dial in 1.2

Next up display a 50% grey field (100% can't be done as the monitor power-limits to stop 1,000Cd/m² being displayed across a lot of the screen) and point your probe at the display. Remember that unlike DCI-P3 we are still at the 6504K white point of tele. However - at 50% grey we should be seeing low-50's Cd/m² being emitted from the screen. 

You might have previously heard Sony's "best practise" (sic) advice of setting 50% grey to 100Cd/m² but this is wrong. Look at the graph; this is the result of profiling an X300 (and they all seem to do it consistently) and notice what happens over the last couple of hundred Candelas at the top end. If you set 50% grey to 100Cd/m² you get loss of detail in the specular highlights. For the correctly 1.2 HLG curve you need to set 50% to around 50Cd/m² to 55Cd/m²- remember the Y-axis on this graph is logarithmic. 

The one display I had previously followed the Sony advice for was sufficiently out of it's linear range that the dark-greys drifted red minutes after I finished adjusting the monitor and (like all OLEDs) the noise in their blacks is sufficient to make the final tweak to 6504k hard work - the Klein probe was having to average over 32 reads to accommodate the OLED panel. Remember - the K10A is accurate to less than 0.001 Cd/m² and not the 1.0 Cd/m² it reads at 10% up the curve of HLG 1.2

So - once you have those under your belt you can PLUGE the display to set blacks correctly for the room (what did I say about scene/display referred?!) and then set about getting the deep greys and the 50% colour balance correct. I've done this now on two X300s with BBC R&D engineers in attendance and they have given this method their blessing!

For a probe I was using a Klein K10A with Klein's own ChromaSurf software. If I get the chance to profile an X300 for myself I will do it with LightSpaceCMS - still the choice of champions for display profiling and LUT-building. They also have an excellent article introducing HDR.

Failure of the BBC's "Digital Media Initiative" and other large IT projects

I still describe myself as a Broadcast Engineer rather than a project manager - and in fairness I do spend more time looking at cable-schedules and schematics than Gantt charts. However; I am often responsible for other people's money in achieving what they want in TV and data facilities. Compared to the BBC DMI project the largest project I've had overall financial responsibility for came to a bit more than 1% of the size of that gig so I am in no means an expert. However - I have worked for dozens of large and small broadcasters and I think I've seen some of the best and worst aspects of other people's project management styles.

I feel sorry for John Linwood - the BBC's CTO who has been suspended over the whole debacle. It's telling that the Beeb now have a CTO rather than a Chief Engineer as that latter term implies that you've had a career in broadcast engineering - you've calibrated monitors, fixed studio cameras (and then racked them in live productions), installed Media Composer (and supported the editors), replaced the head-drums in VTRs as well as the myriad other bits of experience that the top technical job at the world's most prestigious broadcaster would imply. John is a similar age to me and so I'd expect him to remember mk.2 telecines, tubed cameras and 1" VTRs but he's a software guy; ex-Yahoo, ex-Microsoft and it's there you'll find both the justification for him being the Beeb's top technical guy and the reasons for the pickle he's now in. The DMI was a software project BUT software projects have a huge propensity to fail. Around 30% of software projects in commercial industry fail - but that's OK; you have to take risks and great things don't come if there wasn't a danger of failure (that's why it's a risk!). However - in government IT projects the risk of failure is an awful lot higher - typically 70% for publicly-funded IT projects. You'd expect project manager who are being paid with tax-dollars to be more risk-averse but the opposite seems true. Clearly this has been the case at the BBC with the DMI. 

Ross Anderson has written extensively about this kind of thing; he did an interview with Stephen Fry on Radio 4 a couple of years ago which makes a lot of these points; as an aside his brilliant book "Security Engineering" is now in the public domain.

Here are a few thoughts on big-organisation technical projects;

• The danger of "not invented here" - when I was at the BBC most custom projects (i.e. equipment and solutions not bought in from external manufacturers) were often specified and implemented by Research Department. In fact too many projects were as there was an attitude of "nobody understands what we do except us" and so consequently too many things were done by people who might be doing it for the first or second time (chief engineers of facilities will have designed/built maybe two or three machines rooms in their twenty year career - I've done it dozens of times in the last decade!). 
• "Gold plating" everything - In the late eighties/early nineties there was a guy in BBC Research Department who liked the DEC MicroVax 3100-series running VMS (at the time it was a £35k industrial computer) and so whenever a project needed an external computer we'd see a MicroVax appear in the machine room. Automated upload of new weather symbols to the Quantel Paintbox - throw a MicroVax at it. Download realtime financial data from Reuters to make the Aston strap for the breakfast news financial segment; control the caption generator with a MicroVax! However - when it fell on the maintenance department to make something work they typically used a BBC Micro (we all had them at home and new how to program/homebrew them) - the ASTED project to control external logo generators and make them work with the Aston caption machine for news programmes was all done via a £350 BBC Micro, not a £35k MicroVax.
• In a similair vein I had a friend who was working on the NHS unified records system for EDS - he spent eighteen months working on a new secure-VPN protocol; that's not a problem that needs solving! That one is already done with a choice of closed and open-software solutions.
• Don't despise project management methodologies. Lots of engineers have a distrust of Prince2 and it's ilk and for sub-£1m projects the overheads are too onerous, but there are so many valuable lessons that proper project managers bring. In a recent discussion with a colleague about how one project had turned quite painful we realised that the PM101 principle of fully involving the users had been almost totally missed by the customer and it was proving hard to get the poor editors and assistants to buy-into the new system once they saw the implementation.
• "Good, Fast, Cheap - choose only two" - this is the warning PMs often give and it's regarded as customers as a prohibition rather than a good principle to run a project by. The tension of having to hold those three ideas and adjust the sliders as necessary means you don't push them all to the max and expect the best outcome. If they had regarded this principle there is no way they would have let the thing drag on for five years. Timely projects are the best kind.
• Specify, specify, specify - the more you leave to fortune or to the contractors' discretion means you have too many undefined problems.
• Don't disregard experience - the engineer who taught me all I really know about broadcast SI - Chris Clegg - had one thing he used to say about designing facilities; "...given a crew of qualified operators they should be able to run this studio/OB truck/machine room with only fifteen minutes instruction from the usual operator". You can't do that without intimately understanding how TV workflows interact with facilities and how operators and assistants operate. The point is that the best broadcast project managers have years of experience in those areas. Professional project managers (who aren't experienced engineers) don't have those insights.

One thing I can't understand is why Siemens were initially given the project; are they renowned for any of the things that were trying to be achieved? - big database, large video storage, transcoding, version management and the underlying filesystem to make it all hang together? Given that it also has to work with your editing, transmission, and VOD platforms why on Earth not get Avid, Isilon, Google etc involved; OneFS for the backend and GFS for the database sound like they were designed for this (and they also run most of the big Internet media sites).

It'll be interesting to see if the BBC takes on an experienced engineer as their next CTO.

The end of Television Centre - what's changed since I was there?

I joined the Beeb in 1988 and spent the first five years of my career in and around TV Centre. My first BBC posting was to Lime Grove studios (which was a few hundred metres behind the centre) with the occasional foray up to Studio 2 to do camera control on Newsnight. 

Although it's now twenty years since I worked for the BBC I still hold the corporation in great fondness for training me and always encouraging best practice from an engineering point of view. I don't think I could have had a better start in the industry. I honestly believe the BBC is a civilizing force and an example of just how good and truthful a broadcaster can be. They are without equal in my view.

Anyhow - just a few notes on how things have changed since 1988;

Videotape - 2", 1" and 1/2" BetaSP (just coming in) and UMatic or even VHS for offline and viewing copies. Since I worked in news some footage arrived on UMaticSP - BVU900 style.

Digital Video - when I started there was very little equipment that was digital; even less so that was run by a microprocessor. PCs were never seen as everything was built for the purpose (and cost £100k as a consequence!). Aside from D1 videotape (that was still very much being demo'ed at trade shows) you found digital video inside equipment, not used to interconnect it;

• TBCs - Timebase Correctors for analogue videotape - typically a few lines of 4Fsc storage
• Frame Synchronisers - used to time free-running incomming feeds into a studio
• DVEs - typically three frames of storage that would allow you to re-size or at best 'curve' a video signal
• Painting system - only Quantel Paintbox 7001 series at the Beeb but there were others - Spaceward Matisse was the competitor.

Audio - still mostly analogue recorded on 1/4" or 1" 24-track (Studer style). DAT was starting to come in and there was Sony F1 for sending stereo digital audio over a video channel. We also had SIS (Sound in Syncs) - a way of sending digital audio on a video signal. NICAM had just been launched (14-bit, 32Kits/sec companded to 10-bits = 728kbit/sec) - I hadn't heard of audio compression at this point!

Video Cable - at the BBC this was either PSF1/3 or PSF1/2 for long runs; oh, when we expected so little from coax!

Studios - This is a picture of Studio 2 from 1988

Notice the Grass Valley GVG-1600 vision mixer - it's the one you see in Star Wars in the Death Star controlling the destruction of Alderan!

Notice the VT100 terminal at the left hand side of the desk; that was connected to the BASYS newsroom network running on six PDP-11/84s (IIRC) and controlled scripts, the AutoScript prompters and even gave us all email.

The DVE was a Quantel 5000 that occupied a whole equipment bay!

Cameras - they were all tube cameras when I started with the attendant headache calibrating them for a studio shoot and they required two engineers to control them - one for the "racks" (blacks and whites) and one for colour control (referred to in the Beeb as "knobbing" - I did that a lot!). The cameras shown here are a pair of Link 110s from my time at Line Grove. We had Link 125s in TC2 - they were all a nightmare! When I moved to Carlton in 1993 I was amazed how good the Sony BVP-7 CCD cameras were to line-up and control.

I don't have a whole load of photos from the time; we didn't have cell 'phone or digital cameras and I have a feeling it wasn't considered good manners to take photos at work. I do have a picture from 1992 from the big wall of Stage 5 (which was under construction pretty much the whole time I was in News VT maintenance in the Spur).

This wall was subsequently obscured by Stage 6 which was built in the nineties.

In summary there is no other place a trainee engineer could get experience of:

• Studios
• Post Production
• Outside Broadcast
• Telecine
• Transmission

Trainee engineers of 1988!