Category Archives: Vista Systems

ScreenMaster III 3216 Console

ScreenMaster III 3216 – Restoring a Classic – Part I

The ScreenMaster III 3216 and it’s half-sized little sibling the 1608 were some of my favorite consoles every made at Vista Control Systems (later renamed to Vista Systems and later acquired by Christie Digital). These were the first consoles to incorporate 15″ touch screen displays to compliment the massive button boards from prior console generations. This console, like others before it, were purpose built to control a combination of Folsom (now Barco) VFC-2200 scalers and either Extron, Pesa, or Sierra routing switchers. We’re talking analog video only here – this was the nineties after all, when 1080p video was king.

It’s worth a note that this console would be appear again in the future as the control surface for the Vista Montage video processor, painted in blue and re-dubbed as the Montage SC-3200 console. This stuff is all but lost in time, even on the internet these days, and so I’ve included a picture below for full historic reference.

Let’s talk about this got started

Let’s talk about eBay. eBay is a great place to get great deals, and is a great place to troll late nights when you can’t sleep to find stuff you didn’t know you needed (and probably don’t need). One night I happen to be aimlessly looking around the internet, and somehow I made it to this posting on eBay:

This picture of the console immediately gave me ‘the feels’, as it has solid sentimental value. I remember shipping the first of these consoles, sometime back in the nineties. We had a problem with a driver for an internal USB network adapter, and it was causing the console to bluescreen. We weren’t sure it was fixed, but I ‘thought’ I had resolved the issue with an updated driver. We got the console in it’s case and brought it to the back door. After talking a bit about this bluescreen, Jeff Wilson and I opened the console up and made sure it booted successfully five times. As long as it could boot five times in a row, then we’d ship it. Good news – that was the day unit #1 shipped.

<rant>Just to touch briefly on that last point – this was a time when Windows was considered to be generally unstable, and we caught a lot of flack from rental and staging customers (and competitors). Here we were though, shipping a device with Windows (NT Embedded I vaguely recall) and asking customers to entrust their high-dollar live events on it. Software bugs aside, I think this ask proved to be a reasonable one and these consoles were way ahead of their time (my opinion). </rant>

So this console on eBay had an asking price of $599, and I sent an offer for $299 which was accepted. I don’t remember the real figure, but I think this console cost around $45,000 new. From the pictures I could see some button-board activity and a boot failure, and so I knew that (1) the embedded part of the console was alive and (2) the PC was ‘alive’ and the Compact Flash card we used for the hard drive had likely failed. After some back-and-forth on the shipping, we decided to drop the shipping case to avoid going freight, and all-in I think I was down $500.

The arrival

It took about a week for my console to arrive, and it showed up packed tight with instant-foam in a box that must have had a roll of fiber tape for additional support. It took a solid hour to practically chisel the console out of this foam tomb, but it shipped in pristine condition so I can’t complain.

After getting the console freed from it’s shipping cocoon, I gave it a good look over and powered it up. The screen showed the same hard drive failure message that I saw on the eBay post. The quick-keys (the top-right green button array) showed diagnostic counters that I was able to use to verify that the buttons, joystick, T-bar, and rotary encoders were all functional (minus a few burnt-out incandescent switch lamps). So far so good. Next up is to take inventory of the computer hardware and try to get it working again, but before we move on go ahead and take a hard look at that good-looking piece of hardware ūüôā .

Console internals

When you open the bottom of this console, you immediately see that there is a LOT going on. Luckily, when we look closely at the internals of the console there are two main subsystems – the embedded computer (PC) and the physical control interface (buttons / T-Bar / Joystick) subsystem. The picture below shows the console on it’s side with the bottom removed.

The application board is the main embedded component which houses the programming required to read and write the physical hardware. Luckily for us, the interface between the embedded computer and this application board is Ethernet. It’s difficult to see in the pictures, but there is an Ethernet crossover cable between a second Ethernet port on the SBC and the application board. This is great, because it means that we can upgrade the embedded computer without worrying about obscure hardware interface dependencies.

Before we move on to replacing the embedding computer, let’s take a second to talk about the embedded computer that came with the console. This was an EBX form factor computer called the ‘Olympus’ and was manufactured by Arcom Controls (datasheet here). This was a 1.0 Ghz Celeron processor and 128MB of RAM. The hard drive was provided with a 128MB Compact Flash card, which has limited read/write cycles and almost certainly explains why the console eventually stopped working. I did try jump-starting the console with a new Compact Flash module, but the SBC was so old that it felt that even if I could run a modern operating system on it (unlikely) that it would be terribly slow. It was also sporting a 3.5″ floppy disk drive, for those of you who remember what that even is, and I knew that needed to be brought into the modern age as well. With that back-story out of the way, let’s get to upgrading.

