On Mon, Aug 3, 2015 at 10:24 AM, Matthew Brett
wrote:
> On Mon, Aug 3, 2015 at 5:01 PM, Sturla Molden
> wrote:
> > Matthew Brett wrote:
> >
> >> Sure, but to avoid confusion, maybe move the discussion of image
> >> indexing order to another thread?
> >>
> >> I think this thread is about memory
On Sun, Aug 2, 2015 at 1:46 PM, Sturla Molden
wrote:
> On 02/08/15 22:28, Bryan Van de Ven wrote:
> > And to eliminate the order kwarg, use functools.partial to patch the
> zeros function (or any others, as needed):
>
> This will probably break code that depends on NumPy, like SciPy and
> scikit-
On Mon, Aug 3, 2015 at 5:01 PM, Sturla Molden wrote:
> Matthew Brett wrote:
>
>> Sure, but to avoid confusion, maybe move the discussion of image
>> indexing order to another thread?
>>
>> I think this thread is about memory layout, which is a different issue.
>
> It is actually a bit convoluted
Matthew Brett wrote:
> Sure, but to avoid confusion, maybe move the discussion of image
> indexing order to another thread?
>
> I think this thread is about memory layout, which is a different issue.
It is actually a bit convoluted and not completely orthogonal. Memory
layout does not matter fo
SMRUTI RANJAN SAHOO wrote:
> well its really great idea. i can help on python but i don't have any
> knowledge on fortran.
I have been thinking in these lines too. But I have always thought it would
be too much work for very little in return, and it might not interop
properly with libraries writ
On Mon, Aug 3, 2015 at 3:55 PM, Sturla Molden wrote:
> Juan Nunez-Iglesias wrote:
>
>> The short version is that you'll save yourself a lot of pain by starting to
>> think of your images as (plane, row, column) instead of (x, y, z).
>
> There are several things to consider here.
>
> 1. The vertic
well its really great idea. i can help on python but i don't have any
knowledge on fortran.
On Sun, Aug 2, 2015 at 7:25 PM, Kang Wang wrote:
> Hi,
>
> I am an imaging researcher, and a new Python user. My first Python project
> is to somehow modify NumPy source code such that everything is Fortr
Juan Nunez-Iglesias wrote:
> The short version is that you'll save yourself a lot of pain by starting to
> think of your images as (plane, row, column) instead of (x, y, z).
There are several things to consider here.
1. The vertices in computer graphics (OpenGL) are (x,y,z).
2. OpenGL rotatio
On Mon Aug 3 16:26:10 2015 GMT+0200, Matthew Brett wrote:
> Hi,
>
> On Mon, Aug 3, 2015 at 3:13 PM, Gregory Lee wrote:
> > I agree that often you don't need to worry about the memory order. However,
> > it is not uncommon in medical imaging to go back and forth between a 2D or
> > 3D image repre
Hi,
On Mon, Aug 3, 2015 at 3:13 PM, Gregory Lee wrote:
> I agree that often you don't need to worry about the memory order. However,
> it is not uncommon in medical imaging to go back and forth between a 2D or
> 3D image representation and a 1D array representation (e.g. as often used in
> image
I agree that often you don't need to worry about the memory order.
However, it is not uncommon in medical imaging to go back and forth between
a 2D or 3D image representation and a 1D array representation (e.g. as
often used in image reconstruction algorithms). I found that the main time
it was ne
On Mon Aug 3 10:49:35 2015 GMT+0200, Matthew Brett wrote:
> Hi,
>
> On Mon, Aug 3, 2015 at 8:09 AM, Nathaniel Smith wrote:
> > On Aug 2, 2015 11:06 PM, "Kang Wang" wrote:
> >>
> >> This is very good discussion. Thank you all for replying.
> >>
> >> I can see the fundamental difference is that I
Hi,
On Mon, Aug 3, 2015 at 8:09 AM, Nathaniel Smith wrote:
> On Aug 2, 2015 11:06 PM, "Kang Wang" wrote:
>>
>> This is very good discussion. Thank you all for replying.
>>
>> I can see the fundamental difference is that I always
>> think/talk/read/write a 3D image as I(x, y, z), not (plane, row,
On Aug 2, 2015 11:06 PM, "Kang Wang" wrote:
>
> This is very good discussion. Thank you all for replying.
>
> I can see the fundamental difference is that I always
think/talk/read/write a 3D image as I(x, y, z), not (plane, row, column) .
I am coming from MRI (magnetic resonance imaging) research,
This is very good discussion. Thank you all for replying.
I can see the fundamental difference is that I always think/talk/read/write a
3D image as I(x, y, z), not (plane, row, column) . I am coming from MRI
(magnetic resonance imaging) research, and I can assure you that the entire MRI
communi
Hi Kang,
Feel free to come chat about your application on the scikit-image list [1]!
I'll note that we've been through the array order discussion many times
there and even have a doc page about it [2].
The short version is that you'll save yourself a lot of pain by starting to
think of your image
Kang,
Thank you for explaining your motivation. It's clear from your last note,
as you said, that your desire for column-first indexing has nothing to do
with in-memory data layout. That being the case, I strongly urge you to
just use bare numpy and do not use the "fortran_zeros" function I
recomm
Just chiming in with my 2 cents, in direct response to your points...
- Image oriented processing is most typically done with row-major
storage layout. From hardware to general software implementations.
- Well really think of it as [slice,] row, column (logical)... you don't
actually
Thank you all for replying and providing useful insights and suggestions.
The reasons I really want to use column-major are:
I am image-oriented user (not matrix-oriented, as explained in
http://docs.scipy.org/doc/numpy/reference/internals.html#multidimensional-array-indexing-order-issue
On Aug 2, 2015 7:30 AM, "Sturla Molden" wrote:
>
> On 02/08/15 15:55, Kang Wang wrote:
>
> > Can anyone provide any insight/help?
>
> There is no "default order". There was before, but now all operators
> control the order of their return arrays from the order of their input
> array.
This is... o
Could you please explain why you need 'F' ordering? It's pretty unlikely
that you actually care about the internal memory layout, and you'll get
better advice if you explain why you think you do care.
> My first Python project is to somehow modify NumPy source
> code such that everything is Fortra
On Aug 2, 2015 1:17 PM, "Kang Wang" wrote:
>
> Thank you all for replying!
>
> I did a quick test, using python 2.6.6,
There's pretty much no good reason these days to be using python 2.6 (which
was released in *2008*). I assume you're using it because you're using
redhat or some redhat derivativ
On Aug 2, 2015 6:59 AM, "Kang Wang" wrote:
>
> Hi,
>
> I am an imaging researcher, and a new Python user. My first Python
project is to somehow modify NumPy source code such that everything is
Fortran column-major by default.
>
> I read about the information in the link below, but for us, the fact
On 02/08/15 22:28, Bryan Van de Ven wrote:
> And to eliminate the order kwarg, use functools.partial to patch the zeros
> function (or any others, as needed):
This will probably break code that depends on NumPy, like SciPy and
scikit-image. But if NumPy is all that matters, sure go ahead and mon
And to eliminate the order kwarg, use functools.partial to patch the zeros
function (or any others, as needed):
In [26]: import numpy as np
In [27]: from functools import partial
In [28]: np.zeros = partial(np.zeros, order="F")
In [29]: x = np.zeros((2,3), dtype
On 02/08/15 22:14, Kang Wang wrote:
> Thank you all for replying!
>
> I did a quick test, using python 2.6.6, and the original numpy package
> on my Linux computer without any change.
> ==
> x = np.zeros((2,3),dtype=np.int32,order='F')
> print "x.strides ="
> print x.strides
>
> y = x + 1
> print "
Thank you all for replying!
I did a quick test, using python 2.6.6, and the original numpy package on my
Linux computer without any change.==
x = np.zeros((2,3),dtype=np.int32,order='F')
print "x.strides ="
print x.strides
y = x + 1
print "y.strides ="
print y.strides
==
Output:
x.s
Well, numpy has a tendency to prefer C order. There is nothing you can do about
that really. But you just cannot be sure what you get in some cases.
Often you need something specific for interfaceing other code. But in that case
quite often you also do not need to fear the copy.
- Sebastian
On 02/08/15 15:55, Kang Wang wrote:
> Can anyone provide any insight/help?
There is no "default order". There was before, but now all operators
control the order of their return arrays from the order of their input
array. The only thing that makes C order "default" is the keyword
argument to n
29 matches
Mail list logo
