This is interesting. <br><br>I have always done RGB imaging with numpy using arrays of shape (height, width, 3). In fact, this is the form that PIL gives when calling np.asarray() on a PIL image. <br><br>It does seem more efficient to be able to do a[0],a[1],a[2] to get the R, G, and B channels respectively. This, obviously is not currently the case. <br>
<br>Would it be better for me to switch to this way of doing things and/or work a patch for PIL so that the array is built in the form (3, height, width)?<br><br>Chris<br><br><br><br><div class="gmail_quote">On Tue, May 12, 2009 at 4:14 PM, David Warde-Farley <span dir="ltr"><<a href="mailto:dwf@cs.toronto.edu">dwf@cs.toronto.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
On 12-May-09, at 3:55 PM, Ryan May wrote:<br>
><br>
> It's going to be faster to do it without the transpose. Besides,<br>
> for numpy,<br>
> that imshow becomes:<br>
><br>
> imshow(b[0])<br>
><br>
> Which, IMHO, looks better than Matlab.<br>
<br>
</div>You're right, that is better, odd how I never thought of doing it like<br>
that. I've been stuck in my Matlab-esque world with dstack() as my<br>
default mental model of how images/matrices ought to be stacked.<br>
<br>
Am I right in thinking that b[0] is stored in a big contiguous block<br>
of memory, thus making the read marginally faster than slicing on the<br>
third?<br>
<font color="#888888"><br>
David<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Numpy-discussion mailing list<br>
<a href="mailto:Numpy-discussion@scipy.org">Numpy-discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
</div></div></blockquote></div><br>