Displaying animated GIFs

Wednesday, May 22nd, 2013

Displaying images in Matlab figures has always been sort-of awkward. We need to read the image file into a Matlab matrix (possibly with accompanying colormap), then create an invisible axis in our figure window, and finally display the image data within this axis, typically with the imagesc function. In practice, this is not as difficult as it may seem, and can be done in 3 lines of code (imread(); axes(); imagesc();). To display images in uicontrols, we need to set their CData property with the image data. Unfortunately, this is only supported for static (non-animated) images.

But what if we want to display an animated image? There are several image formats that enable animation, GIF being the most well-known. Animated GIFs are used ubiquitously, for anything from logos to simple visualizations. I often use them myself in my utilities and this blog, to illustrate functionality or usage. Creating animated GIFs is so easy — I often use Picasion, but there are numerous alternatives.

So let’s assume that I have the animated GIF featured here:

animated GIF

animated GIF

This example serves as the logo in a demo application that I’ll present tomorrow at the MATLAB Computational Finance Conference.

To display this image in a Matlab GUI, we could use a mini-browser control that we can easily integrate within the figure. But an even simpler and less resource-intensive solution is to integrate an HTML panel:

hFig = figure('Color','w'); 
je = javax.swing.JEditorPane('text/html', '<html><img src="file:/C:\Yair\animated.gif"/></html>');
[hj, hc] =  javacomponent(je,[],hFig);
set(hc, 'pos', [10,10,70,70])

Animated GIF image integrated in Matlab figure

Animated GIF image integrated in Matlab figure


Continue reading →

Categories: GUI, Low risk of breaking in future versions, Undocumented feature
Tags: , , ,
Leave a comment

HG2 update

Wednesday, May 15th, 2013

Exactly three years ago, I posted information (here and here) about Matlab’s upcoming new graphics engine, so-called HG2 (Handle Graphics version 2). At the time, I was sure that HG2 was just around the corner. But three years and six releases have passed, Matlab 7 turned into Matlab 8, and HG1 is still in use. I decided that it was time to revisit the latest state of HG2, as reflected in the latest release, R2013a (Matlab 8.1).

In the past few years, development of HG2 has apparently progressed to a stage where most of the kinks were ironed out. The latest HG2 appears to be quite stable, and in my experience most GUI/graphics utilities run as-is, without any need for tweaking. This is good news, which leads me to think that HG2 will be released soon. It is possible that this could happen as early as the upcoming release (R2013b, 8.2) but I have a gut feeling that it will be in R2014a. I also have a gut feeling that MathWorks will name that release 9.0 rather than 8.3, in keeping with its arch-rival Mathematica.

HG2 has improved grid lines, plot anti-aliasing and customizable everything (more on this below). Here’s a simple plot line as it appears in both HG1 and HG2:

hFig = figure('pos',[100,100,300,250]);
x = -10:0.1:10;
y = 1e7*sin(x)./x; 
hLine = plot(x,y);
box off; grid on;
title('HG2 plot');

HG1 plotHG2 plot

Same plot in HG1 and HG2

We can see that MathWorks has invested heavily in improving usability. The graphics are now much more visually appealing than before. A lot of thought has gone into small details such as the plot colors and the axes gray shades. The changes are small when taken separately, but the overall gestalt is striking. HG2 will definitely justify my license maintenance cost.
Continue reading →

Nguyễn Thế Hồng, Timo Dörsam, Walter Roberson liked this post
Categories: Figure window, GUI, Handle graphics, Hidden property, Low risk of breaking in future versions, Stock Matlab function, Undocumented feature
Tags: , , , , , ,
24 Comments

Improving save performance

Wednesday, May 8th, 2013

Two weeks ago I posted an article about improving fwrite‘s performance. fwrite is normally used to store binary data in some custom pre-defined format. But we often don’t need or want to use such low-level functions. Matlab’s built-in save function is an easy and very convenient way to store data in both binary and text formats. This data can later be loaded back into Matlab using the load function. Today’s article will show little-known tricks of improving save‘s performance.

