numpy-discussion — Discussion list for all users of Numerical Python

Re: [Numpy-discussion] Update for IM. a small image processing system

[Peter V. <ve...@em...>]

Hi Sebastian,

I use the 1.1.4 final version. I do however, have images that are not read by 
PIL ('cannot identify image file'). I think these files are okay, since I can 
read them in a scientific imaging program. So maybe the 16bit support in PIL 
is not complete.

Peter

On Wednesday 07 January 2004 20:43, Sebastian Haase wrote:
> > know a good solution for getting 16bit tiffs into numarray?
>
> Hi Peter,
> When did you try that ?  My info is the PIL released within the last few
> month version 1.1.4 which does the job.
> this is from http://effbot.org/zone/pil-changes-114.htm:
>
> (1.1.4a2 released)
>
> + Improved support for 16-bit unsigned integer images (mode "I;16").
>   This includes TIFF reader support, and support for "getextrema"
>   and "point" (from Klamer Shutte).
>
> (Ooops: PIL 1.1.4 final was released on May 10, 2003.   (time flies ...)

[Numpy-discussion] Update for IM. a small image processing system

[RJS <ra...@sa...>]

Hello Peter,

 > On Wednesday 07 January 2004 07:50, RJS wrote:

 > >   Most programs I have seen align a selected sub-image, then shift
 > >  the whole image/array (without rotation, although that would be 
desirable)
 > If I understand you well, you essentially want to estimate a shift 
between two
 > images. I have some code that can do that. I do not intend to include 
that in
 > nd_image for now, but I can send you the code.

Yes, please. I sure that it's better/faster than my PIL or PythonMagick 
efforts. I don't know about machine vision etc, but shift is indispensable 
for video astronomy.

 > >  2. A fast method(ology) to do weighted sums of 2D arrays with a mask
 > >  available for each array.
 > I think this can be achieved relatively easily with standard numarray
 > operations.

Yes, it is straight-forward, in a way, but I'm always scouring the net for 
C and Python algorithms. Very (most?) often they're better than my own. 
This app is really a proof-of-concept; hopefully others will incorporate 
the "clipped image stacking" into their already fine astro apps.
The problem is that the standard methods - median, mean, or summing - all 
suffer when long images in unequal exposure stacks have large clipped regions.

Thanks,

Ray
http://rjs.org

Re: [Numpy-discussion] Update for IM. a small image processing system

[Sebastian H. <ha...@ms...>]

> Hi Ed,
> > A cople of things I would like to see:
> >
> > The ability to read and write a variety of image formats.
>
> That is of course important. But in my view really a separate issue from
> developing a library of analysis routines. The latter just have to operate
on
> numarray arrays and need not to worry about how the data gets there. Of
> course you need to get your data in numarray. PIL seems to do a good job
with
> images, except for 16bit tiffs which causes me quiet some problems.
Anybody
> know a good solution for getting 16bit tiffs into numarray?
>
Hi Peter,
When did you try that ?  My info is the PIL released within the last few
month version 1.1.4 which does the job.
this is from http://effbot.org/zone/pil-changes-114.htm:

(1.1.4a2 released)

+ Improved support for 16-bit unsigned integer images (mode "I;16").
  This includes TIFF reader support, and support for "getextrema"
  and "point" (from Klamer Shutte).

(Ooops: PIL 1.1.4 final was released on May 10, 2003.   (time flies ...)

Regards,
Sebastian

Re: [Numpy-discussion] Update for IM. a small image processing system

[Peter V. <ve...@em...>]

On Wednesday 07 January 2004 07:50, RJS wrote:
>  >  I have uploaded a new version of my small image processing system IM to
>  >  "http://members.tripod.com/~edcjones/IM-01.01.04.tar.gz". Most of the
>  > code in IM (pronounced "I'm") is inferior to "nd_image" so I will
>  > eventually convert it all to "nd_image".
>
> ...
>
>  > nd_image is however also still being developed and I am looking for
>
> directions to
>
>  > further work on. I wondered if there is anything you would like to see
>
> in there?
>
> I have been working with Pythonmagic and numarray for a particular
> astronomy project/technique, and IM has a few things I might use; nd_image
> also has some interesting functions as well.
>
> I want to align and specially stack 8-bit grayscale images from a FITS
> cube, or BMP set, currently. So, my suggestions (hint, hint) are:
> 1. A method to shift an array to efficiently give the best alignment with
> another. My brute force shifting and subtracting from the main image is
> slow... Most programs I have seen align a selected sub-image, then shift
> the whole image/array (without rotation, although that would be desirable)

If I understand you well, you essentially want to estimate a shift between two 
images. I have some code that can do that. I do not intend to include that in 
nd_image for now, but I can send you the code.

> My _main_ objective is to stack progressively-longer-exposure 8-bit images
> into 16-bits, with the clipped pixels of longer exposures ignored in the
> summing process. The value of each pixel must be weighted inversely
> proportionately to it's exposure length (so shorter exposures "fill in" the
> clipped areas of the long exposures).
>
> So:
> 2. A fast method(ology) to do weighted sums of 2D arrays with a mask
> available for each array.

I think this can be achieved relatively easily with standard numarray 
operations.

Cheers, Peter

[Numpy-discussion] Update for IM. a small image processing system

[RJS <ra...@sa...>]

 >  I have uploaded a new version of my small image processing system IM to
 >  "http://members.tripod.com/~edcjones/IM-01.01.04.tar.gz". Most of the code
 >  in IM (pronounced "I'm") is inferior to "nd_image" so I will eventually
 >  convert it all to "nd_image".
...

 > nd_image is however also still being developed and I am looking for 
directions to
 > further work on. I wondered if there is anything you would like to see 
in there?

I have been working with Pythonmagic and numarray for a particular 
astronomy project/technique, and IM has a few things I might use; nd_image 
also has some interesting functions as well.

I want to align and specially stack 8-bit grayscale images from a FITS 
cube, or BMP set, currently. So, my suggestions (hint, hint) are:
1. A method to shift an array to efficiently give the best alignment with 
another. My brute force shifting and subtracting from the main image is 
slow... Most programs I have seen align a selected sub-image, then shift 
the whole image/array (without rotation, although that would be desirable)

My _main_ objective is to stack progressively-longer-exposure 8-bit images 
into 16-bits, with the clipped pixels of longer exposures ignored in the 
summing process. The value of each pixel must be weighted inversely 
proportionately to it's exposure length (so shorter exposures "fill in" the 
clipped areas of the long exposures).

