From help-octave-request at bevo dot che dot wisc dot edu Fri Dec 20 18:05:12 2002 Subject: Re: octave and image processing From: "Albert F. Niessner" To: "John W. Eaton" Cc: Octave Help 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 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 whole. > > 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: http://www.octave.org > How to fund new projects: http://www.octave.org/funding.html > Subscription information: http://www.octave.org/archive.html > ------------------------------------------------------------- > Al Niessner ------------------------------------------------------------- Octave is freely available under the terms of the GNU GPL. Octave's home on the web: http://www.octave.org How to fund new projects: http://www.octave.org/funding.html Subscription information: http://www.octave.org/archive.html -------------------------------------------------------------