Upgrading the Embedded Computer Hardware

Full disclosure here – this console sat on it’s side in my living room for several weeks, and I’d give it occasional blocks of evening and weekend time. This wasn’t particularly hard, but there were some time-consuming parts of the effort that I’ll bullet point rather than writing a book about:

  • Removed the prior EBX form-factor PC board and graphics adapter
  • Removed the existing floppy disk drive
  • Drilled holes in the chassis to fit a new Mini-ITX form factor PC
  • Bought a +12V to ATX power adapter module to power the new SBC
  • Added two USB to RS-232 cables to drive the touch screens
  • Added a USB to Analog adapter to drive the second touch screen (the SBC had one VGA port I was able to use as well)
  • Replaced the Neutrik Ethernet connector running to the back of the console with a new one
  • Modeled and 3D Printed a custom bracket to hold a new Solid State hard disk and expose 2x USB 3.0 ports to fit in the old floppy disk drive spot.

The mounting and retro-fitting of the new SBC and parts was a pain, but I’m pretty happy with how it came out. This thing feels like it could travel and be as reliable as the original console was. I am particularly proud of the 3D printed module that I made to hold the hard drive and expose a couple USB ports, and you can see this along with a bunch of other build pictures below

After the aforementioned evenings and weekends spanning may weeks, the hardware for the console was done. It was now sporting an Intel i7 processor with 16GB RAM and a 512GB solid state disk, and was running quite nicely. I did sneak in a picture of installing Windows on the replacement Embedded PC / Single Board Computer (SBC), but I’ve saved this for the last section of this post.

Let’s put Windows 10 on this thing

A modern console needs a modern operating system. I actually considered installing Ubuntu Linux for the fun factor, however ultimately I decided to install Windows 10 Pro. It’s less ’embedded’, but it allows for wider flexibility for software to run (including Vista Advanced / Spyder Studio / Spyder Client software).

One wrinkle that I did run into was around the touch screens. They have RS-232 serial controllers, and the native 3M driver didn’t work. I remember running into this with my Car computer touch screen (same hardware), and so I knew I needed to pony up and buy a license for a software called touch-base that makes the touch controllers work with Windows 10. Related note – the screens for the console are each 1024×768 resolution and VGA, and if I were braver I would crack open the top and try to replace them with some newer displays. Maybe someday.

Big reveal time

I don’t need a lot of words for this – I’ll let the pictures of the console working speak for themselves. For those curious, the pretty looking Spyder control software is the Spyder Client application that is available on the Windows 8/10 Store.

So where are we, and what’s next?

So we have a large powerful hardware console alive and well, and we have a working PC operating system on it. Probably a way over-powered PC in there hardware spec-wise, but we still don’t know what we’ll do with it so hard to say. By the time I write this, the console has actually been sitting in my dining room for the past two months. I’ve already done some development and created a software interface to integrate the hardware with the PC, but I’ll save that for a future blog post.

In the next post, I’ll talk about how the PC-to-embedded hardware interface works, and we’ll probably have a simple app to show take a look at. I expect the next post will be a bit shorter – this one was a monster and it feels like it just skims the surface. With that, thank you for reading and see you next time!

Building a Camera Tally Controller for Spyder

Over this past¬†weekend I set out to create a camera tally device for the Spyder video processor.¬† Specifically, I wanted to try to¬†use¬†my relatively new Raspberry Pi 2 board running¬†the Windows 10 IoT¬†Core operating system to make something useful.¬† If you’ve read through my older blog posts, you’ve likely noticed that the Spyder is still my go-to target platform for playing with new technologies.¬† Let’s face it – when you’re playing with shiny new toys, it helps to mate it up with something you know very well so you don’t feel completely lost.¬† Before I get into the details, check out this brief video showing¬†a¬†working¬†tally controller in action:

The whole process of building this device was simply fantastic.  The barrier to entry for people making hardware devices has gotten incredibly low over the past couple years, both from a cost and ease of development perspective.  The whole build process was very quick, and I had such a great time with it that I went ahead and put together a full 30 minute hardware and software video walk-thru for the project (more on this below).

