[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: 22 Dec 2002 14:04:08 -0500

On Sat, 2002-12-21 at 13:00, John W. Eaton wrote:
> On 21-Dec-2002, Al Niessner <address@hidden> wrote:
> | 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
> | [...]
> | 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.
> Unfortunately(?) you can't do this without some other changes to
> Octave.  There are a couple of levels of reference counting.  One is
> in the Matrix object itself and the other is in the octave_value
> object.  If you look at the octave_scalar object, you will see that it
> is just a container for a double (or complex) number.  Neither of
> those objects implements reference counting, but Octave does not allow
> functions to modify scalar arguments either.  For example, if you do
> something like
>   function f (x) x = 2; end
>   x = 1;
>   f (x)
>   x
> you will find that x still has a value of 1 after the function.  The
> reference counting you need to modify is the overall reference
> counting scheme for octave_value objects.  You can't change that by
> defining a new sub-type like octave_image.
> Sorry, but what you want to do will require some fundamental changes
> to the way Octave works.  You mentioned before that you didn't want to
> do that because it would introduce some maintenance problems for you.
> That's only true if you make the modifications and they are not
> included in the "standard" Octave sources, but if we can come up with
> a reasonable way to introduce "pass-by-reference" semantics for
> functions in Octave, I'd be happy to try to implement that (or help
> you do it).  The primary problem that I see is that whatever we come
> up with will probably not be compatible with whatever the MathWorks
> does for Matlab if they choose to implement similar functionality.
> jwe

I may have missed something, but it appears as though the
octave_value_list is an extension of Array.h and it depends on
Array::make_unique() to do the reference counting and copy which is a
shallow copy -- as it should be. Hence, the example I sent should be
sufficient for the doing the job I need done.

Remember that I want the reference handling only in OCT-files and not
M-files because I do not want to change the grammar and thus the

I am still working on how to make it safe for Array to be treated as a
being passed by reference rather than by value into an OCT-file, but I
have the beginnings of an idea. I make the ability to ignore the
reference counting in Array<T> private to that class -- a boolean field.
I would then add an inner class that had access to that private field.
The constructor of the inner class would then take the Array<T> instance
in question in a parameter.

Something akin to:

class Array<T>
   class ReferenceBehavior
         Array<T> &ref;
         ReferenceBehavior (Array<T> &changeToRef) : ref(changeToRef)
         { ref.ignoreReferenceCounting = true }
         ~ReferenceBehavior() { ref.ignoreReferenceCounting = false }
   boolean ignoreReferenceCounting; // default should be false

In this way the user would then do something like this:

#include <octave/oct.h>

DEFUN_DLD (testDynamicFunc, args, orgs, "Test Dynamic Functions.")
  Image test1 = args(0).image_value();

     Array<T>::ReferenceBehavior behaviorAdjuster = 

     ... do operations with test1 behaving as though it was passed by
  } // the ending of the scope make test1 pass by value again

  return octave_value(test1);

Now, this is not perfect by any stretch, but I think you can see where I
am going with it -- hopefully. It allows for some new types to be
handled as references in OCT-files, but the original octave types should
go unaffected. Like I said, I have to give the above stuff more thought
to get right, but its a start anyway. Looking at it, ReferenceBehavior
should probably be an inner class to Image and ignoreReferenceCounting
should be protected in Array<T> so that Image can modify it. That way,
someone cannot use this mechanism with Matrix or something.

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]