So:
2. A fast method(ology) to do weighted sums of 2D arrays with a mask 
available for each array.

I really do commend Peter and Edward for their contribution!
By the way, if you do wxPython and haven't tried Boa Constructor, you might 
like it. I have been using the CVS version (now .2.8) for a few months, and 
it's working nicely.

Ray Schumacher
http://rjs.org/astro/1004x/

Re: [Numpy-discussion] Update for IM. a small image processing system

[Edward C. J. <edc...@er...>]

Perry Greenfield wrote:

>>Hi Ed,
>>    
>>
>>>A cople of things I would like to see:
>>>
>>>The ability to read and write a variety of image formats. 
>>>      
>>>
>>That is of course important. But in my view really a separate issue from 
>>developing a library of analysis routines. The latter just have 
>>to operate on 
>>numarray arrays and need not to worry about how the data gets there. Of 
>>course you need to get your data in numarray. PIL seems to do a 
>>good job with 
>>images, except for 16bit tiffs which causes me quiet some 
>>problems. Anybody 
>>know a good solution for getting 16bit tiffs into numarray?
>>
>>    
>>
>I'd agree that support for image formats should be decoupled
>from processing functions
> 
>  
>
>>>ImageMagick
>>>has a good set. All of ImageMagick should be wrapped.
>>>      
>>>
>>Isn't there already a python interface to ImageMagick?
>>
>>
>>    
>>
>Perhaps we should look at how much work it would be to adopt
>Travis's wrapped version for numarray. It may be fairly simple
>to do if his version uses the the more common api calls.
>
>Perry
>  
>
I have checked this out a bit.  All the Numeric function calls are among 
the ones that numarray emulates. All but one of them seem to be properly 
DECREFed. The exception is in "imageobject.c", line 973, where "bitobj" 
is created.

Also: ImageMagick was forked, producing GraphicsMagick. The two are very 
similar. Which is better to use?

Ed Jones

RE: [Numpy-discussion] Update for IM. a small image processing system

[Perry G. <pe...@st...>]

