<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: R2008a</title>
	<atom:link href="http://blogs.mathworks.com/steve/2008/03/07/r2008a/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.mathworks.com/steve/2008/03/07/r2008a/</link>
	<description>Steve Eddins manages the Image &#38; Geospatial development team at The MathWorks and coauthored Digital Image Processing Using MATLAB. He writes here about image processing concepts, algorithm implementations, and MATLAB.</description>
	<lastBuildDate>Wed, 01 Feb 2012 13:58:45 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Steve</title>
		<link>http://blogs.mathworks.com/steve/2008/03/07/r2008a/#comment-21282</link>
		<dc:creator>Steve</dc:creator>
		<pubDate>Thu, 27 Nov 2008 16:08:17 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.mathworks.com/steve/2008/03/07/r2008a/#comment-21282</guid>
		<description>Ljubomir&#8212;That&#039;s the direction MATLAB has been going in for the past six years or so, on all platforms.</description>
		<content:encoded><![CDATA[<p>Ljubomir&mdash;That&#8217;s the direction MATLAB has been going in for the past six years or so, on all platforms.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ljubomir Josifovski</title>
		<link>http://blogs.mathworks.com/steve/2008/03/07/r2008a/#comment-21281</link>
		<dc:creator>Ljubomir Josifovski</dc:creator>
		<pubDate>Thu, 27 Nov 2008 09:01:10 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.mathworks.com/steve/2008/03/07/r2008a/#comment-21281</guid>
		<description>&gt;&gt; &quot;It is no longer feasible to run MATLAB without the jvm&quot;

OMG. I take this is the direction Matlab is going. Very disappointing. Is this true for the latest Unix version as well?

Thanks,
Ljubomir</description>
		<content:encoded><![CDATA[<p>&gt;&gt; &#8220;It is no longer feasible to run MATLAB without the jvm&#8221;</p>
<p>OMG. I take this is the direction Matlab is going. Very disappointing. Is this true for the latest Unix version as well?</p>
<p>Thanks,<br />
Ljubomir</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steve</title>
		<link>http://blogs.mathworks.com/steve/2008/03/07/r2008a/#comment-21066</link>
		<dc:creator>Steve</dc:creator>
		<pubDate>Mon, 15 Sep 2008 12:33:01 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.mathworks.com/steve/2008/03/07/r2008a/#comment-21066</guid>
		<description>Arjun&#8212;It is no longer feasible to run MATLAB without the jvm.  Too much functionality depends on it.</description>
		<content:encoded><![CDATA[<p>Arjun&mdash;It is no longer feasible to run MATLAB without the jvm.  Too much functionality depends on it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Arjun Raj</title>
		<link>http://blogs.mathworks.com/steve/2008/03/07/r2008a/#comment-21062</link>
		<dc:creator>Arjun Raj</dc:creator>
		<pubDate>Mon, 15 Sep 2008 11:41:19 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.mathworks.com/steve/2008/03/07/r2008a/#comment-21062</guid>
		<description>Hi Steve,

My old license just expired, taking with it my old version of MATLAB, which I had avoided upgrading because of the changes to imshow that require the use of the JVM.  I much prefer running MATLAB in -nojvm mode, but I do a lot of image processing and now it seems as though I&#039;m stuck with the JVM.  Is there any way around this?

Thanks,
Arjun</description>
		<content:encoded><![CDATA[<p>Hi Steve,</p>
<p>My old license just expired, taking with it my old version of MATLAB, which I had avoided upgrading because of the changes to imshow that require the use of the JVM.  I much prefer running MATLAB in -nojvm mode, but I do a lot of image processing and now it seems as though I&#8217;m stuck with the JVM.  Is there any way around this?</p>
<p>Thanks,<br />
Arjun</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steve</title>
		<link>http://blogs.mathworks.com/steve/2008/03/07/r2008a/#comment-20756</link>
		<dc:creator>Steve</dc:creator>
		<pubDate>Fri, 30 May 2008 21:11:11 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.mathworks.com/steve/2008/03/07/r2008a/#comment-20756</guid>
		<description>Jerker&#8212;Thanks for the clarification.  There are many measurements we could conceivably add to &lt;tt&gt;regionprops&lt;/tt&gt;, but we will probably stick to the ones with a high volume of requests.</description>
		<content:encoded><![CDATA[<p>Jerker&mdash;Thanks for the clarification.  There are many measurements we could conceivably add to <tt>regionprops</tt>, but we will probably stick to the ones with a high volume of requests.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jerker Wågberg</title>
		<link>http://blogs.mathworks.com/steve/2008/03/07/r2008a/#comment-20683</link>
		<dc:creator>Jerker Wågberg</dc:creator>
		<pubDate>Tue, 06 May 2008 14:28:10 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.mathworks.com/steve/2008/03/07/r2008a/#comment-20683</guid>
		<description>Steve - I just ran into the perimeter problem and came googling to this page. I don&#039;t think your solution to finding the perimeter pixels is what Mark was asking for. The Boundaries in your example will have offsets, since each &#039;Image&#039; will have the same size as the corresponding &#039;BoundingBox&#039;. The workaround is of course to adjust the pixel lists with &#039;BoundingBox&#039; coordinates, but I think this functionality really should be offered by regionprops.

And while you&#039;re at it ;-), I would like a pixel list of the perimeter of the &#039;FilledImage&#039; too!</description>
		<content:encoded><![CDATA[<p>Steve &#8211; I just ran into the perimeter problem and came googling to this page. I don&#8217;t think your solution to finding the perimeter pixels is what Mark was asking for. The Boundaries in your example will have offsets, since each &#8216;Image&#8217; will have the same size as the corresponding &#8216;BoundingBox&#8217;. The workaround is of course to adjust the pixel lists with &#8216;BoundingBox&#8217; coordinates, but I think this functionality really should be offered by regionprops.</p>
<p>And while you&#8217;re at it ;-), I would like a pixel list of the perimeter of the &#8216;FilledImage&#8217; too!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steve</title>
		<link>http://blogs.mathworks.com/steve/2008/03/07/r2008a/#comment-20485</link>
		<dc:creator>Steve</dc:creator>
		<pubDate>Tue, 18 Mar 2008 13:28:53 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.mathworks.com/steve/2008/03/07/r2008a/#comment-20485</guid>
		<description>Qi&#8212;I&#039;m sorry that we&#039;ve disappointed you.  Exporting to geotiff is definitely high on our list, but I&#039;m not sure yet when it will be available.</description>
		<content:encoded><![CDATA[<p>Qi&mdash;I&#8217;m sorry that we&#8217;ve disappointed you.  Exporting to geotiff is definitely high on our list, but I&#8217;m not sure yet when it will be available.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steve</title>
		<link>http://blogs.mathworks.com/steve/2008/03/07/r2008a/#comment-20484</link>
		<dc:creator>Steve</dc:creator>
		<pubDate>Tue, 18 Mar 2008 13:00:07 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.mathworks.com/steve/2008/03/07/r2008a/#comment-20484</guid>
		<description>Mark&#8212;Thanks for your suggestions.

&lt;tt&gt;regionprops&lt;/tt&gt; has supported multidimensional label matrices since 2001, but not for every measurement.  The &lt;a href=&quot;http://www.mathworks.com/access/helpdesk/help/toolbox/images/regionprops.html&quot; rel=&quot;nofollow&quot;&gt;descriptions for the individual measurements&lt;/a&gt; tell you which ones work for multidimensional L, and which ones work only for two-dimensional L.  For example, the description for &lt;tt&gt;&#039;Centroid&#039;&lt;/tt&gt; starts with &quot;1-by-ndims(L) vector ...&quot;  The description for &lt;tt&gt;&#039;Eccentricity&#039;&lt;/tt&gt;, on the other hand, says &quot;This property is supported only for 2-D input label matrices.&quot;

Your description sounds like you want multidimensional support in a different sense.  You have a two-dimensional label matrix, and you want to compute the specified measurements corresponding to that label matrix for each plane of a three-dimensional array.  This is a straightforward application of functionality that&#039;s already in the product.  For example, you might do something like this:

&lt;pre&gt;
for k = 1:3
  means{k} = regionprops(L, rgb(:,:,k), &#039;MeanIntensity&#039;);
end
&lt;/pre&gt;

Boundary tracing has been available in the toolbox for a few releases.  You could compute the boundaries for each labeled region this way:

&lt;pre&gt;
[L, n] = bwlabel(L);
s = regionprops(L, &#039;Image&#039;);
for k = 1:numel(s)
  s(k).Boundaries = bwboundaries(s(k).Image);
end
&lt;/pre&gt;

I like your &quot;use case&quot; of plotting the outlines of labeled regions, and I&#039;m going to suggest to the team that we add an example like that to the documentation.</description>
		<content:encoded><![CDATA[<p>Mark&mdash;Thanks for your suggestions.</p>
<p><tt>regionprops</tt> has supported multidimensional label matrices since 2001, but not for every measurement.  The <a href="http://www.mathworks.com/access/helpdesk/help/toolbox/images/regionprops.html" rel="nofollow">descriptions for the individual measurements</a> tell you which ones work for multidimensional L, and which ones work only for two-dimensional L.  For example, the description for <tt>'Centroid'</tt> starts with &#8220;1-by-ndims(L) vector &#8230;&#8221;  The description for <tt>'Eccentricity'</tt>, on the other hand, says &#8220;This property is supported only for 2-D input label matrices.&#8221;</p>
<p>Your description sounds like you want multidimensional support in a different sense.  You have a two-dimensional label matrix, and you want to compute the specified measurements corresponding to that label matrix for each plane of a three-dimensional array.  This is a straightforward application of functionality that&#8217;s already in the product.  For example, you might do something like this:</p>
<pre>
for k = 1:3
  means{k} = regionprops(L, rgb(:,:,k), 'MeanIntensity');
end
</pre>
<p>Boundary tracing has been available in the toolbox for a few releases.  You could compute the boundaries for each labeled region this way:</p>
<pre>
[L, n] = bwlabel(L);
s = regionprops(L, 'Image');
for k = 1:numel(s)
  s(k).Boundaries = bwboundaries(s(k).Image);
end
</pre>
<p>I like your &#8220;use case&#8221; of plotting the outlines of labeled regions, and I&#8217;m going to suggest to the team that we add an example like that to the documentation.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark Hayworth</title>
		<link>http://blogs.mathworks.com/steve/2008/03/07/r2008a/#comment-20480</link>
		<dc:creator>Mark Hayworth</dc:creator>
		<pubDate>Tue, 18 Mar 2008 01:40:15 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.mathworks.com/steve/2008/03/07/r2008a/#comment-20480</guid>
		<description>Steve, it&#039;s nice that you added the gray scale measurements to regionprops.  That&#039;s been a major outage for far too long.  However I found it ironic that your next blog post mentions how most of the measurements are multidimensional, yet you mention that the new pixel measurements work with gray scale images and you make no mention of multidimensional images such as RGB color images.  It sounds like R2008a is not multidimensional for regionprops.  These new measurements could easily (I believe) have been extended to handle color images and return color values.  Do I have to wait until the next version?  Or the one after that?

Also, another obvious omission is the lack of returning the blob perimeter pixels.  For the entire blob, you return the area and all the pixels that make up the area, yet for the perimeter, you only return the perimeter length and not all the pixels that make up the perimeter.  Why not?  Is it just an oversight or is it really that complicated to add.  The work around I might try is to erode the binary image and then subtract the original (to get just the perimeter pixels), then label and regionprop that image to get PixelIDXList which would then represent only the perimeter pixels.  Will you be adding this functionality directly into regionprops soon so that we do not have to resort to tricky workarounds to get the perimeter coordinates?  The reason for the request is that after finding the blobs, I want to plot the perimeters of them on top of the original color or gray scale image.</description>
		<content:encoded><![CDATA[<p>Steve, it&#8217;s nice that you added the gray scale measurements to regionprops.  That&#8217;s been a major outage for far too long.  However I found it ironic that your next blog post mentions how most of the measurements are multidimensional, yet you mention that the new pixel measurements work with gray scale images and you make no mention of multidimensional images such as RGB color images.  It sounds like R2008a is not multidimensional for regionprops.  These new measurements could easily (I believe) have been extended to handle color images and return color values.  Do I have to wait until the next version?  Or the one after that?</p>
<p>Also, another obvious omission is the lack of returning the blob perimeter pixels.  For the entire blob, you return the area and all the pixels that make up the area, yet for the perimeter, you only return the perimeter length and not all the pixels that make up the perimeter.  Why not?  Is it just an oversight or is it really that complicated to add.  The work around I might try is to erode the binary image and then subtract the original (to get just the perimeter pixels), then label and regionprop that image to get PixelIDXList which would then represent only the perimeter pixels.  Will you be adding this functionality directly into regionprops soon so that we do not have to resort to tricky workarounds to get the perimeter coordinates?  The reason for the request is that after finding the blobs, I want to plot the perimeters of them on top of the original color or gray scale image.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Qi Chen</title>
		<link>http://blogs.mathworks.com/steve/2008/03/07/r2008a/#comment-20443</link>
		<dc:creator>Qi Chen</dc:creator>
		<pubDate>Tue, 11 Mar 2008 01:47:22 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.mathworks.com/steve/2008/03/07/r2008a/#comment-20443</guid>
		<description>Kind of disappointed that the geotiffwrite() is still not available after so many years&#039; waiting.</description>
		<content:encoded><![CDATA[<p>Kind of disappointed that the geotiffwrite() is still not available after so many years&#8217; waiting.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

