[Top][All Lists]

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

Re: octave and image processing

From: Albert F. Niessner
Subject: Re: octave and image processing
Date: 20 Dec 2002 19:04:41 -0500

On Fri, 2002-12-20 at 17:09, 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?

Sorry, I should have been a little more specific. My part is diffraction
modeling and removing those affects from images mostly for the study of
occulting geometries in a coronagraph. I had not thought about gimp and
will check into it. I am pretty sure that I want a general math engine
over a graphical manipulation tool though. 

> 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.

I do not mind using large amounts of memory where needed -- e.g., A = A
+ B. I am looking to save space on operations like A = transform(A) by
reducing it to transform(A). More on this below, but transform would
still have to be written as A = transform(A) because not all functions
can be done in-place. However, A = A when A == A should not cause a copy
operation -- unless I missed something in the code that I skimmed
through which is likely.

> 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?

Doing it all in double precision is best.

> 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?).

Typically our algorithms are developed in a scripting language and
result in compiled code. Because of this, octave/matlab seem like a more
natural fit. However, I will check into gimp just to see what it does
and if supports a lot of the math.

> If the current limit on matrix size is not the problem, but you would
> like to have reference arguments for functions so modifying a value
> that is passed to a function does not force a copy and also modifies
> the object in the caller's workspace, then I think that might be a
> possibility, but it will require some significant changes to Octave.
> What should the syntax be?  I assume we would want to mark certain
> function arguments as "pass-by-reference" when the function is
> defined.  What should happen for something like
>   a = some_value ();
>   b = a;
>   do_something (a)
> if the argument to do_something is a reference?  Should both a and b
> change, should a copy be forced at the point of the call (so only a is
> modified), or should the call fail?  What about nested calls when the 
> inner function takes a reference argument but the outer one does not?
> I would guess that we would have to force a copy at the nested call or
> fail, since variable passed in the outer call should not change.

Again, I do not want to change Octave significantly because I think it
is a very good tool as is. That is why I am considering a new custom
type whose behavior may be a little a different from the standard
matrix. The behavior difference could only be realized by .oct files and
the interpreter would treat them like a standard matrix. Hence, if you
wanted to treat an image as a reference from a .m file, you would have
to assignWithoutCopy (image, row, column, value). Ugly but there is no
mistaking what is happening. Likewise, there would be an
inPlaceFFT(image) kind of call etc. Inside these calls I can then
extract the pointer to the data without a copy and pass it to the
existing fft. Hence, data coping and memory utilization is minimized.

Notice that I made the assumption that the interpreter does not copy the
data until an assignment is made to an input argument because of the
reference counting that is being done. If this is not correct, then I
have even more holes to plug.

I also want the loader of the image to define its mutability behavior.
In that way, small images would be processed as they are now. It would
only be the very large ones that would have to suffer the pain of the
mixed semantics. Of course, this means I want to throw exceptions from
my loadable modules as well -- oh, it just gets messy. But, I am willing
to constrain my wants to needs to get the job done and keep Octave

> Finally, handling large matrices (> 2GB) will require some changes to
> Octave, and then you will also need to be using a 64-bit system.  I
> would like to make changes like this, but I don't know when it will
> happen.

In this case, I think that using the disk as memory is a good idea. I
realize that this still may cause changes to octave to support larger
than 2 GB image -- at a quick glance, it looks like all matrices are
single index arrays.

> jwe
> -------------------------------------------------------------
> Octave is freely available under the terms of the GNU GPL.
> Octave's home on the web:
> How to fund new projects:
> Subscription information:
> -------------------------------------------------------------

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]