> Hi Ed,
> > A cople of things I would like to see:
> >
> > The ability to read and write a variety of image formats. 
> 
> That is of course important. But in my view really a separate issue from 
> developing a library of analysis routines. The latter just have 
> to operate on 
> numarray arrays and need not to worry about how the data gets there. Of 
> course you need to get your data in numarray. PIL seems to do a 
> good job with 
> images, except for 16bit tiffs which causes me quiet some 
> problems. Anybody 
> know a good solution for getting 16bit tiffs into numarray?
> 
I'd agree that support for image formats should be decoupled
from processing functions
 
> >ImageMagick
> > has a good set. All of ImageMagick should be wrapped.
> 
> Isn't there already a python interface to ImageMagick?
> 
> 
Perhaps we should look at how much work it would be to adopt
Travis's wrapped version for numarray. It may be fairly simple
to do if his version uses the the more common api calls.

Perry

Re: [Numpy-discussion] Update for IM. a small image processing system

[Travis E. O. <oli...@ee...>]

Edward C. Jones wrote:
> Peter Verveer wrote:
> 
>> On Saturday 03 January 2004 03:11, Edward C. Jones wrote:
>>  
>>
>>>                                 IM
>>>
>>> I have uploaded a new version of my small image processing system IM to
>>> "http://members.tripod.com/~edcjones/IM-01.01.04.tar.gz". Most of the 
>>> code
>>> in IM (pronounced "I'm") is inferior to "nd_image" so I will eventually
>>> convert it all to "nd_image".
>>>   
>>
>>
>> I had a look and I guess that indeed you could use the nd_image 
>> package for some low level stuff (I am the author of nd_image). 
>> nd_image is however also still being developed and I am looking for 
>> directions to further work on. I wondered if there is anything you 
>> would like to see in there?  
>>
> Thanks for your response. I have put a slightly revised version of IM on 
> my web page "http://members.tripod.com/~edcjones/". The new version 
> includes functions, written in C, for slicing arrays.
> 
> A cople of things I would like to see:
> 
> The ability to read and write a variety of image formats. ImageMagick 
> has a good set. All of ImageMagick should be wrapped.
> 

I have wrappers for ImageMagick done (for Numeric).

See pylab.sourceforge.net

-Travis

Re: [Numpy-discussion] Update for IM. a small image processing system

[Peter V. <ve...@em...>]

Hi Ed,
> A cople of things I would like to see:
>
> The ability to read and write a variety of image formats. 

That is of course important. But in my view really a separate issue from 
developing a library of analysis routines. The latter just have to operate on 
numarray arrays and need not to worry about how the data gets there. Of 
course you need to get your data in numarray. PIL seems to do a good job with 
images, except for 16bit tiffs which causes me quiet some problems. Anybody 
know a good solution for getting 16bit tiffs into numarray?

>ImageMagick
> has a good set. All of ImageMagick should be wrapped.

Isn't there already a python interface to ImageMagick?

> The Canny edge operator along with code for generating polygonal
> approximations to edges. See OpenCV.

Canny I will likely implement at some point. Polygonal approximations to edges 
can be done in many ways I guess. I would need to find some reasonable method 
in the literature to do that. Suggestions are welcome.

> Do you have some examples of algorithms for multi-dimensional images
> that you think should be put in nd_image?

At the moment I have only been looking at general basic image processing 
operations which normally generalize well to multiple dimensions. I will 
continue to do that. There are also somewhat higher level operations that I 
currently have not included. For instance, I implemented a sub-pixel shift 
estimator which I need for my work. That would be an example of a routine 
that is completely written in python using numarray and nd_image routines and 
does not need any C. This could be useful for others, but I am not sure if it 
belongs in a low-level library. Maybe we need some repository for that sort 
of python applications.

Cheers, Peter

Re: [Numpy-discussion] Update for IM. a small image processing system

[Edward C. J. <edc...@er...>]

Peter Verveer wrote:

>On Saturday 03 January 2004 03:11, Edward C. Jones wrote:
>  
>
>>                                 IM
>>
>>I have uploaded a new version of my small image processing system IM to
>>"http://members.tripod.com/~edcjones/IM-01.01.04.tar.gz". Most of the code
>>in IM (pronounced "I'm") is inferior to "nd_image" so I will eventually
>>convert it all to "nd_image".
>>    
>>
>
>I had a look and I guess that indeed you could use the nd_image package for 
>some low level stuff (I am the author of nd_image). nd_image is however also 
>still being developed and I am looking for directions to further work on. I 
>wondered if there is anything you would like to see in there? 
>  
>
Thanks for your response. I have put a slightly revised version of IM on 
my web page "http://members.tripod.com/~edcjones/". The new version 
includes functions, written in C, for slicing arrays.

