PerceptualVBLSyncTest: Remove bogus 32-Bit pixelsize constraint...

…from 'OpenWindow'. No point having it, potential source of trouble.
Add support for Datapixx on 64-Bit Matlab for Windows.

Datapixx.mexw64 mex file for all Viewpixx devices on 64-Bit Windows
added. Special-case for 64-Bit Windows in PsychDataPixx.m removed.
Screen/GStreamer: Fix camerabin1/2 videocapture from DV-1394 sources.

Both old-school camerabin1 capture and new camerabin2 capture didn't
work with consumer class DV-1394 video cameras, e.g., DV-CamCorders
which are connected via Firewiere. This commit adds special case
handling to fix this: We need to avoid prerolling the pipeline and
shutting it down in some cases. We need to build our own camera video
source bin, which contains the actual dv1394src plugin, but also
special dvdemux demultplexers and dvdecode decoders.

Tested with a Sony DCR-TVR 900E PAL camcorder camera.
Some restrictions apply:

1. Video recording is not fully reliable for some reason. Most of the
time it works, but sometimes it just hangs at start of recording.
Videocapture works though.

2. It is possible for invalid/unsupported requested framerates to pass
validation and then cause a hang, apparently because of way too liberal
reporting of supported framerates.

3. Selectable resolutions are constrained to PAL 720x576 and NTSC
720x480 pixels.

Screen for 64-Bit Octave on Linux rebuilt and tested with DV Firewire,
DC Firewire, USB 2.0 cameras.
Screen/GStreamer: Allow selection of video/audio codecs/muxers for camerabin2 recording.

camerabin2 now uses video encoding profiles for encoding/muxing of
recorded video instead of our old-style manual codec/muxer selection
and setup as on the camerabin1 path. This implements support for
encoding profile selection and for a close mapping of old-style
encoding parameters to new style profile settings. It works reasonably
well, although many of the low-level parameters currently can't be set
as with camerabin1.

Support for encoding profiles requires a recent version of GStreamer.
The GStreamer-SDK provides this, so encoding profile support is enabled
by default on Windows 64-Bit and MacOSX 32/64-Bit, where we rely on the
SDK and therefore know we have support. Same goes for Homebrew
GStreamer for OSX.
On 32-Bit Matlab for Windows, we don't support this new functionality,
because the OSSBuilds GStreamer lacks it, and we don't need it, as we
can use camerabin1. On Linux all recent distros support it, but in the
interest of backwards compatibility we don't support encoding profiles
on Linux for the time being, as we can always use camerabin1 functions
instead to achive the same task old-school. -> Iow. encoding profile
support is disabled for Linux at compile-time.

-> Implemented code.
-> Updated build scripts for different operating systems. This commit
has Linux support on for testing. Must be disabled before recompile for
next beta release!
-> Tested with various USB/Firewrire cameras on Linux 64-Bit + Octave.
Seems to be reasonably stable for general consumption.
LoadOBJFile: Whitespace cleanup.
ImagingStereoDemo: Cleanups, new HDMI stereo mode, RemapMouse demo.

Cleanup some M-Lint warnings and remove dead code / whitespace fixes.

Implement demo of new HDMI side-by-side frame packing stereo mode as
mode 102. This corresponds to PsychImaging mode
'SideBySideCompressedStereo'.

Demonstrate use of RemapMouse() to map mouse cursor locations to stereo
drawbuffer locations. Handy if subject pointing responses should be
correlated to stimulus locations on a stereo display. RemapMouse() so
far was only demonstrated in ImagingVideoCaptureDemo where it reverses
spatial distortions caused by geometric display warping/correction.
PsychImaging: Implement new HDMI 'SideBySideCompressedStereo' stereo mode.

A popular format for frame-packing for stereo displays conforming to
one of the HDMI stereo standards. PsychImaging('AddTask', 'General',
'SideBySideCompressedStereo') enables this display mode where images
are horizontally compressed, displayed side-by-side, then uncompressed
by the HDMI display device.

A new helper routine SetCompressedStereoSideBySideParameters() allows
to modify specific display parameters of this mode if non-default
settings are desired. PsychImaging just calls the function with its
default settings, but additionally sets up proper remap information for
use with the RemapMouse() function.