Getting Started Making your own

To get started making your own, here are a couple links for the main hardware used on this project, as well as the wiring diagram for your reference.

Raspberry Pi 2 Kit ($70):  Amazon Link
8-Channel Relay Board ($9):  Amazon Link

Tally Wiring Diagram

Hardware Wiring Diagram for our Tally Controller

Links to the full¬†source code, documentation resources, and a full YouTube walk-thru video are below.¬† This video has a ton of valuable information in there, covering the hardware specifics, Spyder implementation details, and the full process of creating our software application.¬† This is the first time I’ve gone through and made something this elaborate (and narrated the video), and I’ll be very interested to know what you think of it (so leave me a comment below if you’re so inclined).

GitHub Project (Source Code and Documentation):  Click Here

Next Steps

The tally controller we’ve created is certainly functional. but in it’s initial form the server IP address and tally source lists are hard-coded.¬† In the next stage of this project, we’re going to build a desktop application that can connect to the device remotely over the network and view/configure these properties.¬† We’ll also explore creating a user interface to run on the Pi’s HDMI output, which could be useful for monitoring and troubleshooting the device.

Until next time, take a look through those walk-thru video and the resources in the Github repository, and try to make one yourself.  I hope you enjoy going through this content as much as I enjoyed making it.

Spyder Client for Windows 8.1 – Live Control

One of my favorite areas working on in the Spyder Client for Windows 8.1 was the live view, which not only shows a real-time¬†visualization of the Spyder server’s PixelSpaces, but allows for live interaction and command key creation. While it’s not necessarily new, I thought it would be fun to create a Camtasia video showcasing the live control available from the Spyder Client.¬† I certainly enjoyed making it, and I hope you enjoy watching it (and using it).

Under the Hood – Leveraging Spyder’s External Control

Internally, the Spyder Client uses¬†the Spyder¬†server’s¬†publicly accessible external control protocol for all control actions performed¬†by the application.¬† This is for a few reasons, one of the more notable of which is that¬†Windows Store applications do not¬†support .Net Remoting (which is¬†how the Vista Advanced client communicates to Spyder).¬†¬†¬†If your curious how¬†the¬†Spyder Client is¬†doing something you can simply check out the Spyder server’s logs to see what commands are being executed (see screenshot below).¬† Just make sure to set the server tracing level to information or success so that the command logs actually appear.¬† Of course, if you have a specific question, feel free to leave a comment under this blog post.¬† I’m always happy to help out a fellow coder.

Viewing remote server logs in Vista Advanced

Viewing remote server logs in Vista Advanced

Just in case you don’t already know, the external control protocol documentation is included with the installation of the Vista Advanced client software. If you have Advanced installed, then the external control protocol PDF document is already available from your start menu.

First App in the Windows Store (Yes it’s another Spyder Client)

Historically, when I’m taking a new platform or development tool out for a spin, I end up creating a control client for Spyder.¬† It’s nice to be able to work against a well-known and well-understood platform, so you can focus on the new and exciting stuff.¬† In this case, which is no exception, I fired up a Windows Store application targeting the Windows 8.1 platform.¬† In all truth, I think I started this about 5 months ago, however the project didn’t make real traction until the week of Christmas this year (which I took off from work).¬† I put forth a hard goal of getting the application into the store by the end of that week, in hopes that I wouldn’t aimlessly squander away my week at home.¬† At the end of the week, a new application had indeed been introduced to the store, and while it’s pretty ‘fresh’ I’m proud¬†of the results so far.

Check out the app’s official page on this site here

Check out the app and download it from the Windows Store here

Feature Set on Day One (What’s there and what isn’t)

Getting something into the store on a compressed timeline is tricky, and there are always a lot of features that get dropped.¬† I’ve been reading The Lean Startup, and one of the concepts reiterated regularly is the concept of getting something out there early to collect feedback to iterate against.¬† Waiting too long for something to be perfect (which isn’t a real thing) means that you can spend an inordinate amount of time working on features that people don’t care about.¬† This is pure waste, and in a project like this where all development is happening in my free time, there simply isn’t time for waste.¬† All that being said, here are the features as they exist on day one, and my current view of where they could go in the future.

Note that this is my list, and I’m providing it to you in hopes of hearing some of your feedback.¬† Tell me what is and isn’t important to you, and together we’ll be able to make this app better.

Main Screen

 

Home Screen