A cople of things I would like to see:

The ability to read and write a variety of image formats. ImageMagick 
has a good set. All of ImageMagick should be wrapped.

The Canny edge operator along with code for generating polygonal 
approximations to edges. See OpenCV.

Do you have some examples of algorithms for multi-dimensional images 
that you think should be put in nd_image?

Thanks,
Ed Jones

Re: [Numpy-discussion] Update for IM. a small image processing system

[Peter V. <ve...@em...>]

On Saturday 03 January 2004 03:11, Edward C. Jones wrote:
>                                  IM
>
> I have uploaded a new version of my small image processing system IM to
> "http://members.tripod.com/~edcjones/IM-01.01.04.tar.gz". Most of the code
> in IM (pronounced "I'm") is inferior to "nd_image" so I will eventually
> convert it all to "nd_image".

I had a look and I guess that indeed you could use the nd_image package for 
some low level stuff (I am the author of nd_image). nd_image is however also 
still being developed and I am looking for directions to further work on. I 
wondered if there is anything you would like to see in there? 

>                               THOUGHTS
>
> There are many open source image processing systems but most of them get
> only to the Canny edge operator and then stop.  A sample of the better ones
> are:
>
>     ImageMagick   http://www.imagemagick.org/
>     OpenCV        http://www.intel.com/research/mrl/research/opencv/
>     Xite         
> http://www.ifi.uio.no/forskning/grupper/dsb/Software/Xite/ VXL          
> http://vxl.sourceforge.net/
>     Gandalf       http://sourceforge.net/projects/gandalf-library/
>     imgSeek       http://imgseek.sourceforge.net/

I think not all of these are general image processing systems and often a bit 
limited. One problem that I have with most of these packages is that they 
stop at processing 8bit or 16bit two-dimensional images. That is a limit for 
quite a lot of image analysis research, for instance medical imaging. That is 
why numarray is so great, it supports multi-dimensional arrays of arbritrary 
type. nd_image is designed to support multiple dimensions and any data type. 
That is not always easy and may prevent some optimizations, but I think it is 
an important feature. That idea is of course not new, matlab is starting to 
support multi-dimensional image routines and I am aware of at least one C 
library that does this, although it is not free software: 
  http://www.ph.tn.tudelft.nl/DIPlib/

> And then there is the huge and hard to use "Image Understanding
> Environment" (IUE) at "http://www.aai.com/AAI/IUE/IUE.html". Has anyone
> used this?

The website appears to updated last in 1999, which is not encouraging. Looks 
hideously complex too.

> A good starting point is "The Computer Vision Homepage" at
> "http://www-2.cs.cmu.edu/~cil/vision.html". At this site there is a list of
> published software. A well-known example is the Kanade-Lucas-Tomasi Feature
> Tracker coded by Stan Birchfield at
> "http://vision.stanford.edu/~birch/klt/". Thanks. Note how short the
> software list is compared with the size of the computer vision lterature.
>
> Why does so little software exists for the more advanced parts of computer
> vision? I feel this is mostly because academic researchers seldom publish
> their software. In some cases (for example, face recognition software)
> there are financial motives. In most cases. I suspect that there is no
> pressure on the researchers from journals or department chairmen to publish
> the software. So they avoid the work of making their software presentable
> by not releasing it. The result are many unreproduced experiments and slow
> transitions of new algorithms out of academia.

This is certainly true. I know from experience that often you simply cannot 
afford to design and maintain a software package after you came up with 
something new and published it. So a lot of things never leave the laboratory 
simply because it is hard to do properly. I hope that having a system around 
like numarray with packages will help.

> A good computer vision system
>     Has an easy to use and widely used scripting language.
>         Python
>     Has powerful array processing capabilities.
>         numarray, nd_image
>     Wraps a variety of other computer vision systems. The wrapping process
>     should be straightforward.
>         SWIG, Pyrex, Psyco, ..., and the Python API.
>     Provides a uniform interface to its components.
>     Is used by many people.

I intend to develop nd_image further as a basic component for multidimensional 
image analysis. It would be great if it would get picked up to be part of a 
system like to propose. Maybe in the future SciPy could play that role.

What I would like to hear from people that use this type of software is what 
kind of basic operations you would like to see become part of nd_image. That 
will help me to further develop the package. Contributed code is obviously 
also welcome.

