Not So Flash, By Vidcheck

ITU-R BT 1702 is a specification that I am sure that many of you will be familiar with, albeit perhaps not with this nomenclature because it is often referred to as the OfCom PSE requirements, writes Thomas Dove, CEO, Vidcheck.

These PSE requirements limit changes in brightness, moving patterns, and red images that can be present within video transmitted on UK television. These requirements are non-optional: if your video goes out contravening ITU-R BT 1702 then that is illegal and the penalties can be severe (= expensive).

News bulletins can get around the problem by issuing a 'This report contains flashing images' warning immediately before a suspect sequence, but this is not feasible for most programmes.

PSE stands for photo-sensitive epilepsy: watching video with flashing images and patterns can trigger epilepsy in a small percentage of the population, hence the legal requirement for compliance. Japan has a similar legal requirement, particularly brought about by the prevalence of high contrast cartoon videos.

For those of us in the UK, ITU-R BT 1702 is clear in its definition of PSE triggers but ironically is hard to interpret as it does not necessarily correlate intuitively with video that looks 'flashy'. Also, there is no one-to-one correspondence with parameters that can be easily measured within the editing environment such as video levels.

For example, the specification says that the limit is 3 flashes per second of ± 20 candelas/m² luminance but only when the screen luminance of the darker image is below 160 candelas/m², covering at least 25% of the screen area (20% when the 'strict' limit is applied). I am sure that all you experienced editors out there will immediately be able to spot when the luminance is below 160 candelas/m² and has changed by ± 20 candelas/m² within the given time. No? Nor me.

These 'flashes' could be caused by rapid changes of lighting in a scene or by rapid cuts that cause the screen to flash.

A luminance measurement such as 20 candelas/m² is the amount of light emitted by the display device. So immediately there is a question: why not simply turn down the brightness of your display in the NLE edit bay so, there at least, you won't go above the PSE threshold? Clearly this is not the solution and a 'normal' level of brightness must be assumed for the end–user viewing device.

The accompanying two sets of image sequences are a case in point: the first set shows a few frames from a video which does not comply, where there are repeated flashes as shown in the central image. The corrected video as shown in the second set of images, where the luminance of the flash images has been reduced fractionally, does then comply. (This may be very hard to see, particularly in the printed images.)

As well as luminance changes, ITU-R BT 1702 mandates checks for extended flashing over five seconds, saturated red frames, and potentially harmful regular patterns. The test for harmful regular patterns is particularly difficult as, in some cases, it can be very non-intuitive. For example, there is a standard BBC test clip with a person on a train sitting in front of a window with the scenery flashing by in the background. Because of the speed of movement and the linear patterns generated, this has to be indicated as a PSE failure.

For all these reasons, standard software has been used to measure PSE compliance for many years. There are now three software devices approved for such measurements which will generate a PSE compliance certificate that meets the AS-11 DPP specification and the UK legal requirements, including the software from Vidcheck.

Once the video has been produced and the PSE testing software has generated a report saying what the issues are and when they occur, it is then normally a case of returning the video to the editor to correct the issues. Typically the editor will make a few small tweaks to try and bring the video into legality. The video must then be re-rendered and tested again for compliance. If it fails again, the process must be repeated until compliance is achieved.

Clearly this can be time-consuming and frustrating. Also, in our experience, what often happens after a few times around this correction loop is that the editor gives up trying to make the minimal changes and makes much larger changes than he or she would really like, just to get past this stage. Apart from all the time and expense of this, it means that the video can end up with more of an undesirable editorial/content change just to meet the PSE requirements.

In many cases, 'flashing video' is by far the most important compliance issue as it is the most common, particularly of course in news broadcasts but also in many other programmes. Examples are muzzle flashes from guns, cars going through scenes of rapidly changing sunlight and shade, fast scene cuts, cartoon-like video, rotating fans, flickering neon signs and reflections off moving water.

What is really needed is software that will do the minimum changes necessary to bring the video into compliance, ideally fully automatically and without involving an editor at all.

PSE flashing auto-correction is included as standard in the Vidfixer auto QC software from Vidcheck. It is also now available as an option in the popular Vidchecker auto QC software.

The software intelligently tries various methods of correction of the flashing failures in the video to achieve a PSE pass, making the minimum changes necessary. As the correction methods are highly novel, a patent has been applied for by Vidcheck.

Accepting that this new software will not deal with 100% of PSE failure issues 100% of the time, it does cover the issue for the most part so is well worth having. Let's face it, what software does 100% of what you want, 100% of the time?

www.vidcheck.com