MAT is Matlab’s default data format for the save function. This format is publicly available and adaptors are available for other programming languages (C, C#, Java). Matlab 6 and earlier did not employ automatic data compression; Matlab versions 7.0 (R14) through 7.2 (R2006a) use GZIP compression; Matlab 7.3 (R2006b) and newer can use an HDF5-variant format, which apparently also uses GZIP (level-3) compression, although MathWorks might have done better to pay the license cost of employing SZIP (thanks to Malcolm Lidierth for the clarification). Note that Matlab’s 7.3 format is not a pure HDF5 file, but rather a HDF5 variant that uses an undocumented internal format.

The following table summarizes the available options for saving data using the save function:

save option Available since Data format Compression Major functionality
-v7.3 R2006b (7.3) Binary (HDF5) GZIP 2GB files, class objects
-v7 R14 (7.0) Binary (MAT) GZIP Compression, Unicode
-v6 R8 (5.0) Binary (MAT) None N-D arrays, cell arrays, structs
-v4 All releases Binary (MAT) None 2D data
-ascii All releases Text None Tab/space delimited

HDF5 uses a generic format to store data of any conceivable type, and has a non-significant storage overhead in order to describe the file’s contents. Moreover, Matlab’s HDF5 implementation does not by default compress non-numeric data (struct and cell arrays). For this reason, HDF5 files are typically larger and slower than non-HDF5 MAT files, especially if the data contains cell arrays or structs. This holds true for both pure-HDF files (saved via the hdf and hdf5 set of functions, for HDF4 and HDF5 formats respectively), and v7.3-format MAT files.

Perhaps for this reason the default preference is for save to use –v7, even on new releases that support –v7.3. This preference can be changed in Matlab’s Preferences/General window (or we could always specify the –v7/-v7.3 switch directly when using save):

Matlab's preferences for saving binary data

Matlab's preferences for saving binary data


Continue reading →

Categories: Low risk of breaking in future versions, Stock Matlab function
Tags: ,
10 Comments

New York City visit, 21-24 May 2013

Wednesday, May 1st, 2013

I’d like to break the regular flow of weekly articles, to announce that I will visit New York City on May 21-24, to speak at the Matlab Computational Finance Conference (May 23).

I will be very happy to meet you and discuss how I could bring value to your needs, either financial-oriented or not. We can meet at the conference, or elsewhere in NYC on other days: Tuesday (May 21), Wednesday (May 22) or Friday (May 24). If you would like to schedule a meeting, please email me.

Matlab Computational Finance Conference

Matlab Computational Finance Conference, 23 May 2013 The Matlab Computational Finance conference is an event that takes place more-or-less annually, in different locations. In 2012 it was held in London; in 2011 it was virtual (online). This year it will be held in New York City on May 23, at the Marriott Marquis hotel, located in midtown (1535 Broadway, next to Times Square).

The free, full-day conference showcases real-world examples of how financial organizations use Matlab to develop risk, trading, investment management, and insurance applications. Highlights include:

  • Customer presentations from leading industry practitioners in trading, risk, valuation, portfolio analysis, insurance, and regulatory compliance
  • Master class tutorials delivered by senior MathWorks engineers to enhance your understanding of Matlab features and functionality
  • Panel discussion with senior Matlab developers
  • An opportunity to network, exchange ideas, and discuss challenges and successes with industry peers and Matlab experts
  • And naturally, my presentation, slated for 16:50 (I suggest rechecking the agenda close to the conference, to ensure that the time-slot hasn’t changed)

Here is the abstract of my presentation:

MATLAB has traditionally been used for analyzing data off-line, presenting analytic recommendations that were then acted-upon manually. However, MATLAB supports direct interface with data feeds and online brokers, as well as the ability to present sophisticated graphics and user interfaces – all in real time.

This presentation will demonstrate an end-to-end demo trading system in MATLAB, highlighting MATLAB’s potential as a platform of choice. Interactive Brokers will be used to demonstrate live market data feed and account/portfolio input, as well as for sending trading orders to the market. The system’s user interface (GUI) showcases MATLAB’s hidden visualization and interactivity potential, for tracking order executions and charting financial time-series in real-time. Some best-practices for improving real-time performance shall also be discussed.

If you are interested in any aspect of computational finance, you will surely find some interesting presentations at this conference. So if you’re in town, I urge you to attend (hey – it’s free and I hear there’s drinks…). You can register here. If you can’t attend in person, you will be able to see recordings of the proceedings on the conference website some time later.

Walter Roberson, Marcelo David liked this post
Categories: Uncategorized
1 Comment

Improving fwrite performance

Wednesday, April 24th, 2013

Readers of this blog are probably aware by now that I am currently writing my second book, MATLAB Performance Tuning (expected publication date: early 2014, CRC Press). During my work on this book, I encounter many surprising aspects of Matlab performance. In many cases these aspects are not un-documented per-se, but are certainly not well known in the Matlab community. So taking some artistic liberty coupled with some influence over this blog’s owner, I’ll mention some of these interesting discoveries here, even if they are not strictly-speaking undocumented.

Today’s post is about the well-known fwrite function, which is used to write binary data to file. In many cases, using fwrite provides the fastest alternative to saving data files (save(…,’-v6′) coming a close second). This function is in fact so low-level, and is used so often, that some readers may be surprised that its default speed can be improved. Today’s article applies equally to the fprintf function, which is used to save data in text format.

Apparently, there are things to be learned even with such standard low-level functions; there’s a deep moral here I guess.
Continue reading →

Categories: Low risk of breaking in future versions, Semi-documented feature, Stock Matlab function
Tags: ,
5 Comments

Setting class property types

Thursday, April 18th, 2013

When I wrote about the undocumented aspects of classdef properties half a year ago, I did not expect to learn of another major undocumented aspect in Matlab’s class-object system. last month I discovered the additional undocumented classdef Description and DetailedDescription attributes, and updated that article accordingly. But a few days ago I was pleasantly surprised to read Amro’s comment about an entirely new and undocumented aspect of Matlab MCOS classes.

Amro is a top contributor on StackOverflow, where he frequently answers questions before I even get any subscription notification about them… His answers are generally characterized by a deep technical understanding of Matlab, and I’ve learned quite a lot from him in the past few years. This time was no different.

In a nutshell, Amro found an undocumented way to specify a class object property’s type, in such a way that would prevent accidental setting to an incompatible value. For example, if we have a class with properties Width and Height, we probably want to restrict their possible values to numbers, to prevent setting a string or struct value.

In UDD classes, we can do this easily by setting the property’s DataType meta-property. An easy way to do this is by setting the second argument of the schema.prop function. A detailed explanation was provided here.

We can still do this today, since UDD classes are still supported, side-by-side with the newer MCOS classes. Unfortunately, MCOS does not provide a documented way of specifying the property type as in UDD.

One simple way to prevent unintentional MCOS property updates is to override the property’s set method. In fact, this was the solution of Jonas, another StackOverflow heavyweight:

classdef myClass
   properties
      myProperty = uint16(23); %# specify default value using correct type
   end
   methods
      function obj = set.myProperty(obj,val)
         if ~isa(val,'uint16')
            error('only uint16 values allowed')
         end
         %# assign the value
         obj.myProperty = val;
      end
   end
end

But it turns out that there’s a much cleaner and simpler solution, provided by Amro:

classdef Packet
    properties
        HeaderLength@uint16
        PayloadLength@uint16 = uint16(0);
        PacketType@char
    end
end

Continue reading →

Categories: Medium risk of breaking in future versions, Undocumented feature
Tags: , , , , ,
12 Comments

Parsing mlint (Code Analyzer) output

Wednesday, April 10th, 2013

Mlint, Matlab’s static code-analysis parser, was written by Stephen Johnson (the original developer of the enormously successful lint parser for C/C++ back in 1977), when he was lured by MathWorks in 2002 to develop a similar tool for Matlab. Since its development (in R14 I believe), and especially since its incorporation in Matlab’s Editor in R2006a (Matlab 7.2), mlint has become a very important tool for reporting potential problems in m-files.

Unfortunately, to this day (R2013a), there is no documented manner of programmatically separating mlint warnings and errors, nor for accessing any of the multitude of features that are readily available in mlint. Naturally, there is (and has always been) an undocumented back door.

From its earliest beginnings, mlint has relied on C code (presumably modeled after lint). For many years mlint relied on a mex file (%matlabroot%/toolbox/matlab/codetools/mlintmex.mex*), which is basically just a wrapper for mlint.dll where the core algorithm resides. In recent releases, mlintmex, just like many other core mex files, was ported into a core Matlab library (libmwbuiltins.dll on Windows). However, the name and interface of the mlintmex function have remained unchanged over the years. Wrapping the core mlintmex function is the mlint m-function (%matlabroot%/toolbox/matlab/codetools/mlint.m) that calls mlintmex internally. In R2011b (Matlab 7.13) its official function name has changed to checkcode, although this was never documented in the release notes for some reason. However, using mlint still works even today. Wrapping all that is the mlintrpt function, which calls mlint/checkcode internally.

The core function mlintmex returns a long string with embedded newlines to separate the messages. For example:

>> str = mlintmex('perfTest.m')
str = 
L 3 (C 1): The value assigned to variable 'A' might be unused.
L 4 (C 1): The value assigned to variable 'B' might be unused.
L 5 (C 1-3): Variable 'ops', apparently a structure, is changed but the value seems to be unused.
L 12 (C 9): This statement (and possibly following ones) cannot be reached.
L 53 (C 19-25): The function 'subFunc' might be unused.
L 53 (C 27-35): Input argument 'iteration' might be unused. If this is OK, consider replacing it by ~.

Continue reading →

Categories: Medium risk of breaking in future versions, Mex, Stock Matlab function, Undocumented feature
Tags: , , , ,
3 Comments

ishghandle’s undocumented input parameter

Wednesday, March 27th, 2013

Two weeks ago I wrote about Matlab Handle Graphics (HG) undocumented acceptance of structs as input parameter to some plotting functions. Continuing in a related matter, today I expose an undocumented input parameter for HG’s ishghandle function.

ishghandle is a fully-documented built-in Matlab function that returns a logical flag indicating whether the specified input is a valid HG handle or not. The input could be an invalid handle for several reasons: Perhaps it is not an HG handle in the first place, or perhaps the corresponding HG object has since been deleted (for example, its parent figure window was closed). The usage is very simple:

if ishghandle(myHandle)
    set(myHandle, ...);
end

But what if myHandle could be any of several possible HG types (e.g., plot line, patch or 3D surface) and our logic depends on the type? Of course, we could always add an extra condition to the logic:

if ishghandle(myHandle) && strcmp(get(h,'type'),'surface')
%or: if ishghandle(myHandle) && isa(handle(h),'surface')
    set(myHandle, ...);
end

There’s an undocumented alternative: we can simply specify the expected type as a second input argument to ishghandle. This is in fact the simplest and fastest alternative:

if ishghandle(myHandle,'surface')
    set(myHandle, ...);
end

Continue reading →

Categories: Handle graphics, Low risk of breaking in future versions, Stock Matlab function, Undocumented feature
Tags: , ,
Leave a comment

JTattoo look-and-feel demo

Wednesday, March 20th, 2013

Three years ago, I wrote an article about modifying Matlab’s look-and-feel (L&F, or LnF), using Java’s built-in support for replaceable LnFs. To date, that article has 27 comments by 13 different commenters (plus 20 responses by me), making it the second most active article on this website. I decided to follow up on that article with a demo that shows the effects that different L&Fs have on GUI controls, and a demonstration of the JTattoo library of professional L&Fs.

Today’s article and the demo are based on original work by Karthik Ponudurai, who has written a guest article here about an interesting technique to interface a Java GUI to a Matlab application, a couple of years ago.

Demo of using different Look-and-Feels in Matlab GUI

Demo of using different Look-and-Feels in Matlab GUI

Continue reading →

Categories: Guest bloggers, GUI, Java, Medium risk of breaking in future versions, UI controls
Tags: , , , ,
3 Comments

HG’s undocumented parameters interface

Thursday, March 14th, 2013

Continuing last week’s article on Matlab Handle Graphics’ (HG) undocumented Behavior functionality, today I describe another undocumented aspect of HG. Some of the low-level HG functions, such as line and path receive their input parameters in one of two formats:

HG line created using either of the input formats

HG line created using either of the input formats

  • The regular fully-documented P-V pairs format: 
    line('Marker','*', 'MarkerSize',8, 'MarkerEdgeColor','b', ...
     'Color','r', 'XData',1:5, 'YData',3:7)
  • An undocumented struct-fields format: 
    lineprops.Marker = '*';
lineprops.MarkerSize = 15;
lineprops.MarkerEdgeColor = 'b';
lineprops.color = 'r';
lineprops.xdata = 1:5;
lineprops.ydata = 3:7;
 
line(lineprops)

Continue reading →

Categories: Handle graphics, Medium risk of breaking in future versions, Stock Matlab function, Undocumented feature
Tags: , ,
6 Comments