Peter

-- 
Dr. Peter J. Verveer
Cell Biology and Cell Biophysics Programme
European Molecular Biology Laboratory
Meyerhofstrasse 1
D-69117 Heidelberg
Germany
Tel. : +49 6221 387245
Fax  : +49 6221 387306

[Numpy-discussion] Update for IM. a small image processing system

[Edward C. J. <edc...@er...>]

                                 IM

I have uploaded a new version of my small image processing system IM to
"http://members.tripod.com/~edcjones/IM-01.01.04.tar.gz". Most of the code
in IM (pronounced "I'm") is inferior to "nd_image" so I will eventually
convert it all to "nd_image".

Some features are:
    Wrappers for some useful functions in the numarray API.
        NA_GetType
        NA_TypeName
        NA_GetTypeFromTypeno
        NA_TypenoFromType
    SafeCastCheck
    Standardized parameters
        Module(arrin), TypeCode(arrin), Width(arrin), Height(arrin),
        Bands(arrin), Mode(arrin), NatypeOrMode(arrin), and
        BytesPerItem(arrin)
    Open and Save
    ArrayToArrayCast
        Converts between array types and formats. Out of range values are
        clipped.
    Some additions to numarray
        BlockReduce, MultiReduce, BlockMean, CountNonZero, CountZeros,
        Stretch (grey level range), Zoom, Shrink, and Saturate.
        Convert an array to a list of (array[i,j], i, j) or a dictionary
            with entries d[(i,j)] = array[i,j].
    Sliding window operators including MeanX and HaarX which have masking. 
        Only the unmasked pixels are averaged when finding a mean. For MeanX
        and HaarX, a border is added to the image. The pixels in the border
        become the masked pixels.

                              THOUGHTS

There are many open source image processing systems but most of them get
only to the Canny edge operator and then stop. A sample of the better ones
are:

    ImageMagick   http://www.imagemagick.org/
    OpenCV        http://www.intel.com/research/mrl/research/opencv/
    Xite          http://www.ifi.uio.no/forskning/grupper/dsb/Software/Xite/
    VXL           http://vxl.sourceforge.net/
    Gandalf       http://sourceforge.net/projects/gandalf-library/
    imgSeek       http://imgseek.sourceforge.net/

And then there is the huge and hard to use "Image Understanding Environment"
(IUE) at "http://www.aai.com/AAI/IUE/IUE.html". Has anyone used this?

A good starting point is "The Computer Vision Homepage" at
"http://www-2.cs.cmu.edu/~cil/vision.html". At this site there is a list of
published software. A well-known example is the Kanade-Lucas-Tomasi Feature
Tracker coded by Stan Birchfield at
"http://vision.stanford.edu/~birch/klt/". Thanks. Note how short the
software list is compared with the size of the computer vision lterature.

Why does so little software exists for the more advanced parts of computer
vision? I feel this is mostly because academic researchers seldom publish
their software. In some cases (for example, face recognition software) there
are financial motives. In most cases. I suspect that there is no pressure on
the researchers from journals or department chairmen to publish the
software. So they avoid the work of making their software presentable by not
releasing it. The result are many unreproduced experiments and slow
transitions of new algorithms out of academia.

A good computer vision system
    Has an easy to use and widely used scripting language.
        Python
    Has powerful array processing capabilities.
        numarray, nd_image
    Wraps a variety of other computer vision systems. The wrapping process
    should be straightforward.
        SWIG, Pyrex, Psyco, ..., and the Python API.
    Provides a uniform interface to its components.
    Is used by many people.

Re: [Numpy-discussion] UInt64 support in FreeBSD?

[Todd M. <jm...@st...>]

On Fri, 2004-01-02 at 10:53, Francesc Alted wrote:
> Hi,
> 
> Some people wanting to use pytables on FreeBSD would like to have UInt64
> support, but numarray lacks support for it on this platform. As FreeBSD uses
> gcc compiler, I think it's just a matter to add an "freebsd4-i386" entry in
> generate.py.
> 
> Todd, may you please add such a support? 

Sure, I'll add it,  but I have no means to test it...  I also changed
the default platform to include UInt64,  since with the exception of
MSVC,  it's supported everywhere I've looked.

Todd

