Monday, March 23, 2015

Poor RGB separation in Plasma TVs and poor Barco broadcast monitors!

I spent a day over the weekend at a customer's facility; they are a large production house with a decent number of edit, grade and audio rooms. An old industry pal has recently become the tech manager there and he's trying to get them up to standard. So - I've been in calibrating monitors and he also asked me to give him an assessment of how easily he could LUT their plasmas to get them to Rec.709.
The first observation is how bad Barco broadcast displays have become! I was very used to them in the eighties at the BBC but the RHDM-2301 is a sorry excuse for a TV monitor.  The marketing material say; 
The RHDM-2301P is the perfect reference monitor for Directors of Photography (DoP) on set during film acquisition, as well as for dailies processing. The Grade-1 color accuracy and stability means that two RHDM-2310P monitors will show identical pictures even on two distant sets.
Which might be the case, but the problem is that they only give you access to adjust the white-point of the monitor (which on these two were both wrong AND different; one was a tad blue, the other a tad red) - the menu tells you what the CIE 1931 color space chromaticity coordinates of D65 are, namely x=0.3127, y=0.3290 but the monitor is not kicking out that colour - it was a bit blue in the white; around x=0.3045 and y=0.3315! This is why monitors tell you what RGB values they are driving and you measure and make the display correct using the x,y,Y values off you photometer or spectralradiometer. For them to tell you what the white point is in terms of x & y and them be wrong is monstrous! They do allow you to tweak the x & y but only in the whites; the monitor is also incorrect in the blacks; greyscale tracking is wrong!
It's also kinda pointless for them to tell you the values of the primaries as well! They can't be adjusted.
So - rant about Barcos over, here are some test results for the cheaper Panasonic 32" plasmas they also had;

Using LightSpace I profiled the display. You can see the gamut of the TV is bigger than Rec.709. The other worry is how bad the RGB separation is. However; after taking a 17-point profile (around 5000 colours) the software reports better than 100% compliance. Good news!

This is the resulting LUT cube and you can see 709 is entirely contained. There are no tightly packed points anywhere indicating a LUT will make things better.

So, loading the cube into our ISmini LUT box and re-running;

Friday, March 20, 2015

Reliable Avid ethernet traffic over old fibres

The first Avid Unity fibre-channel SAN I installed was in 1999 and fibre was the standard for high-speed shared storage for editing for more than a decade. However; since the introduction of MPEG4-based editing codecs which allowed Avid to offer high quality DNxHD we've been all about ethernet-attached shared storage; in Avid's case the ISIS storage products.

We have had a lots of customers who went to the expense of running OM3 (50 micron multi-mode fibre) cable only a few years ago and are now cheesed-off that they need to flood their facility with cat6 or 7 because the rough-old cat5e they have doesn't work reliably for gigabit. So; the obvious choice is to use that fibre which had bags of bandwidth for ethernet but until very recently that was not an approved configuration by Avid. Recently they have tested Allied Telesis media converters and given a cautious thumbs-up. BUT, they are very expensive (a few hundred quid per workstation, so back to running new cable), but I had a quick chat with the guys at Comtec about the house-brand they supply which uses the same chipset.

Neal Kemsley kindly ran Avid's PathDiag tool before and after and these little cheapies seem entirely transparent. Here's what he fed back to me;

"Windows ISIS client attached directly to a Dell N3048 switch running Pathdiag in an “Unlimited” Writes then Read PathDiag test cycle targeting an ISIS Workspace (the term used by Avid for their storage volume – the same as Unity). Unlimited means that the test attempts to saturate the channel between the ISIS client and is a good indicator of the upper limits of the potential connection between the client and the storage. In this case it is a 1 Gbit copper connection to the switch, and an optical 10 Gbit connection between the switch and three ISIS 5500 storage chassis. As you can see we are getting a result north of 100 MBs per second – yes that is MegaBytes – not bad for a 1 Gbit path! (Not too shabby as they say in Boston!)"

"This one shows the same test parameters but with the client attached to the switch using the media converter pair in circuit. Note that the test results are really similar perhaps with some minor variation in the upper reaches of the test during the write cycle but nothing serious. The overall speeds achieved during the tests are essentially the same as a direct connection and there are no errors displayed.
Note that the graph pattern drawn by the test is relatively clean showing very little spiking or variation and clean transitions between the Write tests and the Read test cycle. Note also that no errors are seen in the error count on the right side."

"We would want to run the test for several hours to draw conclusions on this but these results are very promising. We would probably want to also change the Transfer Size parameter of the test up and down to emulate different editor timeline characteristics. Smaller values are used to emulate working with heavily compressed material, the current setting being used to emulate working with DNxHD material, and larger values can be selected to emulate working with uncompressed HD and UHD material."

"To emulate working with several streams of data in a timeline this shows four independent PathDiag test sessions running simultaneously with the Media Converters in circuit. In this case rather than working with unlimited tests, I set the Transfer Rate parameter to 25 MB/sec and allowed the tests to cycle for 30 minutes. Notice for results graphed in these tests the individual tests are interacting somewhat – see that the top value levels are becoming choppy and castelated somewhat as each test competes for throughput. Since the tests in aggregate are pushing the maximum limit of the channel (if all four tests happen to be writing or reading simultaneously, the overall write or read bandwidth should around 100 MB/sec) this interaction is quite normal and will get worse if similar test were being run on further clients in the ISIS environment as each client competes for access to the storage."