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).