<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.1" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Logical indexing</title>
	<link>http://blogs.mathworks.com/steve/2008/01/28/logical-indexing/</link>
	<description>Steve Eddins manages the Image &#38; Geospatial development team at &#60;a href="http://www.mathworks.com/"&#62;The MathWorks&#60;/a&#62; and coauthored &#60;a href="http://www.mathworks.com/support/books/book5291.html?category=-1&#38;language=-1"&#62;Digital Image Processing Using MATLAB&#60;/a&#62;. He writes here about image processing concepts, algorithm implementations, and MATLAB.&#60;br&#62;&#60;br&#62;&#60;img&#62;</description>
	<pubDate>Mon, 23 Nov 2009 01:50:15 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.1</generator>
		<item>
		<title>By: Steve</title>
		<link>http://blogs.mathworks.com/steve/2008/01/28/logical-indexing/#comment-20866</link>
		<dc:creator>Steve</dc:creator>
		<pubDate>Sat, 12 Jul 2008 16:21:27 +0000</pubDate>
		<guid>http://blogs.mathworks.com/steve/2008/01/28/logical-indexing/#comment-20866</guid>
		<description>Oliver&#8212;I'm glad you found it useful.</description>
		<content:encoded><![CDATA[<p>Oliver&mdash;I&#8217;m glad you found it useful.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Oliver A. Chapman, P.E.</title>
		<link>http://blogs.mathworks.com/steve/2008/01/28/logical-indexing/#comment-20864</link>
		<dc:creator>Oliver A. Chapman, P.E.</dc:creator>
		<pubDate>Fri, 11 Jul 2008 18:24:05 +0000</pubDate>
		<guid>http://blogs.mathworks.com/steve/2008/01/28/logical-indexing/#comment-20864</guid>
		<description>Steve,

Thanks for directing me to this.  It is very well written.</description>
		<content:encoded><![CDATA[<p>Steve,</p>
<p>Thanks for directing me to this.  It is very well written.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steve</title>
		<link>http://blogs.mathworks.com/steve/2008/01/28/logical-indexing/#comment-20603</link>
		<dc:creator>Steve</dc:creator>
		<pubDate>Wed, 16 Apr 2008 17:36:56 +0000</pubDate>
		<guid>http://blogs.mathworks.com/steve/2008/01/28/logical-indexing/#comment-20603</guid>
		<description>Lydia&#8212;If your files are TIFF, and if you have R2007b or R2008a, you can use the &lt;tt&gt;PixelRegion&lt;/tt&gt; parameter of &lt;tt&gt;imread&lt;/tt&gt; to read in subsets of the image, or to read in a subsampled version of the image.</description>
		<content:encoded><![CDATA[<p>Lydia&mdash;If your files are TIFF, and if you have R2007b or R2008a, you can use the <tt>PixelRegion</tt> parameter of <tt>imread</tt> to read in subsets of the image, or to read in a subsampled version of the image.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Lydia</title>
		<link>http://blogs.mathworks.com/steve/2008/01/28/logical-indexing/#comment-20547</link>
		<dc:creator>Lydia</dc:creator>
		<pubDate>Tue, 01 Apr 2008 16:46:31 +0000</pubDate>
		<guid>http://blogs.mathworks.com/steve/2008/01/28/logical-indexing/#comment-20547</guid>
		<description>Dear Steve,
My images are quite big (169600x241 matrices, 326988800bytes) and when i try to display them it seems I don't have enough memory or the image is too big to fit in the screen and use the imshow function... How can I make these images easier to handle and take less memory? I am not very familiar with all the available storage formats, which one could I try, any option?</description>
		<content:encoded><![CDATA[<p>Dear Steve,<br />
My images are quite big (169600&#215;241 matrices, 326988800bytes) and when i try to display them it seems I don&#8217;t have enough memory or the image is too big to fit in the screen and use the imshow function&#8230; How can I make these images easier to handle and take less memory? I am not very familiar with all the available storage formats, which one could I try, any option?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steve</title>
		<link>http://blogs.mathworks.com/steve/2008/01/28/logical-indexing/#comment-20379</link>
		<dc:creator>Steve</dc:creator>
		<pubDate>Sun, 02 Mar 2008 14:20:07 +0000</pubDate>
		<guid>http://blogs.mathworks.com/steve/2008/01/28/logical-indexing/#comment-20379</guid>
		<description>Joshua&#8212;You might find &lt;tt&gt;roifilt&lt;/tt&gt; to be helpful.</description>
		<content:encoded><![CDATA[<p>Joshua&mdash;You might find <tt>roifilt</tt> to be helpful.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joshua</title>
		<link>http://blogs.mathworks.com/steve/2008/01/28/logical-indexing/#comment-20255</link>
		<dc:creator>Joshua</dc:creator>
		<pubDate>Mon, 18 Feb 2008 21:15:51 +0000</pubDate>
		<guid>http://blogs.mathworks.com/steve/2008/01/28/logical-indexing/#comment-20255</guid>
		<description>I have been trying to figure out a way to convolve specific pixels in an image.  Could a logical mask be used to do this?  Convolving all the pixels in an image is a waste for my algorithm that only needs to convolve sometimes just one pixel in a loop.  The only solution I have found so far is to copy out a 3x3 region, convolve that, and copy the value back.  But it isn't very elegant.</description>
		<content:encoded><![CDATA[<p>I have been trying to figure out a way to convolve specific pixels in an image.  Could a logical mask be used to do this?  Convolving all the pixels in an image is a waste for my algorithm that only needs to convolve sometimes just one pixel in a loop.  The only solution I have found so far is to copy out a 3&#215;3 region, convolve that, and copy the value back.  But it isn&#8217;t very elegant.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steve</title>
		<link>http://blogs.mathworks.com/steve/2008/01/28/logical-indexing/#comment-19915</link>
		<dc:creator>Steve</dc:creator>
		<pubDate>Thu, 07 Feb 2008 13:59:24 +0000</pubDate>
		<guid>http://blogs.mathworks.com/steve/2008/01/28/logical-indexing/#comment-19915</guid>
		<description>Ram&#8212;Keep an auxiliary "mask" image (logical matrix) in which pixels already processed are marked with 1s.</description>
		<content:encoded><![CDATA[<p>Ram&mdash;Keep an auxiliary &#8220;mask&#8221; image (logical matrix) in which pixels already processed are marked with 1s.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ram</title>
		<link>http://blogs.mathworks.com/steve/2008/01/28/logical-indexing/#comment-19884</link>
		<dc:creator>Ram</dc:creator>
		<pubDate>Wed, 06 Feb 2008 15:21:39 +0000</pubDate>
		<guid>http://blogs.mathworks.com/steve/2008/01/28/logical-indexing/#comment-19884</guid>
		<description>Hi Steve,
 
My work involves finding suitable pixels in an image and pseudo-randomly selecting those pixels. Considering the selected pixel as centre pixel i have to modify the value of the centre pixel and its 4-neighbours.
The problem is that i must make sure none of neighbours are selected again so the values of already modified 5 pixels dont get remodified. Please suggest something.</description>
		<content:encoded><![CDATA[<p>Hi Steve,</p>
<p>My work involves finding suitable pixels in an image and pseudo-randomly selecting those pixels. Considering the selected pixel as centre pixel i have to modify the value of the centre pixel and its 4-neighbours.<br />
The problem is that i must make sure none of neighbours are selected again so the values of already modified 5 pixels dont get remodified. Please suggest something.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steve</title>
		<link>http://blogs.mathworks.com/steve/2008/01/28/logical-indexing/#comment-19471</link>
		<dc:creator>Steve</dc:creator>
		<pubDate>Tue, 29 Jan 2008 01:50:17 +0000</pubDate>
		<guid>http://blogs.mathworks.com/steve/2008/01/28/logical-indexing/#comment-19471</guid>
		<description>Andreas&#8212;It's not a simple story.  It's tied up in the long history of MATLAB language design evolution.  Before MATLAB 5, all MATLAB matrices were 2-D double precision, and "logicalness" was an attribute of those matrices.  That's 8 bytes per binary pixel!  Then MATLAB 5 introduced integer array types (including uint8), but at first there was relatively little functional or operator support for them, except in the Image Processing Toolbox.  Logicalness was still a numeric array attribute.  Gradually, some operators that produced logical arrays began producing uint8 arrays instead of double arrays.  These changes were made very cautiously because of obvious compatibility issues.  Then in MATLAB 6.5 logical became its own class, instead of an attribute of other classes.  Again this change had to be made very carefully to minimize the impact on the existing huge base of internal code, toolbox code (especially in the Image Processing Toolbox), and existing customer MEX code.  By keeping to the 1-byte element, much existing internal MATLAB code as well customer code could continue to work with little or no change.  A "compatibility layer" was introduced into the MEX API that helped smooth over compatibility issues for a couple of releases.  Plus the fact that C had a builtin one-byte data type, but not a builtin one-bit data type, influenced decision making along the way.</description>
		<content:encoded><![CDATA[<p>Andreas&mdash;It&#8217;s not a simple story.  It&#8217;s tied up in the long history of MATLAB language design evolution.  Before MATLAB 5, all MATLAB matrices were 2-D double precision, and &#8220;logicalness&#8221; was an attribute of those matrices.  That&#8217;s 8 bytes per binary pixel!  Then MATLAB 5 introduced integer array types (including uint8), but at first there was relatively little functional or operator support for them, except in the Image Processing Toolbox.  Logicalness was still a numeric array attribute.  Gradually, some operators that produced logical arrays began producing uint8 arrays instead of double arrays.  These changes were made very cautiously because of obvious compatibility issues.  Then in MATLAB 6.5 logical became its own class, instead of an attribute of other classes.  Again this change had to be made very carefully to minimize the impact on the existing huge base of internal code, toolbox code (especially in the Image Processing Toolbox), and existing customer MEX code.  By keeping to the 1-byte element, much existing internal MATLAB code as well customer code could continue to work with little or no change.  A &#8220;compatibility layer&#8221; was introduced into the MEX API that helped smooth over compatibility issues for a couple of releases.  Plus the fact that C had a builtin one-byte data type, but not a builtin one-bit data type, influenced decision making along the way.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andreas Korinek</title>
		<link>http://blogs.mathworks.com/steve/2008/01/28/logical-indexing/#comment-19455</link>
		<dc:creator>Andreas Korinek</dc:creator>
		<pubDate>Mon, 28 Jan 2008 18:19:28 +0000</pubDate>
		<guid>http://blogs.mathworks.com/steve/2008/01/28/logical-indexing/#comment-19455</guid>
		<description>Hi Steve,

I was wondering why the logical type uses 1 byte per entry and not 1 bit. Seems like a huge waste of memory for large binary images.</description>
		<content:encoded><![CDATA[<p>Hi Steve,</p>
<p>I was wondering why the logical type uses 1 byte per entry and not 1 bit. Seems like a huge waste of memory for large binary images.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