The main screen is the landing page for the application when opened, and displays all servers available on the network, each with a thumbnail sized live view and launch buttons to command keys, function keys, and still image pages.¬† The functionality is pretty straight forward, so I won’t list out what is there in more detail here, but there are a few things that I would really like to see go into a near future version of the application:

Planned Main Screen / General App Features

  • View of system health / user diagnostics¬†(with launch button to a health screen)
  • Ability to select any of the buttons and open their associated pages in a new window, allowing multiple views to be displayed simultaneously.¬† This could be a big deal for multi-monitor users, and opens up more complex control and monitoring scenarios for even single monitor users.
  • Sources view / list, showing thumbnails and tally status.¬† Used in combination with the previous feature bullet, this could allow for drag-drop support onto the live view

Live View

Spyder Client - Live View

This is effectively a display simulator view, designed to give a real-time view of the system’s PixelSpaces and layers using thumbnails pre-configured in Spyder.¬† Creating a full-featured simulator¬†brings a number of complexities, and this control is very primitive by the standards of the simulator in Vista Advanced.¬† The live view control will undoubtedly be the benefactor or the majority of near¬†future development work as a result, and to get the most bang for the buck I’ve re-used this same control to provide thumbnail visualizations for command keys and the thumbnail view on the main page.

Live View Features on Day One

  • Preview / Program PixelSpaces
  • Solid Color Borders with bezel luminance offsets
  • Thumbnails for PixelSpaces and Layers
  • Smooth motion views of layers and background transitions

Planned Live View Features

  • Full bitmap borders and shadows
  • PixelSpace Stackups (different view configurations for PixelSpaces)
  • Layer number indicators
  • Interactive control¬†(layer pinch resize, reposition support)
  • Drag/Drop support for sources / stills

Command Keys View

Command Keys

The live thumbnail view within the command keys page is (in my humble opinion) the most interesting feature within the application.¬† This works extremely well at showing what-if scenarios for recalling relative command keys, but is very limited today by the general render capabilities of the live view control used to¬†generate thumbnails.¬† I don’t think I can understate this; the renderer is pretty feature light and falls down quickly when showing more than the most basic of looks.¬† As stated previously though, this will gain all the development benefit of work applied to the live view, and so I think it’s only a matter of time for this to get flushed out.

Command Key Features on Day One

  • Displays user defined register colors for command keys
  • Groups buttons by existing user defined pages
  • Live generated preview of ‘Program’ (Cue 1)¬†look for command key
  • Absolute / Relative Indicator
  • Preview / Program tally indicators

Planned Command Keys Features

  • PixelSpace stackup switching
  • Ability to turn off live view integration with thumbnail previews.¬†¬†Not sure if anyone would actually want this feature¬†– seems to me like once you have a feature like this you would never want to turn it off (would love your feedback)
  • Option for different button sizes to condense more command keys onto the screen
  • Pinch zoom support to jump between pages quickly
  • 320 pixel wide snap view support
  • Link to a full script grid view showing all command key cues with individual thumbnail previews.¬† I have a lot of thought into this, and will probably need a blog post all it’s own to describe further.

Stills View

Stills Viewer

The stills view came about early on as a side effect of needing to¬†validate the¬†image file processor / transport software, but was handy enough to keep around.¬† The¬†Advanced client has¬†the ability to¬†obtain thumbnails from the server in a round about way (once you’ve seen them in the simulator they are cached locally in¬†the ‘C:\Spyder\Images’ folder on your PC).

Stills View Features on Day One

  • View all Still images defined in the Still registers list on the Spyder server in thumbnail form
  • View a full screen view of all images by clicking a thumbnail
  • Ability to save image files locally via the app bar
  • Ability to share one or more selected images using the ‘Share’ charm in windows

Planned Stills View Features

  • Native shape file viewer (custom bitmap border shapes)
  • Native shape file creator, with the ability to simply draw a shape on screen and have it saved onto the Spyder server as a shape file.¬† This would have the ability to load an image into the background to be used as a stencil, and additionally preview the resulting shape at a number of different source aspect ratios.
  • Different thumbnail sizes to show more thumbnails on the screen at once

Function Keys View

Function Keys

I think the Function Keys view is off to a good start; it works (which helps), and it’s approach of showing a very brief text description of it’s execution action makes it easy to see what the button will do before you actually press it.¬† An interesting note about function keys:¬† the Spyder data model actually has support for custom register colors for function keys, but this is not brought forward into the Vista Advanced interface.¬†¬†The Spyder client has support for¬†displaying custom register colors as it does in the command keys view, and so this¬†will auto-magically start working if this becomes implemented in Advanced in the future.