This function is inspired by and co-developed with David Hoffman,
former member of the Banks vision lab, now at Samsung.
PsychDataPixx: Fix auto lut tweaking for osx.

Apple's crappy os (10.7.5 on NVidia GeForce GT 330M) reports a gamma
table size of 1024 slots, but returns a gamma table of 256 slots! This
not only causes loading of wrong identity luts and therefore dithering
problems with devices like DataPixx, it also throws off the automatic
gamma table tweaking in PsychDataPixx due to the mismatch between
reported and actual table size.

Fix this by ignoring the osx reported gamma tables size and just look
at what we actually get. These iToys never fail to endlessly entertain.
DrawManuallyAntiAliasedTextDemo: Restore anti-aliasing settings at end of demo.

So they don't stick and affect all following running demos and code.
Screen('Pixelsize'/'Pixelsizes'): Clarify help text, whitespace fixes.

Fix code formatting. Make it clear in online help text that pixelSize
refers to the color depth of a pixel (bpp), not spatial size.
Screen: Fix typo in error message on invalid pixelSize argument.

It is an "invalid" argument, not an "invalide" argument.
Screen/OSX: Workaround broken pixelSize reporting on OSX 10.7

The iToys os does not enumerate all available displays modes under
certain conditions, e.g., external display connected to MacBookPro 2010
on 10.7.5 and operated at certain resolutions. While the video
resolution is set to 1440x900 pixels on the external display, and in
fact reported as such by the os'es GUI and PTB's Screen('Rect')
function, that resolution is not listed by the OS as available video
mode! Well it is listed on low-level driver queries, but not by the
high-level routines CGDisplayAvailableModes(). This schizophrenic
mental state of the OS causes matching failure of current video mode
against set of possible modes, resulting in return of an empty list of
supported display bit depths for current video mode, ie.,
Screen('Pixelsizes') returns an emtpy list. This wreaks havoc in
Screen('Openwindow') if pixelSize is specified -- matching against an
empty list --> invalid pixelSize abort, and in other user scripts.
Workaround this by printing a warning and making up a fake list of the
most common supported pixelSizes 16 bpp and 32 bpp. Of course other
routines like Screen('Resolutions') will also be affected without
possibility of a workaround, but this allows unfortunate owners of an
iToy to let their machines limp along if they don't use one of the
affected routines.

The specific error case here is running a CRT monitor at a low
resolution over a DataPixx device. Luckily more common video modes seem
to work.
Screen('DrawText'): Make text texture sampling mode dependent on anti-aliasing setting.

Old ptb's always used nearest neighbour sampling for the OpenGL texture
which stores rendered text. This works perfectly with things like color
index overlays as used for clut animation or hardware like
DataPixx/ViewPixx/ProPixx/Bits+/Bits# with hardware overlays, but text
quality suffers if text is displayed scaled, sheared or rotated.
Current ptb's always use bilinear filtering: Nice
rotated/scaled/sheared text, but potential misassignment of color
palette indices in rendered text if output display has high resolution
and gpu has relatively low texture sampling accuracy, e.g., Radeon
X-1000 gpu's -> Causes artifacts in text in hardware overlays during
clut animation etc.

Solution: If Screen('Preference', 'TextAntiAliasing') requests
anti-aliased text rendering, use bilinear filtering for text texture
sampling/blitting during DrawText. This is the default. If
anti-aliasing is disabled, also switch back to nearest neighbour
texture sampling. This causes the usual jagged text, but works with
color overlay hardware and cluts.

Problem was found when trying to drive a high resolution 1920x1080
ViewPixx panel with an old 2006'ish MacBookPro and ATI Mobility Radeon
X1600 class gpu, which has accuracy issues in such a case, causing
weird color artifacts in text displayed by the hardware overly in M16
mode.

Screen for 64-Bit Matlab on OSX rebuilt & tested. Same fix will apply
to Windows, whereas Linux text renderer always did the right thing(tm).
Screen: Tolerate a multisample size of 1 sample without warnings.

Intel gpu drivers on Windows report a sample count of 1 even if
multi-sampling is off. This is a driver bug that triggered lots of
warnings in the past. Now we simply tolerate a count of 1 sample, which
still means that MSAA is off, allowing for less warning clutter on the
screen.
Merge pull request #9 from iandol/eyelinkfixes

Eyelink toolbox: Fix a hardcoded callback function.