headers
Francesc Alted | 2 Jan 2004 16:53

UInt64 support in FreeBSD?

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

-------------------------------------------------------
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
Permalink | Reply | 1 comment |
headers
Todd Miller | 2 Jan 2004 17:15

Re: UInt64 support in FreeBSD?

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 <jmiller <at> stsci.edu>

-------------------------------------------------------
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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Edward C. Jones | 3 Jan 2004 03:11
Picon

Update for IM. a small image processing system

                                 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
(Continue reading)

Permalink | Reply | 8 comments |
headers
Peter Verveer | 5 Jan 2004 12:43
Picon

Re: Update for IM. a small image processing system

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
(Continue reading)

Permalink | Reply | 7 comments |
headers
Edward C. Jones | 6 Jan 2004 01:20
Picon

Re: Update for IM. a small image processing system

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
(Continue reading)

Permalink | Reply | 6 comments |
headers
Peter Verveer | 6 Jan 2004 13:30
Picon

Re: Update for IM. a small image processing system

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
(Continue reading)

Permalink | Reply | 4 comments |
headers
Travis E. Oliphant | 6 Jan 2004 16:32
Favicon

Re: Update for IM. a small image processing system

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Perry Greenfield | 6 Jan 2004 16:47

RE: Update for IM. a small image processing system

> 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Edward C. Jones | 6 Jan 2004 17:49
Picon

Re: Update for IM. a small image processing system

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.
>>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
RJS | 7 Jan 2004 07:50
Picon

Update for IM. a small image processing system


 >  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:
(Continue reading)

Permalink | Reply | 1 comment |

Gmane