Function Key View Features on Day One

  • Display of Function key names
  • Display of the type of command key
  • Short text describing the action which will be performed when the key is executed (limited to one line of text, may be clipped depending on things like the number of layers affected)

Planned Function Key View Features

  • A pseudo-tally feature which would evaluate the state of the system and show a red tally indicator if the function key appeared to be in it’s executed state.¬† An assign source function key, for example, would show a program tally indicator if it’s associated source was already assigned to it’s target layer(s)
  • Relative layer recall support.¬† Function keys with relative layer/device assignments require the layer/device IDs to be specified at the time of recall, and currently there is no way to¬†provide these when¬†executing a relative function key from the Spyder client.
  • Option for¬†a more¬†compact view of buttons to display more function keys on the screen at once
  • Pinch zoom to quickly navigate between pages

Again, the planned features are on my wish list based on what I think would be great additions.¬† It’s entirely possible that I’m missing the boat on functionality that I’m just not thinking about, and if you think that’s the case then I’d like to hear from you.¬† Please leave your comments on this post, and in general let me know what you think of the app.

In a future post I’ll talk about the back-end development, project management, and source control technologies, and possible future directions for the platform.

 

Vista Advanced broken (and fixed) when running high DPI displays

I recently became the proud owner of a Microsoft Surface PRO device, and was shocked to see that our main software application Vista Advanced looked absolutely horrible!  It felt like half of the UI was tiny, and the other half was massive in size.  The Splash screen graphic was even bad, having been drawn in a tiled display.  Take a look at this first-run / out-of-box experience on the surface running the latest release (4.0.1 at the time of this writing):

Splash screen background image wrapping

Splash screen background image wrapping

Oversized controls and UI elements make the app usability pretty rough

Oversized controls and UI elements make the app usability pretty rough

The Problem

The problem, it turns out, has to do with the application’s UI frameworks detecting the selected resize mode for the OS (set to 150% scale by default on high DPI devices like the Surface PRO), and scales up the bitmaps and fonts accordingly.¬† The really annoying part is that only some of the UI elements are affected by this, and this is due to a combination of different technologies and control libraries being used together to put Advanced together.

The Workaround (read: Hack)

There is a work-around to allow existing versions of Vista Advanced software to look normal on your high DPI device, and the way to do this is to open display resolution in control panel and look for the link that says ‘Make text and other items larger or smaller’.¬† That link will bring you to the dialog below, and from this dialog set the size of¬†all items to 100% (Smaller).¬† This affects the entire OS, and has the additional requirement of needing¬†you to log out and back in before the setting will take effect.¬† ¬†This is certainly far from ideal, but in a pinch it’ll at least get you by.

Use display settings to change the default size of items to 100%

Use display settings to change the default size of items to 100%

The Real Fix

Modification to AssemblyInfo.cs to disable DPI awareness

Modification to AssemblyInfo.cs to disable DPI awareness

Luckily there is a simple software fix for this problem that we were able to put in place.¬†Inserting the DisableDpiAwareness attribute at the¬†main application’s assembly level will disable the DPI scaling that happens on these high DPI devices, causing¬†our application to render the same size on all computers.¬† Setting this attribute immediately brings the application back into it’s normal look and feel:

Normal looking splash screen after setting DisableDpiAwareness

Normal looking splash screen after setting DisableDpiAwareness

Normal Advanced application look after setting DisableDpiAwareness attribute

Normal Advanced application look after setting DisableDpiAwareness attribute

Now with this fix, you can see Advanced looks as one might expect it to look again, and without the user having to make any screen resolution hacks to do it.¬† You’ll see this fix in the next beta version of software (0.55.8), which will roll into version 4.0.2 for those of you who wait for release builds only.

Simple Spyder Preset Recall App for Windows 7 and 8

Back at NAB this year,¬†Vista used¬†a Microsoft Surface PRO device as a free-standing touch screen running a custom¬†application¬†to recall Spyder command keys.¬† A number of people asked about obtaining a copy of this interface during the show, citing it’s ease of use and¬†simple functionality¬†as a common¬†use case¬†that¬†can be found¬†across several environments.¬† I worked on this application in my free time leading up to the show, and as it stands this isn’t something that will be formally productized.¬† It’s a great application for what it does, and as such,¬†I’m making¬†this application available¬†here for those who want it.

