Time for action – adding preview in our code

This time, we will repeat the previous experiment, with a minor adjustment; we will add a preview command in our code. Let's try it:

  1. First, we will repeat steps 1 to 3 from the previous example:
    >> imaqreset
    >> vid = videoinput('winvideo', 1, 'dvsd_720x576'),
    >> test = uint8(zeros(576,720,3,100));
    >> profile on
  2. Now, we will invoke the Preview window using the following command:
    >>preview(vid);
  3. And then, we will once more type in the acquisition-processing nested for loops:
    >> for i = 1:100
    temp = getsnapshot(vid);  % Acquire a frame
    fprintf('Processing frame number %d… 
    ',i) % Announcement 
    for k = 1:3	% For all 3 color channels
    test(:,:,k,i) = imadjust(temp(:,:,k)); % Adjust contrast
    end
    subplot(1,2,1),imshow(temp ) % Display current frame
    subplot(1,2,2),imshow(test(:,:,:,i)) % Display processed frame
    end
  4. Finally, we will close and display the profiling results:
    >> profile off % Close profiler
    >> profile viewer   % Display profiling results
    Time for action – adding preview in our code

    Quite different results than what we saw before.

  5. Our last step is to close the Preview window, since we are done with our acquisition:
    >> stoppreview(vid)

What just happened?

This example showed us a general truth about MATLAB programming. The solution to our problems, especially when they are relevant to processing speed, is frequently much simpler than expected. In our case here, the solution was to open a Preview window that continuously displays what our camera sees. This way, the total time spent for 100 calls of our getsnapshot function fell from a huge 26.824 seconds to a very low 0.353 seconds. Our code still has not reached 25 fps, since the imshow function needs 5 seconds, hence leads to a 1/0.05 = 20 fps rate alone, but this is a smaller problem that can be handled in other ways.

Have a go hero – doubling the speed of our code

Now we have reached our most crucial point. Our code is near real-time, but still not actual real-time. You should try to make adjustments in the code, which will enable it to run at least twice as fast as the one we have created so far. As different machines will produce different processing time results, you should have a goal of doubling the performance in your machine. Therefore, you should time the process of the previous example in your own machine and then try to improve the code while checking if you have accomplished your goal (at least doubling the speed). It goes without saying that we seek a performance increase without throwing out the part of the code displaying our results.

Pop quiz – acquiring and processing videos

Q1. Which of the following are true?

  1. The Image Acquisition Tool only saves uncompressed video.
  2. The size of an MP4 video is related only to its resolution and duration.
  3. A high motion MP4 video with the same settings as a low motion MP4 video will be larger in size.
  4. The creation of time-lapse videos can be accomplished by just using a for loop with getsnapshot and pause inside it.
  5. The real-time processing of time-lapse videos is more challenging than the real-time processing of regular frame rate videos.
  6. Adding preview in our code slows down the frame acquisition process using getsnapshot.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset