Guy and Seth on Simulink

A MATLAB vs. Simulink battle? I’m in! 7

Posted by Guy Rouleau,

When I saw the latest post by Matt Tearle on Steve's blog, I had to do something.

Since the video at the center of this post is about a rap battle between MATLAB and Simulink, I thought it would be interesting to bring that to a higher level and see how the video processing could have been implemented in Simulink instead of MATLAB.

Seriously... who wants to write code when you can simply connect blocks?


Since I have absolutely zero knowledge in image processing, I simply re-implemented the algorithm suggested by Matt in Simulink. The resulting model looks like:

Green Screen processing

Let's look at the details.

Importing the video

To begin, I used the From Multimedia File from the DSP System Toolbox to directly read the AVI-file with our rappers in front of a green background. Then I use the resize block from the Computer Vision System Toolbox. This allows me to work on images of a relatively small size. After, I normalize the data, as suggested by Matt.

Reading Video

The Greenness factor

I really like the simple equation the Matt figured out to calculate the "greenness" of each pixel in the image. In MATLAB, it looks like:

% Greenness = G*(G-R)*(G-B) greenness = yd(:,:,2).*(yd(:,:,2)-yd(:,:,1)).*(yd(:,:,2)-yd(:,:,3));

In Simulink, I can use Selector blocks to separate the three colors (third dimension of the image signal) and implement Matt's equation:



The next piece of code is something that many users struggle to figure out:

thresh = 0.3*mean(greenness(greenness>0));

To implement logical indexing (e.g. A(A>0)) in Simulink, we need to combine the Find block with a Selector block. This results in a variable-size signal


Combining the images

The last line we need to implement is to replace the pixels identified as green in the foreground image but their values in the background image. In MATLAB, this is accomplished using this line:

rgb2(isgreen) = rgb1(isgreen);

In Simulink, we need to extend the logic seen at the previous step. We first select the desired pixels from the background image, and then assign them to the foreground image:


Note that the Computer Vision System Toolbox has a Compositing block implementing this functionality.

Here is what the final result looks like:


Now it's your turn

What do you think? Is it more convenient to implement this algorithm in MATLAB or Simulink? How do you typically decide between a code-based or a block-based implementation? Let us know by leaving a comment here.

7 CommentsOldest to Newest

Simulink’s preferred:
The library browser makes it easy to find what’s available.
The interface to each block is usually more clear, and the dialog box shows how they can be configured – rarely do I need to open the documentation to understand a block, the information’s much more readily available.

I tend to use Matlab only for processing files/logs into graphs – it’s not work doing that in Simulink.

The answer to which is best depends largely on your background, and what you’re used to. In my opinion, Simulink if better for top-level functional and data-flow visualisation, Matlab is better for “low-level” implementation.

The big disadvantage of Simulink is the lack of traceability of algorithms through revision control systems (we use SVN). The lack of a suitable difference tool (without forking out for Simulink Projects, which in my opinion should be a core component of Simulink) makes tracability virtually impossible. The file format (MDL) also changes significantly between saves leading to larger SVN repos. The introduction of the binary model format (SLX) is likely to compound that.

As a result we try to use as much embedded M, with each embedded M function just calling a standalone function to do the work. This approach also allows:
– Easier unit testing of the “low-level” function
– Traceability through SVN

A big downside of this approach is that codegen of embedded M doesn’t appear to be able to suitably resolve the difference between one-indexed arrays (M) and zero-indexed arrays (C), leading to (more) inefficient code.


Simulink Projects *is* a part of core Simulink, so you do get the SVN/Git integration with a standard Simulink installation.

The “forking out” would be for Simulink Report Generator, which (among other things) provides functionality for comparing and merging Simulink models.

Putting it together, you can do your diffing across SVN/Git revisions right from the Simulink Project.

Hi, Sebastian, I agree that for embedded project, the generated code is better for comparing. How about model merging? can we do model merging from Report?

Hello, guys. I have a question about the code generation using Stateflow. In MAAB style guideline, there is a rule applied to logic in Stateflow: Matlab functions can not be used and the rule priority is mandatory. Can anybody give me an explaination? Many thanks.

Add A Comment

What is 3 + 9?

Preview: hide

These postings are the author's and don't necessarily represent the opinions of MathWorks.