Quick screenshot of the preset recall app in action

Quick screenshot of the preset recall app in action

Now for the quick description:¬† this¬†is a full-screen desktop application which leverages the Windows 8 Metro design philosophy¬†for a modern look.¬† The app¬†auto-discovers Spyder servers¬†on the network and allows them to be selected in a drop-down (top-right of the screen).¬† Upon selecting a server, it’s command key¬†pages and associated command keys are displayed.¬† The command key buttons are greatly oversized, optimizing them for touch-screen scenarios.¬† A single¬†press of these buttons will recall the program cue of it’s associated command key, and active command key buttons will be displayed in red (take a look at the¬†screenshot above).

If you have any questions or issues getting running, feel free to post a message on the blog here.  It takes zero configuration to get running (other than getting your client PC on the same subnet as a Spyder), and as of this writing has no known issues.  Give it a spin, enjoy, and let me know what you think!

Download the Spyder Preset Recall Application Now

Note:  This application requires the installation of the Microsoft .Net 4.5 Framework

Bitmap Borders and Shadows: Part 2 of n

In the first part of this series of posts I discussed how to use the bitmap border / shadow feature on Spyder X20 and how it works under the hood.  In this post, I‚Äôm going to discuss the process for creating custom shapes and getting them loaded into the X20 video processor.  You might want to create custom shapes for any number of reasons, a common one being for corporate logos.  Below are a few examples of custom shapes I‚Äôve generated for the sales team for various demos over time.

CNN_Logo 
DVD player video cut into CNN logo
Shards 
Another DVD player cut into shards

So How is a Shape Defined?

The bitmap border / shadow engine uses a XAML (eXtensible Markup Language)  parser to convert a vector-based shape definition into the specially formatted raster-based image that is loaded to the video processor hardware.  The shape definition is imported into the system as a .shape file, which contains a single XAML PathGeometry definition. Below is the contents of a shape file defining one of the ‚Äėshard‚Äô shapes above:

<PathGeometry
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Figures="M 100,0L 62.75,0L 51.75,24.3333L 
     65.9166,24.3333L 66.25,45.3333L 75.75,30.5L
     5.5833,62.3333L 92.5833,75.5L  100,75.8333L 100,0 Z "/>

The real meat of the shape definition is defined in the Figures section of a PathGeometry object, which is written in a mini path syntax.  In practice you‚Äôll be copying and pasting this data out of a tool like Microsoft Expression Design, but in case your curious there are several pages online that describe the XAML path mini-language (one here) that you can peruse in your free time if your curious to know more about how this syntax works.

Tools of the Trade

There are many tools capable of generating XAML output, but my personal preference is Microsoft‚Äôs Expression Design tool.  You can download a 60-day free trial of this tool on Microsoft‚Äôs site (here).

You‚Äôll also want to have a basic template file that you can paste your custom shape data into.  You can pull this off my site here.

OK I have the Tools, now what?

The steps involved are easier to show than describe, and so I created a video walkthrough showing the process of creating a custom shape with Expression Design, saving it into a .shape file, and then finally importing that shape into Spyder using Vista Advanced.  The walkthrough moves pretty fast; if you have any questions just leave a comment on this blog post for me and I‚Äôll try my best to help.

 

Summary

So hopefully this post has helped explain the basics of creating custom shapes for your X20 system.  In the next post I‚Äôll spend some more time building custom shapes and logos in Expression Design, and I‚Äôll cover a few tips and tricks I‚Äôve found to make the process more efficient.

Bitmap Borders and Shadows: Part 1 of n

In this next series of posts, I‚Äôm going to discuss the bitmap borders and shadows (BBS) feature that first appeared in Vista Advanced 3.5.0.  If you haven‚Äôt played with them yet, you owe it to yourself to do so. 

This first blog post will discuss how (and when) you can use the feature, how it works under the covers, and how to get the best possible performance from it.  If you have no idea what the bitmap borders and shadows feature is, take a look at the action shot below.

358

The image above shows two related features, bitmap borders and shadows and window titling.  I‚Äôm going to skip over titling for this post, and concentrate only on the bitmap border / shadow feature.

What Can I do With Bitmap Borders?

Bitmap borders goes beyond the traditional supported borders to enable custom shapes and fills to be defined.  Shadows applied will keep the same shape as the bitmap border, and can even have a color other than black defined (not shown).

one layer