> Regarding to the other parameters,
> LP64 (long pointer), HAS_FLOAT128 (128 floating point), I'm not sure, but
> perhaps they maybe similar to the "linux2" platform. Anyone using FreeBSD
> can give more hints?
> 
> Happy new year!,
-- 
Todd Miller <jm...@st...>

[Numpy-discussion] UInt64 support in FreeBSD?

[Francesc A. <fa...@op...>]

Hi,

Some people wanting to use pytables on FreeBSD would like to have UInt64
support, but numarray lacks support for it on this platform. As FreeBSD uses
gcc compiler, I think it's just a matter to add an "freebsd4-i386" entry in
generate.py.

Todd, may you please add such a support? Regarding to the other parameters,
LP64 (long pointer), HAS_FLOAT128 (128 floating point), I'm not sure, but
perhaps they maybe similar to the "linux2" platform. Anyone using FreeBSD
can give more hints?

Happy new year!,

-- 
Francesc Alted

RE: [Numpy-discussion] Slow conversion from list to arrays

[Nadav H. <na...@vi...>]

It works excellent. I see also that there is a corresponding update in =
the CVS.

  Happy new (and peaceful) year,
   Nadav.


-----Original Message-----
From:	Todd Miller [mailto:jm...@st...]
Sent:	Tue 30-Dec-03 16:34
To:	Nadav Horesh
Cc:	numpy-discussion
Subject:	Re: [Numpy-discussion] Slow conversion from list to arrays
On Thu, 2003-12-25 at 03:27, Nadav Horesh wrote:=20
> The conversion for a list of large arrays into a matrix is very slow =
in
> numarray while reasonably fast:
>=20
> >>> from numarray import *
> >>> a =3D [arange(200000), arange(200000), arange(200000), =
arange(200000)]
> >>> aa =3D array(a)   # Very slow
>=20
> --------------------------------
>=20
> >>> from Numeric import *
> >>> a =3D [arange(200000), arange(200000), arange(200000), =
arange(200000)]
> >>> aa =3D array(a)   # Fast
>=20
> Python version:    2.3.3
> numarray version:  Official 0.8
>=20
> Tested under WinXP and RH9 linux.
>=20
> Any workaround?
>=20
Try concatenate.  For the array sizes you're looking at,  numarray does
OK.  You may have to adjust the result shape.

Todd=20

>   Nadav
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
> Click now! =
http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
--=20
Todd Miller 		=09
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576

Re: [Numpy-discussion] Slow conversion from list to arrays

[Todd M. <jm...@st...>]

On Thu, 2003-12-25 at 03:27, Nadav Horesh wrote: 
> The conversion for a list of large arrays into a matrix is very slow in
> numarray while reasonably fast:
> 
> >>> from numarray import *
> >>> a = [arange(200000), arange(200000), arange(200000), arange(200000)]
> >>> aa = array(a)   # Very slow
> 
> --------------------------------
> 
> >>> from Numeric import *
> >>> a = [arange(200000), arange(200000), arange(200000), arange(200000)]
> >>> aa = array(a)   # Fast
> 
> Python version:    2.3.3
> numarray version:  Official 0.8
> 
> Tested under WinXP and RH9 linux.
> 
> Any workaround?
> 
Try concatenate.  For the array sizes you're looking at,  numarray does
OK.  You may have to adjust the result shape.

Todd 

>   Nadav
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576

[Fwd: Re: [Numpy-discussion] "error getting read buffer data ptr"]

[Todd M. <jm...@st...>]

This is a response I forgot to reply-all.  Edward tracked this problem
down to a memory management bug in his C-code.


-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576

[Numpy-discussion] Linking numarray with ATLAS

[Nadav H. <na...@Vi...>]

The following recipe worked on RH9 and gentoo 1.4:
     1. Set environment variable USE_LAPACK:
                export USE_LAPACK=1
     2. Edit addon.py and make the following changes:
             1. Change the first item of lapack_libs from 'blas' to
                'atlas'
             2. Change lapack_dirs from [] to ['directory of
                libatlas.a', 'directory of libg2c.a']
             3. Proceed with the usual installation: python setup.py ...
I had some problem on the RH9 system that were solved by upgrading to a
recent ATLAS package.

 Enjoy ;)
  Nadav.

[Numpy-discussion] Linking numarray with atlas

[Nadav H. <na...@Vi...>]

The following recipe worked with RH9 and gentoo linux:

     1. Set environment variable USE_LAPACK:

[Numpy-discussion] "error getting read buffer data ptr"

