[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: octave and image processing

From: Al Niessner
Subject: Re: octave and image processing
Date: 21 Dec 2002 12:34:58 -0500

On Sat, 2002-12-21 at 01:17, Andy Adler wrote:
> On Fri, 20 Dec 2002, John W. Eaton wrote:
> > On 19-Dec-2002, Al Niessner <address@hidden> wrote:
> >
> > | How can/should octave be changed to allow for processing very large
> > | images?
> >
> > What do you want to be able to do with the image object?
> >
> > If you are looking for arbitrary numerical operations on images, then
> > I don't see how you will be able to work on them without a lot of
> > memory since you will probably want to use double precision
> > arithmetic.  Even if single precision is good enough for image
> > manipulation, I'm not sure that you will be able to get that in
> > Octave, since I think it would be difficult to support both double and
> > float arithmetic in Octave.
> >
> > If you don't need arbitrary numerical operations, then perhaps it
> > would help to have int/short/char size matrix objects that can be used
> > to store data?  I'm not sure what operations would be useful for these
> > objects.  Would we want integer arithmetic rules, or conversion to
> > double?
> >
> > I do think it would be useful for Octave to be able to do more things
> > with images and for those operations to use less memory, but I'm
> > curious to know why you don't simply use something that is already
> > designed for image manipulation (the Gimp?).
> I also do lots of image processing with octave. I research medical
> image processing algorithms; for developing new image procesing
> algorithms, tools like gimp are inappropriate. Until recently,
> however, I didn't need to handle very large images - I see myself
> doing this fairly soon, now.
> I think that two additions would be very useful:
> - support for short/char size matrix objects. This would be
>   primarily to load images. Subsequent processing would
>   then be done on subsections of the image in double precision.
> - support for large matrices mapped to disk. The idea of
>   Paul Kienzle to unify this with parallel processing support
>   is excellent.
> I'll try to put together some support for byte matrices as a test
> of the first idea. Does anyone who has used the corresponding
> feature in Matlab want to comment on the requirements?
> My idea is to allow the result to be upcast to double whenever
> an operation could potentially overflow.
> andy

I agree that Paul's suggestion for putting large matrices onto disk is a
good idea. However, I had a slightly different approach for extending
the current concept of an image in octave.

I would like to keep the image represented as a matrix of doubles. I
think that any operation preformed on the matrix -- except reading it --
will push any limited representation (shorts or bytes) to doubles.

I am attempting to introduce a new type to octave called 'image'. The
user could then define the following (default is b,b,b):

1) Storage location of the image
  a) disk
  b) memory

2) How operations are preformed
  a) block oriented (see parallel processing and Paul's suggestion)
  b) nominal -- as done normally in octave

3) The mutability of the data in an image
  a) in-place operations allowed via .oct files only
  b) nominal -- as done normally in octave

I think option (1) is pretty obvious. If the images I am loading are
small, then keep them in memory. If they are larger than the resources
on my machine, then I will tell octave to use disk storage. In this way
the user has complete control and understanding of the choice being
made. If (1a) is chosen, then (2a) must be true as well. Lastly, there
is (3). This is a little more difficult. It would allow reference to be
passed within .oct files causing the original data to change. However,
the user would have to explicitly choose this option and accept all the
pitfalls that come with it.

To support this new type I would have to change loadimage and saveimage.
I would then set them up to be more like this:

[image MAP] = loadimage (filename, format, options)
saveimage (filename, image, format, MAP)

format would be the same as the current saveimage but work in both.
options are the behavior choices above.

Note that the defaults will give the user an image that is a matrix and
behaves exactly like they do now.

I would then add the following functions to ease use:

image emptyimage (size)
insertIntoImage (image, row, column, subimage)
[ subimage ] = extractSubimage (image, location, size, options)
[ double ] = getValue (image, row, column)
[ double ] = setValue (image, row, column) // returns old value if
changed, otherwise NAN

This means all current .m files would work as they are. All programming
would have to be done as though all the standard octave rules applied to
input parameters changing.

I think this gives Andy mostly what he wants -- large images to disk
when they get large along with some parallel processing. It gives me
what I need -- in-place capabilities. It does not alter Octave's rules
on input parameters etc. in .m files or the interpreter -- however, it
may be nice to do operations like += and such in-place but not required.

So the question is, is it better to create a whole new type or simply
extend matrix? I am leaning toward the latter in which I would have a
method that returned rep->data independent of the reference count if
option (3a) was chosen at load time or in a call to extractImage.

Al Niessner

Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:
How to fund new projects:
Subscription information:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]