Features Shown:

  1. Non-Rectangular window (rounded edges in this example)
  2. Image file used as border texture
  3. Shadow shape that matches the border shape

The Spyder software comes with about a dozen border shapes that you can use, as well as a number of images that can be used to texture the border.  Of course you can create and use custom shapes and fill images, which I‚Äôll be discussing in detail in the next blog post.

The KeyFrame property panel contains handles for all of the available bitmap border and shadow adjustments, and I‚Äôve included a few screenshots of the most interesting ones below.  Using them is pretty self explanatory, and so I won‚Äôt bother going through them exhaustively.

border settings border texture border shape
General Settings Border Texture Border Shape

 

So How Does It Work?

Under the covers, the border / shadow settings selected are used to generate a specially formatted image at a size relative to the input video resolution, which gets loaded once into the target layer where it is in turn merged with the video each frame. The Images below show this process.

Example - Source Video Frame Buffer (2048×1200)

In this frame buffer, the active video is repositioned so that it will fit correctly when merged with the border image loaded.  These offsets are programmed by the server as part of the image loading process

Example - Border Bitmap  Buffer (2048×1200)

This buffer stores the generated image which will be merged with the video.  Special bit values are encoded into the image to specify what area of the image should be mixed with the video and which area should be mixed with the VI.

Example - Both Resulting Image

Once the image is loaded, the hardware in the X20 layer will perform the video cutout and merge the image with the border on a frame-by-frame basis.

Note that the image sequence above makes a point to call out the frame buffer sizes in the layer hardware; a size of 2048×1200.  This is important because the generated image file previously mentioned needs to fit within these dimensions.  Since the image file must be loaded relative to the input video resolution, there may not be enough ‚Äėfree‚Äô frame buffer space to generate the desired effect. 

In cases where there isn’t enough space to fit the requested bitmap border / shadow settings, the server will automatically scale back the border offset and then the border thickness until the image fits.

Also note that the image files generated can be relatively large, and in almost all cases you really need to be running a still server to ensure a good experience.  While technically the bitmap borders will work when using traditional USB loading, the image load times detract much of the experience.  There is additional information on the still server on the Vista forum site, and I‚Äôve additionally just completed a post describing the still server here.

Where Bitmap Borders Won’t Work

There are a few scenarios where bitmap border functionality isn’t available, and this section attempts to list them all to save you from surprises in the field.

  • Input Resolutions above 2048 wide OR 1200 high.  This causes the layers to enter a special mode that uses two layer frame buffers, and there is no bitmap border support when in this mode.

  • Running a VI height above 1850.  When your running a VI at a height above 1850, certain layers cannot support still images, effectively disabling bitmap borders.

Tips for Getting the Best Experience

While certainly not required, the recommendations presented here are sure to be extremely beneficial for anyone using the bitmap border / shadow feature set.

Use a Still Server

I know I mentioned this already once in this post, but it can‚Äôt possibly be stressed enough.  If your using bitmap borders and shadows (or stills for that matter), then plunk down a few hundred bucks and buy a PC to hook up to your X20 for use as a still server.  The speed performance improvement when using this accessory can easily be over 10x. 

Build Treatments to Recall Bitmap Border Settings

Using treatments is good practice in general, but the load times involved with adjusting bitmap borders and shadows make it an even more beneficial practice.  Instead of manually adjusting KeyFrame parameters each time you want to setup a bitmap border, just make a treatment for the looks you use most frequently (border / shadow treatment settings include bitmap border options).  Not only does this clean up the workflow for the operator, the on-screen experience is nicer since the system will use the smooth go processor to automatically pull the layer off screen while loading the border.

Summary

I always like knowing how things work under the hood, and if your like me then hopefully this has shed a little light on how the bitmap border and shadow feature works.  In the next post, I‚Äôm going to discuss how you can create your own custom border shapes and use them with the Spyder X20.

Using a Still Server with Spyder X20

While the still server has been a supported option for Spyder X20 and URS since the initial product release, I‚Äôm still surprised to see the number of people who either aren‚Äôt aware of it or don‚Äôt understand it‚Äôs usefulness.  Since it‚Äôs usage is essentially a core requirement when using the bitmap border and shadow features I‚Äôm planning to blog about shortly, I figured I‚Äôd provide a thorough explanation of what it is, how it works, and why you should care.

Traditional Image Loading (No Still Server)