[Edward C. J. <edc...@er...>]

What are the usual causes for this traceback:

Traceback (most recent call last):
  File "/home/edcjones/cvlib/phase03/IM/slide/test03.py", line 166, in ?
    test4()
  File "/home/edcjones/cvlib/phase03/IM/slide/test03.py", line 125, in test4
    print arrout
  File "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py",
             line 631, in __str__
    return array_str(self)
  File "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py",
             line 1159, in array_str
    return arrayprint.array2string(
  File "/usr/local/lib/python2.3/site-packages/numarray/arrayprint.py",
             line 187, in array2string
    separator, prefix)
  File "/usr/local/lib/python2.3/site-packages/numarray/arrayprint.py",
             line 140, in _array2string
    data = _gen.ravel(a)
  File "/usr/local/lib/python2.3/site-packages/numarray/generic.py",
             line 916, in ravel
    return reshape(array, (array.nelements(),))
  File "/usr/local/lib/python2.3/site-packages/numarray/generic.py",
             line 907, in reshape
    v = v.view()
libnumarray.error: NA_updateDataPtr: error getting read buffer data ptr

[Numpy-discussion] Slow conversion from list to arrays

[Nadav H. <na...@Vi...>]

The conversion for a list of large arrays into a matrix is very slow in
numarray while reasonably fast:

>>> from numarray import *
>>> a = [arange(200000), arange(200000), arange(200000), arange(200000)]
>>> aa = array(a)   # Very slow

--------------------------------

>>> from Numeric import *
>>> a = [arange(200000), arange(200000), arange(200000), arange(200000)]
>>> aa = array(a)   # Fast

Python version:    2.3.3
numarray version:  Official 0.8

Tested under WinXP and RH9 linux.

Any workaround?

  Nadav

Re: [Numpy-discussion] ANN: numarray-0.8 released

[<jo...@fh...>]

On Fri, 19 Dec 2003 18:33:15 +0100 Peter Verveer wrote:

Peter> I just checked and found that the problem was that the numarray
Peter> directory is called numarray-0.8 when you gunzip the tar file.
Peter> Apparantly the '.' in the file name is a problem. Renaming to
Peter> 'numarray' fixed the problem.

I see that mkhowto prints that information to the screen (saying its a
dvips problem), so I guess it is fine for now... Never encountered it
as I always use cvs to get the source, so my directory is numarray
anyway.

Greetings,
Jochen
--=20
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Libert=E9, =C9galit=E9, Fraternit=E9                GnuPG key: CC1B0B4D
        (Part 3 you find in my messages before fall 2003.)

Re: [Numpy-discussion] Re: Python, Numarray, LinearAlgebra

[<jo...@fh...>]

On Fri, 19 Dec 2003 18:12:00 +0100 Jochen K=FCpper wrote:

[sh..]

Sorry guys, that was supposed to be a private mail.

Greetings,
Jochen
--=20
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Libert=E9, =C9galit=E9, Fraternit=E9                GnuPG key: CC1B0B4D
        (Part 3 you find in my messages before fall 2003.)

Re: [Numpy-discussion] ANN: numarray-0.8 released

[Peter V. <ve...@em...>]

I just checked and found that the problem was that the numarray directory i=
s=20
called numarray-0.8 when you gunzip the tar file. Apparantly the '.' in the=
=20
file name is a problem. Renaming to 'numarray' fixed the problem.

Peter

On Friday 19 December 2003 18:08, Jochen K=FCpper wrote:
> On Thu, 18 Dec 2003 19:32:10 +0100   wrote:
> > I could not build the html docs for some reason but building the pdf
> > worked fine.
>
> Wanna send some more information on your problems?
>
> Greetings,
> Jochen

[Numpy-discussion] Re: Python, Numarray, LinearAlgebra

[<jo...@fh...>]

Hallo Corinna,

leider kann ich Dir nicht direkt bei Deinem Fehler helfen.

Falls der Fehler auch mit der letzten Version auftritt (0.8) solltest
Du Deine Fehlerbeschreibung/analyse doch bitte an die Numeric Python
Emailliste <num...@li...> schicke.=20=20

Erw=E4hne bitte Dein System, Python Version sowie die numarray version.

Greetings,
Jochen
--=20
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Libert=E9, =C9galit=E9, Fraternit=E9                GnuPG key: CC1B0B4D
        (Part 3 you find in my messages before fall 2003.)