First a little history lesson:  In a traditional scenario where a still server is not in use, images are transferred from the internal X20 computer to the hardware using an internal USB 2.0 hardware link.  This link is fairly slow, and depending on the size of the image being loaded there may be a delay of several seconds to complete a transfer to a hardware input or output frame buffer.  Note that this is the method used on the Spyder 200/300 series systems.  The image below shows a high-level overview of this process. 

image
Figure 1: Image loading without a still server

This approach has a few disadvantages.  As mentioned previously, the image load time can be substantial (over a minute in the case of backgrounds).  Under the covers on the server, there is a substantial amount of CPU and memory being consumed to process and stream the image out to the hardware.  The resulting effect during periods of moderate to heavy still usage can be characterized as a noticeably sluggish ‚Äėfeel‚Äô to the system.

Enhanced Image Loading (Enter the Still Server)

When the Spyder X20 was designed, a special DVI-D input connector was added to the output board which is labeled ‚ÄėOpMon Input‚Äô (yes the name is incredibly misleading), which allows us to increase still loading speed by relying on an external PC connection.  This external PC, typically referred to as a Still Image Server, runs a special application that connects to the existing Spyder network and listens for requests to display image files. 

image
Figure 2: Still Server Network / Video Wiring Diagram

When configured to use a still server, the Spyder X20 / URS server will offload the image loading instruction to the still server, and then simply instruct the hardware to do a frame capture of the image on the OpMon input and transfer the image into the target input / output frame buffer (see sequence below).

image
Figure 3: Image loading using a still server

This has a number of benefits, the largest of which is the raw speed increase when loading images.  The other big side effect is the reduction in CPU and memory usage on the X20 server, since the ‚Äėheavy lifting‚Äô gets moved off to the still server PC and the X20 hardware.

The description above about how the still server works has been  oversimplified, and there are a number of tricks employed to handle edge cases; scenarios like images with alpha channels being being captured, or where the image is larger than the still server‚Äôs output resolution.  Be assured, these are supported scenarios that still reap huge benefits from the still server.

What Scenarios Benefit from a Still Server?

In short, pretty much any operation in an X20 / URS system that loads a still image to a layer or an output will see a large benefit from using the still server.  Below is an exhaustive list, which might contain a few you may not have considered:

  • – Backgrounds (HUGE performance boost)
  • – Stills on layers
  • – Test Patterns (layers / outputs / PixelSpaces)
  • – Bitmap Borders / Shadows
  • – Window Titling
  • – SourceMonitor overlays

Performance Tips

Use a Gigabit network

When using that still server, keep in mind that image files are transferred from the X20 / URS server over the network, and so you can get an additional boost from the still server when your using a Gigabit network for communication.

Use a still server PC with a decent graphics card

While the still server application isn‚Äôt a particularly demanding application, it is a graphics application that will take advantage of hardware acceleration where it can.  If your out looking for a new PC to run as your still server, look for something with a decent ATI or NVidia (preferred) graphics card.  If the PC your looking at has one of those Intel Extreme Graphics chipsets, keep looking‚Ķ

Summary

For many scenarios, the still server is a must-have accessory for the X20 / URS system, and considering the low cost of PC hardware there really isn‚Äôt a good reason not to have one.  If your not already using one, do your self a favor and get one. 

X20 Blend Loading Improvements

With the upcoming Vista Advanced 3.3.1 software, we‚Äôve made big improvements to both the blend loading time and the user experience when working with the blend controls in the UI.  The X20 blending and black level is achieved by loading a 32-bit bitmap image onto each output, which is essentially layered over the top of the output video.  Using internal USB image transfer, the load time associated with each blend or black level change can be several seconds.  A still server reduces the load time substantially, however you can see in the figure below that we were able to beat even the still server time.

Blend Load Times

In cases where only left and/or right blends are enabled (which is all cases currently since Spyder and Spyder X20 don‚Äôt support vertical blending) each line of the still server image is identical.  Since the majority of the time penalty in loading blends was at the image transfer, we opted to write only the first line of the blend to hardware, and enable a new mode in firmware that would cause that line to be written to every line of the output.  Voila, blend loading is now under 500ms.

In the user interface we had another problem with the blend controls, specifically the curve adjustment sliders.  All image loading occurs asynchronously, and there was code disable the blend adjustment controls while any image was being loaded (a carryover from Spyder).  Since X20 blends are loaded as images, as soon as a slider started to move the entire control would become disabled.  This has been corrected, and will be available in the 3.3.1 update this week.